For Acquirers: What to Demand from the Seller on the Stripe Side When Buying a SaaS

When you are buying a SaaS, the deal reaches its most sensitive operational moment at cutover. This guide is written for acquirers who need to know what to demand from the seller on the Stripe side.

As an acquirer buying a SaaS, your primary objective is protecting recurring revenue. If the seller mismanages the Stripe transfer, your newly acquired customers will be double-billed, charged on the wrong dates, or cut off from service.

Most sellers assume Stripe has an automated button to transfer a subscription book between accounts. It does not. Stripe's Customer Data Copy moves saved credit cards, but leaves subscriptions, prices, and meters behind.

Here are the six operational requirements you should demand from the seller before releasing funds from escrow.

Demand 1: Read-Only Staging on the Seller's Account

Never allow a seller or external consultant to perform migrations using root Stripe secret keys. A single mistake with an unrestricted key can delete live data or trigger unwanted customer charges.

Demand that the migration architecture enforce separated, restricted API keys:

• Read-only source staging: The seller must connect a restricted key limited strictly to read permissions. During catalog replication and pre-migration scans, the seller's account must remain read-only.
• Isolated destination writes: You provide a restricted write key for your destination account that only allows creating products, prices, billing meters, and subscription schedules.
• Narrow cancellation key: Cancellation of the source subscriptions must use a separate restricted key uploaded only after you verify the destination schedules.

This isolation keeps the source account read-only until destination verification passes and limits each key to its stage.

Demand 2: Exact Renewal Date Alignment (No Immediate Subscriptions)

The greatest danger during an account transfer is double billing. If the seller creates active subscriptions in your destination account immediately, Stripe will charge the customers' cards today, even though the seller already collected payment for the current period.

Demand that the seller use Stripe subscription schedules anchored to real renewal dates.

The seller must:

1. Extract the current_period_end timestamp from every active source subscription.
2. Create a destination subscription schedule set to activate on that exact current_period_end date.
3. Attach the recreated price and the copied customer record.

By anchoring destination schedules to existing renewal dates, your destination account will only bill customers when the seller's paid service period concludes. Your business receives continuous recurring revenue without double-charging a single customer.

Demand 3: A 48-Hour Near-Renewal Buffer

Subscriptions that renew during the cutover window create severe operational hazards. If a customer's subscription renews in the seller's account while destination schedules are being deployed, billing webhooks race each other. This causes failed charges or duplicate billing.

Demand that the seller enforce a 48-hour buffer on renewals (DEFAULT_MINIMUM_START_BUFFER_HOURS = 48).

Any subscription scheduled to renew within 48 hours must be flagged for manual review and held outside the immediate migration batch. These subscriptions must be allowed to renew cleanly in the seller's account first. Once the renewal processes and the current_period_end rolls over to the next billing cycle, the subscription can be safely scheduled in your destination account.

In addition, demand that subscriptions with discounts or coupons, past-due or trialing status, existing schedules, manual tax rates, automatic-tax settings that need checking, missing default payment methods, or unusual item shapes be flagged for manual review.

Demand 4: Invoice Default Payment Method Repair

Stripe's Customer Data Copy transfers saved payment methods and customer records, but it frequently drops the customer's invoice default payment method pointer.

If an acquirer receives copied customers without default payment pointers, scheduled subscriptions will fail to collect payment on their renewal dates. The invoice will generate, find no default payment method, and mark the invoice past due.

Demand that the seller verify copied customers in the destination account and set the invoice default payment method where the copy dropped it. Setting this pointer ensures that every customer renews automatically without manual support intervention.

Demand 5: Verified Destination Schedules Before Source Cancellation

A seller should never touch their source subscriptions based on the assumption that destination writes succeeded.

Demand that the seller retrieve each created destination schedule from the Stripe API and verify:

• The destination customer ID matches the copied record
• The scheduled start date matches the source current_period_end
• Prices, currencies, quantities, and billing intervals match the original contract
• Automatic tax configurations match destination settings

Only after all destination schedules pass verification should the seller update source subscriptions. Furthermore, insist that the seller update subscriptions to cancel at period end (cancel_at_period_end: true). The seller must never cancel source subscriptions immediately. Cancelling at period end allows the existing paid period to finish naturally while your destination schedule waits for the renewal date.

Demand 6: Two-Party Sign-Off and a Closing Audit Packet

Do not accept verbal confirmations or Slack messages that a migration was completed. Require the seller to provide a formal audit packet for the acquisition closing binder.

A complete audit packet documents:

• Every source subscription ID and status
• The corresponding copied destination customer ID
• The created destination subscription schedule ID
• The verified renewal start date
• Records of any subscriptions held for manual review

Both buyer and seller must inspect and sign off on the plan before live writes occur. Having this audit packet protects you during post-closing accounting audits and provides an unambiguous record of the handoff.

Understand Your Responsibilities as the Acquirer

While SubPorter and the seller handle the Stripe Billing layer, certain technical tasks remain the acquirer's responsibility. Stripe tooling does not touch application code or infrastructure.

As the buyer, your engineering team must:

• Update application database records mapping existing users to new Stripe customer and subscription IDs
• Update Stripe secret API keys and publishable keys in your production environment
• Configure and point application webhook endpoints to the new Stripe account
• Verify user access entitlements in the application database

Maintaining a clear separation between Stripe Billing objects and application backend tasks ensures that both engineering teams execute their responsibilities cleanly.

Tooling and Pricing Considerations

When evaluating migration tooling with your seller, consider the economics.

MoveMRR charges a fee that grows with your subscription count and MRR according to a published formula. For very small migrations, MoveMRR can be cheaper at base list prices. However, above roughly 300 subscriptions, SubPorter's flat price is lower.

SubPorter provides transparent, flat pricing:

• Small Exit: $99 one-time fee for up to 100 subscriptions.
• Standard: $199 one-time fee for migrations above 100 subscriptions.
• Free planning: Pre-migration planning, review scans, and sandbox runs are completely free. You only pay before live billing writes begin.
• Founding offer: For the first 5 customers, the founder joins the cutover call live to oversee the migration.

SubPorter was built by a founder who moved 30 subscriptions during a $10k exit. The scripts and verification checks created during that sale became SubPorter's core product.