Choosing a payment provider is one of the few early decisions that’s genuinely annoying to reverse. It determines who is legally selling your software, who owes sales tax in twenty jurisdictions, what your checkout looks like, and how much billing code you end up owning. Here’s how to make the call deliberately rather than by defaulting to whatever the tutorial used.
The decision that drives every other one: merchant of record
Almost everything else follows from a single question — who is legally the seller?
- You are (Stripe): you own the customer relationship, the data, and the compliance burden. You register for VAT/sales tax where you have obligations, file returns, and handle it as you grow.
- They are (Paddle, Lemon Squeezy, Polar): the provider sells your software to the customer and buys it from you. They collect and remit global tax, handle most chargebacks and fraud, and take a larger cut for it.
For a solo founder or small team selling internationally, a merchant of record is usually worth the extra percentage points — global digital-goods tax is a genuinely large ongoing chore. For a larger business with finance support, or one that needs deep control over billing logic, Stripe’s model wins.
The four in practice
Stripe — the most complete and flexible billing platform, the best documentation, and the broadest ecosystem. You get granular webhooks and can model nearly any pricing scheme. In exchange you own tax compliance (Stripe Tax helps calculate, but you still register and file), and you write more code.
Paddle — merchant of record with strong B2B support: invoicing, sales tax handled, fraud and chargebacks absorbed. Historically aimed at slightly larger or more B2B-shaped businesses. Less low-level control than Stripe, which is often the point.
Lemon Squeezy — merchant of record aimed at indie and small SaaS. Fast to set up, hosted checkout and license keys included, tax handled. Popular with solo founders who want to be selling this week.
Polar — developer-focused merchant of record, strong fit for open-source, API, and usage-billed products, with a modern event model and a good DX.
For how each provider affects referral tracking specifically, there’s a dedicated breakdown: Stripe vs Paddle vs Lemon Squeezy vs Polar for affiliates.
The seven things to actually compare
- Total cost, not headline rate. Add processing fees, cross-border and currency conversion fees, payout fees, and — for MoR providers — the tax handling premium. Then compare against what tax compliance would cost you in software and accountant time. The headline percentage is rarely the real number.
- Where your customers are. Local payment methods matter more than founders expect: SEPA in Europe, iDEAL in the Netherlands, and similar. A provider that doesn’t support your buyers’ preferred method silently costs you conversions.
- Subscription primitives you’ll need later. Trials, proration, plan changes, seat-based and usage-based billing, pause, dunning. Migrating because your provider can’t express your pricing is a bad reason to migrate.
- Dunning and involuntary churn. A meaningful share of SaaS churn is just failed cards. Retry logic and recovery emails are worth real money — check what’s included.
- Checkout experience. Hosted checkout is faster to ship and usually better-converting than something you build. Embedded gives you control. Decide which you need before you’re committed.
- Webhooks and data access. You’ll want subscription lifecycle events for analytics, entitlements, and referral attribution. Sparse or delayed events cause problems everywhere downstream.
- Exit cost. Can you export customers and migrate card data? With a merchant of record, the customer relationship is partly theirs — that’s the real lock-in, more than the code.
Quick guidance by situation
- Selling globally, small team, want to ship now → a merchant of record (Lemon Squeezy or Polar for indie scale, Paddle as you move upmarket).
- Complex or unusual pricing, or a finance function to lean on → Stripe.
- Open-source, API, or usage-billed product → Polar is built for this shape.
- Mostly domestic sales → the tax argument weakens considerably; Stripe’s control and fees usually win.
Don’t over-couple your stack to one provider
The practical lesson from teams who’ve switched: keep provider-specific logic behind a thin internal boundary. Your app should care about “subscription active” and “payment succeeded,” not about a particular provider’s object shapes.
This matters for anything built on top of billing events, referral tracking included. If your affiliate attribution is wired directly to one provider’s webhooks, switching billing means rebuilding the program and losing historical attribution. Qanary runs one attribution spine across all four providers for exactly this reason — the referral program survives a billing migration, and its usage-based pricing means it never takes a cut of affiliate revenue on any of them (the pricing comparison).
What to do first
Pick based on merchant of record and where your customers are — those two answers eliminate most options. Then ship the simplest checkout that works, keep your billing integration thin, and revisit in a year with real data on fees, failed payments, and where your revenue actually comes from.
Once payments work, the next lever is usually getting other people to sell for you: adding an affiliate program to a Stripe SaaS covers that setup, and the flow is similar on the other three.
FAQ
What is a merchant of record, and do I need one?
A merchant of record is the legal seller of your software, which means they collect and remit sales tax and VAT for you. It’s usually worth the higher fee if you sell internationally and don’t have finance support.
Is Stripe or Paddle better for SaaS?
Stripe gives more control and lower headline fees but leaves tax compliance to you; Paddle acts as merchant of record and handles global tax for a larger cut. Choose based on whether you want that compliance burden.
Can I switch payment providers later?
Yes, though it’s disruptive — card migration, subscription recreation, and rebuilding anything wired to provider-specific webhooks. Keeping billing logic behind a thin internal boundary makes it far less painful.
More provider comparisons are in the comparisons hub.