Stripe Managed Payments vs. Paddle: Why I'm Choosing the More Expensive One
I wrote a general guide to PSPs and Merchants of Record some time ago. This is the follow-up where I stop being neutral and actually decide, for my own SaaS, running on an EU entity that bills through Stripe today.
The short version: on my US-weighted card mix, Stripe Managed Payments costs me more than Paddle would. I am going with it anyway, and the reasoning has nothing to do with the take rate.
The comparison everyone runs is "which MoR has the lower fee." That is the wrong comparison, because the two options are not the same decision. One is a flag on an integration I already run. The other is moving my business onto a reseller.
1. What Managed Payments Actually Is
Stripe's merchant-of-record product. Stripe becomes the legal seller, handles indirect tax calculation, registration, filing and remittance in 80+ countries, absorbs fraud and dispute management, and provides transaction-level customer support.
One detail that the comparison posts consistently skip, and that materially changes how you should think about it: the merchant of record is not "Stripe" as your customer understands the word. Transactions are acquired by Stripe Payments Company or Stripe Technology Europe Limited, but the customer-facing entity is Link. Your buyer checks out through Link, sees the purchase described as "Sold through Link", gets receipts and invoices from Link, manages the subscription at link.com, and sees this on their card statement:
LINK.COM* YOUR DESCRIPTOR
That is the same brand interposition problem Paddle has. Arguably it is worse, because Paddle is at least a known name in B2B software billing, whereas Link reads to most people as a consumer wallet. If your buyer is a finance person reconciling a statement, LINK.COM* is a support ticket waiting to happen.
2. The Fee Stack, Honestly
Managed Payments is 3.5% per transaction in addition to standard Stripe processing fees. Not instead of. It stacks on top of everything, including international card fees and currency conversion. Stripe's own documentation confirms the layering with worked examples.
So from an EU entity, here is what the actual all-in rate looks like against Paddle's flat 5% + 50¢:
| Transaction | Stripe Processing | + Managed Payments | All-In | Paddle |
|---|---|---|---|---|
| EEA card | 1.5% + €0.25 | 3.5% | 5% + €0.25 | 5% + 50¢ |
| UK card | 2.5% + €0.25 | 3.5% | 6% + €0.25 | 5% + 50¢ |
| US card | 3.15% + €0.25 | 3.5% | 6.65% + €0.25 | 5% + 50¢ |
Note what is not in that table: the 2% currency conversion fee. On ordinary Stripe Payments, charging a US customer in dollars and settling in euros costs you that 2% on top, which would put a US card at 8.65%. Managed Payments enables Adaptive Pricing by default, and under Adaptive Pricing Stripe's position is explicit: "You pay 0%". The merchant receives settlement in their integration currency and the conversion fee is not charged to them.
That distinction is worth getting right, because it is the single largest number in this decision and the naive stack is an easy mistake to make. If you see a comparison quoting Stripe's MoR at over 8% for an EU seller, this is what it missed.
It does not mean conversion is free, though. It means it moved. Stripe embeds a 2-4% conversion fee in the exchange rate shown to the customer, so your US buyer pays 2-4% above your EUR-equivalent list price. That is invisible on your Stripe statement and very visible on your price page. A customer who prefers can elect to pay in your original currency and absorb their own bank's spread instead. Paddle localises prices too, so this is a wash between the two rather than a point against either.
So the real gap on US cards is 6.65% against 5%. That is 1.65 points, worth roughly €8,250 a year at €500k of US ARR and €16,500 at €1M. Real money, but a fraction of what the naive arithmetic suggests.
Parity happens on EEA cards, where Stripe's 1.5% base is so cheap that even a 3.5% surcharge lands at Paddle's number. And EEA volume is precisely the revenue where I do not need an MoR at all, because I already hold the registrations and OSS covers it.
3. So Why Am I Still Choosing It
Because it is per-transaction, and Paddle is all-or-nothing
This is the argument that carries the decision. Managed Payments is a parameter on a Checkout Session. I can enable it on the transactions where MoR coverage is worth paying for and leave everything else on my direct 1.5% EEA rate.
Paddle does not work that way. Adopting Paddle means Paddle becomes the seller for your whole book. So the honest comparison is not 6.65% against 5% on one transaction. It is a blended rate where I route the messy international long tail through an MoR and keep my home-market margin, against a flat 5% applied to everything including the EEA revenue I currently process at 1.5%.
Run that on a book that is meaningfully EEA-weighted and the flat-5%-on-everything option stops looking cheap very quickly. Run it on a book that is overwhelmingly US-converted and Paddle wins outright. The answer genuinely depends on your mix, which is why "which MoR is cheaper" has no general answer.
Because migrating to Paddle costs more than the fee difference
Card tokens are not portable between merchants of record. Moving an existing subscriber base to Paddle means pushing every active customer through a re-checkout, and you do not get all of them back. Assume even a modest single-digit churn spike on that migration and it dwarfs the annual fee delta, except it is permanent revenue rather than a recurring cost you can reverse.
Managed Payments has no migration. My subscriptions, customers, invoices, webhooks and reporting stay as Stripe objects in the account I already run.
Because it is reversible
Turning Managed Payments off is a code change. Leaving Paddle is a project with customer attrition attached. When I am this uncertain about my own cost model, an option I can back out of is worth paying a premium for. That asymmetry is the actual product here.
Because Stripe Tax comes free where the MoR does not cover you
Managed Payments does not cover every country. Where it cannot assume tax liability, you remain responsible, but Stripe Tax calculation is included at no additional charge on those transactions. For an EU seller the coverage is good: all 27 member states for cross-border, plus the US, UK, Canada, Australia and most of APAC.
4. What I Am Accepting In Exchange
These are from Stripe's documentation, not from competitor comparison pages, and several of them would be dealbreakers for a different product.
- Checkout and Payment Links only. No Elements, no embeddable web components, no advanced integrations. If you have built a custom checkout, adopting Managed Payments is a rebuild, and that rebuild cost belongs in your comparison.
- You cannot create a subscription outside of Checkout or Payment Links. Programmatic subscription creation is out.
- No invoice items on a Customer, no one-off invoices outside the billing period. This kills a lot of usage-based and enterprise invoicing patterns outright.
- No custom domain on the checkout page.
- Stripe Tax only. Third-party tax integrations are not supported, so Avalara, Anrok and TaxJar are off the table.
- The 48-hour rule. If Stripe escalates a support case to you and you do not respond within 48 hours, Stripe may issue a refund without your approval. That is a real transfer of control over your own revenue.
- Refunds cost you the tax. The customer is refunded in full, but in some jurisdictions Stripe must still remit the original tax, and your balance is reduced accordingly.
- Disputes are handled, not free. You still pay the dispute received fee and the dispute prevention tooling. Stripe covers the evidence submission fee only when it submits on your behalf.
- Eligibility is conditional and revocable. Continued access requires a low dispute rate and clean risk history.
- Digital products only, with no human in the loop. Physical goods, professional services such as consulting or development, and live in-person events are excluded. Stripe is explicit that a service involving human intervention, live 1-1 coaching being their example, does not qualify. You also have to assign an eligible product tax code to everything you sell.
- No Connect. Platforms, marketplaces, Express accounts and platform-controlled accounts are all ineligible.
- Data deletion cascades into your account. If a customer requests deletion, Stripe cancels their Managed Payments subscriptions and deletes the associated Customer, Subscription, Invoice, PaymentIntent and Charge objects from your Stripe account.
5. Where Paddle Is Genuinely The Better Answer
I do not think Managed Payments is the better MoR. I think it is the better option for my specific situation. Paddle wins on:
- Price on non-EEA volume, and price you can actually predict. One flat number beats a stack that moves with your customers' card geography.
- Software-specific billing machinery: licensing, dunning, failed-payment retry logic, cart abandonment recovery, customer billing portals. Stripe expects you to buy Billing separately and build the rest.
- Invoicing and B2B flows, where Managed Payments' restrictions bite hardest.
- Maturity. Paddle has run a tax function across this many jurisdictions for years. Managed Payments is new, and "Stripe will figure it out" is a belief, not a track record.
6. The Decision Rule
flowchart TD
A{"Existing subscriber base
on a PSP?"}
A -->|"Yes, meaningful MRR"| B["Managed Payments
(migration cost dominates)"]
A -->|"No, greenfield"| C{"Card mix?"}
C -->|"EEA-weighted"| D{"Custom checkout
or invoicing needs?"}
C -->|"US / non-EEA weighted"| E["Paddle
(1.65pt gap on US cards)"]
D -->|"Yes"| E
D -->|"No"| F["Managed Payments
(composable, reversible)"]
Put plainly. If you already have revenue running through Stripe, the migration cost swamps the fee difference and Managed Payments wins almost regardless of the arithmetic. If you are greenfield and US-weighted, Paddle is cheaper and you should take the cheaper option. If you are greenfield and EEA-weighted, it turns on whether Managed Payments' integration constraints are survivable for your product.
7. What I Would Still Confirm
One piece of the fee stack is not spelled out anywhere public: whether the full 3.15% international card rate applies unchanged under Managed Payments. Adaptive Pricing does not alter where a card was issued, so it should, but the interaction between the two is not documented and it is worth two points on my largest revenue segment. I am getting that in writing from Stripe before I move volume.
Which is the real lesson, and it is the same one as the last post: do not adopt anyone's conclusion here, including mine. Get your card mix out of your processor, put your own numbers into the table in section 2, and add the migration cost that only applies to you.