Controlled Stripe access for a sensitive billing handover

A Stripe secret key can authorize consequential actions. MoveMRR therefore uses purpose-specific Restricted Keys for normal source and destination access and validates required permissions. The source role needs access to inspect the objects that define current billing. The destination role needs the permissions required to recreate the agreed objects. Keeping those roles separate makes the granted capability easier to review.

Least privilege is not a fixed list for every project. Subscription schedules, coupons, tax settings, products, prices or optional webhook recreation can change the required scope. The practical rule is to grant the documented permissions needed by the selected workflow, reject a key that cannot perform the required checks, and avoid unrelated permissions.

Stored live keys use Supabase Vault. After storage, the live secret is not returned to the browser; the interface receives key status and validation metadata rather than the key value. Internal migration operations request the secret only when they need to call Stripe. Live-key storage is refused if the secure Vault path is unavailable instead of silently falling back to Base64 encoding.

A stored live key receives a MoveMRR expiry after 30 days. Once expired, migration operations reject it and the cleanup path can remove the stored secret. This limit narrows the retention window, but it does not reach into Stripe and revoke the credential there. The account owner remains responsible for revocation, rotation and incident response in Stripe.

MoveMRR does not collect or store raw card numbers. Where a migration qualifies, Stripe can copy eligible customer and payment-method data between accounts. The MoveMRR workflow then relates the copied customer and payment-method objects to recreated destination subscriptions. Stripe documents both the eligible data and the objects that Customer Data Copy does not transfer.

This separation does not imply that every payment method will work without follow-up. Unsupported methods, missing default payment methods, issuer declines and Strong Customer Authentication can require remediation or customer action. A dry run and exception report are therefore operational controls, not a guarantee of future payment authorization.

Sandbox seeding helps reproduce selected live-account structures in Stripe test mode. For a seed run, the operator supplies a one-shot live key with read permissions and a one-shot test key with the writes required in the sandbox. These keys travel to the backend executor as run arguments and are not inserted into the project’s stored Stripe-key records.

The live client is read-only by contract, while all seed writes target a Stripe test-mode account. The service validates key mode and permissions before work begins. Customer synchronization between two prepared sandboxes is a different operation and uses the stored test-mode source and destination keys. Keeping these paths distinct prevents a temporary seeding permission set from becoming the normal live-migration credential.

MoveMRR can enforce controls inside its product, but it cannot decide who in a transaction should authorize access. Buyer and seller should name the owners of the source account, destination account, application, cutover and incident channel. They should agree when keys may be created, who reviews dry-run evidence and who revokes access after the final reconciliation.

Application credentials, webhook signing secrets, local database permissions and staff access are separate from Stripe API-key storage. A complete SaaS handover needs an inventory for each of them. This page makes no claim of a certification, audit opinion or absolute protection against every security event. It describes current product behavior and links to the relevant platform guidance.