Stripe Managed Payments: The Merchant-of-Record Fee Is 6.4%. The Churn Cost Isn't on the Pricing Page.

Stripe Managed Payments went generally available at Sessions 2026 in April, and it's been expanding steadily since — Stripe added Australia in preview in August, bringing the total to 39 countries where a business can operate as a Managed Payments merchant. The pitch is simple: stop being the legal seller of record for your own product. Stripe collects the payment, remits sales tax and VAT across more than 80 countries, fields the chargebacks, and handles customer support for billing questions. For a small SaaS team without a finance function, that's real relief.

What doesn't show up in that pricing conversation is what happens to the subscribers you already have. Becoming a merchant of record isn't a billing settings change — it's a change of legal seller. And a change of legal seller has consequences for every card already on file.

Why the fee number and the churn number are two separate decisions

Most teams evaluating Managed Payments run the math as a pricing comparison: is a 2–3 point fee premium worth not having to register for VAT in Germany and GST in Australia. That's a reasonable question, and it usually favors self-managed Stripe once you're past the smallest revenue tiers. But it's the wrong question to answer alone, because it treats the migration as a pricing event rather than the mass re-authentication event it actually is for anyone with existing subscribers on file.

Rates compiled from Stripe's published Managed Payments pricing, Paddle's public fee schedule, and FastSpring comparison writeups (Dodo Payments, Checkout Page, 2026). FastSpring's rate is sales-negotiated and varies by volume.

Notice the pattern in the last column: every merchant-of-record option, not just Stripe's, breaks card-on-file continuity the moment the legal seller changes. This isn't a Stripe-specific flaw — it's inherent to what "merchant of record" means. The card network authorized your customer's bank to let a specific, verified merchant charge that card. Swap the merchant, and that authorization doesn't automatically follow.

Why PAN import doesn't save you here

Stripe already has a well-worn path for moving saved cards between accounts: PAN import. Request your data from the losing processor, hand it to Stripe, and within about 10 business days you get a mapping file linking old payment method IDs to new ones — no customer action required. It's the process behind most of the "migrate to Stripe painlessly" guides floating around, and it works well because both ends of the migration are the same legal entity: you, before and after.

Managed Payments breaks that assumption. Freemius — a WordPress plugin licensing platform that runs its own merchant-of-record service and has written critically about Stripe's — put it plainly in a 2026 analysis: payment method tokens don't transfer to a merchant of record, so subscriptions need to be re-authorized and payment details re-entered, and that re-authentication step is exactly where involuntary churn shows up. The card token that's valid for "your company, Inc." as the merchant isn't valid for "Stripe, as merchant of record for your company" — even though the customer sees the same product and, ideally, the same familiar billing descriptor.

What a mass re-authentication event actually looks like

Compare this to ordinary involuntary churn. A card expiring or getting declined for insufficient funds happens to a trickle of your subscriber base every month — a few percent, spread across the billing cycle, which is exactly why dunning and Smart Retries work: the volume is small and continuous, so a retry schedule and a card-expiry email can absorb it. A merchant-of-record migration doesn't trickle. It hits your entire active subscriber base at once, all needing to take the same action inside the same migration window, regardless of when their card happens to expire.

That's the same mechanism behind involuntary churn generally — a customer who never decided to leave, losing access because a payment step failed — just compressed into a single week instead of spread across a year. Run it badly and you can turn a rounding-error-sized involuntary churn rate into a visible dent in MRR inside one billing cycle, on customers who were perfectly happy paying you the day before.

Running the migration without re-churning your base

None of this means Managed Payments is a bad product — for a solo founder drowning in EU VAT registrations, offloading that entirely can be worth a meaningfully higher take rate. It means the migration needs to be planned as its own project, separate from the tax and fee decision:

• Run both merchants in parallel. Keep existing subscriptions billing under your current setup and route only new signups through Managed Payments at first. This turns a hard cutover into a gradual transition as your existing base naturally churns and renews over time.
• Treat the re-auth request like a dunning campaign, not a one-off email. A single "please update your payment method" email gets ignored at roughly the same rate as a first dunning notice. Sequence it: an early heads-up explaining why (with the tax/compliance framing, which customers generally accept), a reminder as the cutover date approaches, and an in-app banner for anyone who logs in without having acted.
• Give it a real grace period, not a hard cutoff. Subscriptions that haven't re-verified by the cutover date should move to a past-due-style state with continued retry attempts, not an immediate cancellation — the same pause-instead-of-cancel logic that recovers far more accounts than an outright drop.
• Check the country list before you commit. Managed Payments still doesn't cover some large markets — Brazil, India, South Korea and Turkey among them as of this writing. If a meaningful slice of your revenue comes from a country it doesn't support yet, you'd be running two billing systems in parallel indefinitely, not migrating once.

Where this leaves the pricing decision

The honest framing is that Managed Payments and self-managed Stripe Billing aren't really competing on price — they're trading a fee premium for offloaded tax compliance work, and that trade can be worth it depending on your footprint. What's missing from most comparisons, including the vendor's own, is that the migration itself carries a cost measured in subscribers, not basis points, and it's a cost you control almost entirely through how carefully you sequence the re-authentication rather than through anything Stripe does on its end.

If you're weighing whether the fee premium pencils out, our churn calculator is worth running with two scenarios: your current involuntary churn rate, and a one-time spike modeling what even a partial failure-to-reauthorize rate would do to a single month's MRR. For SaaS teams already thinking about cross-border payment failures or running more than one processor, a merchant-of-record migration is one more payment-identity change layered on top — worth mapping out before committing to a cutover date, not after. And whatever the migration does to your involuntary churn in the short term, a clear cancellation flow on the other side still matters just as much — customers who do successfully re-authenticate are exactly the ones you don't want losing over a confusing exit experience six months later.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.