Stripe handoff after a SaaS acquisition: keep, migrate, or rebuild

Stripe is the question I get asked about more than every other handover topic combined. The reason is simple. Stripe does not allow account transfers between owners, and you cannot move customers from one Stripe account to another. PCI scope makes the export and import you wish existed legally impossible. So when you buy a SaaS with paying subscribers, you inherit a problem the docs do not really name.

This is the deeper version of what I wrote in the post acquisition checklist. If the deal you are closing has revenue attached, read this before signing.

Why this is hard

A Stripe account belongs to a legal entity. When the entity changes, Stripe expects a new account. Customers’ card details live in that account’s PCI vault, and you cannot dump them out, even if you are the new owner. Subscriptions, invoices, tax records, and dispute history all live with the original account.

Three real paths exist. Plus a fourth that sometimes makes sense. Pick before the wire goes out, because the price of the deal usually depends on which one you choose.

Option 1: keep the seller’s Stripe account temporarily

The simplest path on day one. The seller’s Stripe account keeps charging customers. You and the seller sign a side agreement that says payouts get forwarded to your bank account, either via a Stripe Connect platform split or via a manual ACH transfer at the end of each month.

What goes well with this option: zero customer disruption. Cards on file keep working. No re-authentication. No churn. You inherit the live MRR on day one, exactly as it was running.

What does not go well: you do not legally own the revenue. The seller’s entity is the one earning it. That creates a tax mess at year end, because the 1099 (or local equivalent) shows up under their name, not yours. Your accountant will need to treat the forwarded payouts as either a service fee paid by the seller to you, or a structured asset sale with deferred consideration. Both work, both add complexity.

The other risk is trust. The seller technically retains the ability to refund any charge, dispute any payout, or simply stop forwarding the money. I have not seen this happen on a Failedups deal yet, but I have seen the worry stop deals from closing. A short escrow on the final payment helps. So does a written agreement with a clear termination clause.

Realistic horizon: 30 to 90 days. Anything longer and the tax and ownership story gets uncomfortable enough that you should be migrating in parallel.

Option 2: scheduled migration to your own Stripe account

Cleanest legal outcome, real engineering work. The buyer creates a fresh Stripe account, then migrates each customer over by getting them to re-enter payment details on the new account.

The mechanics, in order:

1. Export the customer list from the seller’s account. stripe.customers.list paginated through all active subscribers, dumping ID, email, current plan, current period end, and any custom metadata into a CSV.

2. Build a re-authorization page on your domain that uses a Stripe Setup Intent against your new account. The customer logs in, clicks a button, enters their card, and you save the payment method against a new Customer object on your side.

3. As each customer re-authorizes, mirror their subscription on your account at the same plan and the same renewal date. Then call stripe.subscriptions.cancel on the seller’s account with cancellation_details.comment set to something like “Migrated to new billing account” so the audit trail is clean.

4. Send a final receipt explaining what just happened.

The email sequence matters more than any of the engineering. Three emails, friendly tone, clear value.

The first email lands two weeks before the cutoff. Subject is something direct like “Quick action needed for your [Product] subscription.” Explain the acquisition in two sentences. Explain what they need to do in one sentence. Include the re-authorization link prominently. Promise that nothing changes about the product.

The second email goes out one week later to anyone who has not clicked. Same tone. Add a sentence about what happens if they do not act, which is that their subscription pauses on [date]. Do not threaten. State the consequence calmly.

The third email is the day-of nudge. Short. “Your subscription pauses tomorrow unless you take 30 seconds to update your billing.” Re-authorization link as the only call to action.

Realistic conversion on a well-run sequence: 60 to 80 percent of subscribers re-authorize. The rest are churn you have to swallow. Run the migration at a natural billing cycle, ideally at the start of a month, so customers are in the right headspace to think about a recurring charge anyway.

Option 3: hard cutover and re-charge

Burn the boats. Set up a new Stripe account, cancel every subscription on the seller’s account on the same day, and email every customer asking them to sign up fresh on the new account. Whoever does, great. Whoever does not, gone.

This sounds reckless and sometimes it is the right answer. If the customer count is under 20, the engineering cost of a proper migration is not worth it. A clean break with a personal email to each customer often converts better than a templated migration flow anyway. You get a fresh start with clean tax records and no shared dependencies on the seller.

Buyers should price this option with a 30 to 50 percent expected loss. Sellers should accept that the price reflects that loss. Pretending otherwise is how deals fall apart in week three.

Option 4: Stripe Connect Standard

Worth mentioning, narrowly useful. The buyer sets up a Stripe Connect platform. The seller’s existing account becomes a connected Standard account underneath. Over time, customers reauthorize through the platform’s flow, which routes new charges to the platform with a transfer back to the connected account, or to a new connected account owned by the buyer.

This works if the underlying product is platform-shaped (think a marketplace where sellers were always going to be Connect accounts anyway). It does not work as a generic transfer trick. The complexity, the platform onboarding, and the application review with Stripe make this a multi-week project. I have seen it used twice on Failedups deals. Both were already heading toward a Connect architecture for product reasons.

Tax implications, briefly

I am not your accountant. Talk to yours. The short version: the entity earning the revenue is the entity that owes tax on it. If you are running option 1, the seller’s entity is technically earning, and the forwarded payout is either income to your entity (if structured as a service or referral) or part of the purchase price (if structured as deferred consideration). The structure matters for both sides. Get it in writing before the first payout lands.

Decision matrix

The honest version, after walking through this with enough buyers:

• Under 10 paying customers. Hard cutover. The engineering and email cost of a migration is not worth it. Personal outreach beats templates at this scale anyway.
• 10 to 50 paying customers. Scheduled migration at the next billing cycle. Three-email sequence. Accept 20 to 40 percent churn as the cost of clean ownership.
• 50 plus paying customers. Keep the seller’s account for 30 to 60 days, migrate at scale in parallel, settle up at the end of the window. The disruption cost of a same-day cutover is too high.

Pick the option before you sign. Build the email sequence before you flip the switch. Talk to your accountant before the first payout clears.

If you have not already, the post acquisition checklist covers the rest of the handover. Stripe is the hardest part. Domain, DNS, Supabase, transactional email, all easier once this one is decided.