For acquirers
For Acquirers: What to Demand from the Seller on the Stripe Side When Buying a SaaS
For acquirers buying a SaaS: six requirements to put to the seller on the Stripe side before funds leave escrow.
· Simon Liang
When you are buying a SaaS, the Stripe migration is the most sensitive operational moment of the deal. This guide is for acquirers. It lists what to require from the seller on the Stripe side before funds leave escrow.
Your goal is to protect the recurring revenue you are buying. A mismanaged migration double-charges your new customers, charges them on the wrong dates, or cuts them off.
Most sellers assume Stripe has a button to transfer a subscription book. It does not. Stripe's customer copy moves saved cards. Subscriptions, prices, and meters stay behind.
Requirement 1: Read-only access to the seller's account
Never let a seller or a consultant run the migration with a secret key. One mistake with an unrestricted key can delete live data or charge customers.
Require three restricted keys:
- A read-only key on the source account, for the scan and the plan.
- A write key on your destination account, which can only create products, prices, meters, customers, and subscription schedules.
- A cancellation key on the source account, created only after you have verified the schedules, which can only set subscriptions to cancel at period end.
Requirement 2: Schedules that start on the renewal date
The biggest danger is the double charge. If the seller creates active subscriptions in your account today, Stripe charges the cards today, even though the seller already collected this period.
Require subscription schedules. For each source subscription, the seller reads current_period_end and creates a destination schedule that starts on that exact date, with the copied customer and the recreated price. Your account bills only when the seller's paid period ends.
Requirement 3: Renewals within 48 hours are held
A subscription that renews during the migration collides with it. Require that any subscription renewing within 48 hours is flagged, left to renew in the seller's account, and moved in a later pass.
Require the same for coupons, trials, past due, existing schedules, manual tax rates, missing payment methods, and unusual items: a decision for each, not a batch.
Requirement 4: Default payment methods checked
Stripe's copy sometimes drops the invoice default payment method. A customer with a card but no default fails to pay when the schedule starts. Require that the seller verifies every copied customer in your account and sets the default where the copy dropped it.
Requirement 5: Verified schedules before any cancellation
The seller must not touch the source subscriptions on the assumption that the writes worked. Require that every schedule is read back and checked:
- The destination customer ID matches the copied record.
- The start date matches the source
current_period_end. - The price, currency, quantity, and interval match the contract.
- The tax settings match your account.
Only then may the seller set the source subscriptions to cancel_at_period_end: true. Never immediately. The paid period finishes, and your schedule starts at that moment.
Requirement 6: Migration records both owners keep
Do not accept a chat message that the migration is done. Require migration records for the closing binder:
- Every source subscription ID and status
- The copied destination customer ID
- The destination schedule ID
- The verified start date
- The decision on every flagged subscription
Both owners review the plan before the first write and keep the same records after.
Your responsibilities as the acquirer
Stripe tooling does not touch your application. Your engineering team must:
- Update the application database with the new customer and subscription IDs
- Switch the Stripe API keys in your deployments
- Point the webhooks at the destination account
- Check entitlements for every user
Tooling and price
MoveMRR's fee rises with subscription count and MRR. For a very small migration it can cost less at list price. SubPorter charges $99 for migrations with up to 100 active subscriptions and $199 for more than 100, one-time, with free planning and sandbox migrations. For the first five customers, the founder is in the project chat during the final steps.
SubPorter runs all six requirements as gates in a migration project. It was built by a founder who moved 30 subscriptions during a $10,000 sale.
Frequently Asked Questions
What should an acquirer require from the seller on the Stripe side?
- Read-only access to the source account, schedules that start on each renewal date, a hold on renewals within 48 hours, verified default payment methods, verified schedules before any cancellation, and migration records for the closing binder.
Does Stripe’s customer copy transfer the MRR to the buyer’s account?
- No. It moves customer records and saved cards only. The subscriptions must be recreated in the buyer’s account as schedules before any revenue arrives there.
How does an acquirer check that copied customers can pay?
- Open the copied customers in the destination account and check that each has an invoice default payment method. Where the copy dropped it, set it from the copied payment method before any schedule is created.
What are migration records for?
- They list every source subscription, copied customer, destination schedule, verified start date, and decision. They give finance and both owners the same record of what moved and when.
What stays the buyer’s technical job?
- Updating the application database with the new customer and subscription IDs, switching the Stripe API keys, pointing the webhooks at the destination account, and checking entitlements.
Plan the Stripe migration before closing.
Open a migration project to review the source account, the destination account, the flagged subscriptions, and the verified schedules together with the seller.