DEV Community

Nico
Nico

Posted on • Originally published at keylight.dev

Stripe vs Paddle vs Lemon Squeezy for Indie Developers

Originally published on the Keylight blog.

If you are an indie developer about to charge for an app, you have three names in front of you: Stripe, Paddle, and Lemon Squeezy. They get discussed as if they are the same kind of choice. They are not. This post lays out the real differences so you can pick deliberately.

They are not the same kind of thing

The single most important distinction is processor versus merchant of record.

Stripe is a payment processor. It moves money from your customer's card to your bank account. You are the legal seller. The customer relationship, and the sales-tax liability, are yours.

Paddle and Lemon Squeezy are merchants of record. They are the legal seller of your product. The customer's receipt comes from them. They calculate, collect, and remit sales tax and VAT worldwide, then pay you the remainder. You are, in effect, a supplier selling through their storefront.

Everything else — fees, customer ownership, lock-in — flows from this one difference.

Fees

Stripe: about 2.9% + $0.30 per card charge (US card pricing; rates vary by country, card type, and Stripe products used). On a $49 sale, roughly $1.72.

Paddle: approximately 5% plus the underlying payment fee. On that $49 sale, closer to $2.45-$2.75.

Lemon Squeezy: 5% + $0.50 per transaction. On $49, roughly $2.95.

Stripe is plainly the cheapest on raw processing. But the merchant-of-record fee is not pure overhead — it is buying tax compliance. To compare honestly, you have to price that in.

Tax compliance: the real tradeoff

Paddle and Lemon Squeezy handle sales tax and VAT for you, everywhere. If you sell to a customer in Germany, Australia, or California, they apply the right rate, collect it, and remit it. You never think about it.

With Stripe, that is your responsibility. The practical answer is Stripe Tax — built into Stripe Checkout, about 0.5% of the transaction — or a third-party tool like Quaderno or TaxJar. These work well, but they require setup and occasional maintenance as rules change.

So the fair comparison is not 2.9% vs 5%. It is roughly 2.9% + 0.5% tax + a small licensing cost for the Stripe path, versus ~5% all-in for a merchant of record. At meaningful revenue the Stripe path is still cheaper — and below tax thresholds, cheaper still. But it is not hands-off the way a merchant of record is.

Customer ownership

With Stripe you own the customer: email, billing history, subscription status, all exportable. You can email customers, run win-back campaigns, and migrate processors if you ever need to.

With Paddle or Lemon Squeezy, the customer is theirs. Your invoice shows their name. How much customer data flows back to you is governed by their terms, and those terms can change. Migrating away later is a renegotiation, not an export.

For a product you plan to support for years, an owned customer list is a genuine business asset. For a first product or a small catalogue, the difference matters less.

Licensing is a separate question

Here is the part the comparison usually misses: none of these three issues license keys in the sense a desktop app needs.

A desktop app needs a key it can verify offline — a cryptographically signed entitlement, checked locally with no server call. Stripe has nothing for this; it is a payment processor and stops at the payment. Paddle and Lemon Squeezy each have a license-key feature, but it is tied to their platform and oriented around an online validation API, not offline signature verification.

So whichever of the three you choose for payments, licensing is a separate layer. The clean architecture is: a processor for payments, and a licensing layer for keys, connected by webhooks. In code, the licensing half looks the same regardless:

import KeylightSDK

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:    enablePaidFeatures()
case .trial(let d): showTrialBanner(daysLeft: d)
case .expired:     showRenewalPrompt()
case .invalid:     showActivationSheet()
}
Enter fullscreen mode Exit fullscreen mode

Which to choose

Choose Stripe if you want the lowest fees, full customer ownership, and you are willing to add a tax tool. At any meaningful revenue this is the strongest long-term position. Pair it with a licensing layer for keys.

Choose Paddle or Lemon Squeezy if you want the simplest possible setup, you sell globally from day one, and you genuinely do not want to think about tax. You pay more and give up the customer list in exchange for never handling compliance. Between the two, Lemon Squeezy leans toward a friendlier indie experience; Paddle toward more established tooling.

For most indie developers building a paid app to support for years, Stripe plus a licensing layer wins. For a first product where simplicity beats everything, a merchant of record is a defensible call. If you would like a deeper comparison on any one of these, send us your feedback.

FAQ

Which is cheapest: Stripe, Paddle, or Lemon Squeezy?

Stripe has the lowest processing fee at about 2.9% + $0.30. Paddle and Lemon Squeezy charge around 5% because their fee bundles global tax compliance. Adding a tax tool to Stripe usually still totals less.

What is the difference between a payment processor and a merchant of record?

A payment processor like Stripe moves money while you remain the legal seller. A merchant of record like Paddle or Lemon Squeezy is the legal seller, assuming sales tax and VAT liability on your behalf.

Do any of them handle license keys?

None of them issue cryptographically signed license keys an app verifies offline. Paddle and Lemon Squeezy offer platform-tied key APIs; Stripe has none. Licensing is a separate layer.

Top comments (3)

Collapse
 
johnfrandsen profile image
John Frandsen

Solid breakdown. One thing missing from the comparison that European indie developers should know about: Pay by Bank via PSD2 Payment Initiation Services (PIS) is emerging as a fourth option that sidesteps card fees entirely.

The unit economics are dramatically different. Stripe charges ~2.9% + $0.30 per card transaction. European PIS providers charge roughly 0.1–0.5% per payment because there's no card network involved — the payment goes directly from the customer's bank account to yours via SEPA Instant or Faster Payments. On a €49 sale, that's €0.05–0.25 vs €1.72 with Stripe. For a subscription business doing €10k/month in EU volume, the difference is hundreds of euros every month.

The tradeoffs are real, though:

  • Irrevocable payments. Bank transfers can't be chargebacked. Good for reducing fraud/dispute risk, but you lose the consumer protection angle that makes cards feel safe to buyers. Refunds are manual.
  • Integration friction. You're not integrating a single API — you're going through a PIS aggregator (TrueLayer, GoCardless, Tink) that normalises 4,000+ European bank APIs behind one interface. It works, but the developer experience isn't as polished as Stripe Checkout.
  • EU/UK only. PIS is a PSD2/PSR regulatory construct. No equivalent in the US yet (though the CFPB's Section 1033 rule may change that). If your customers are global, you still need a card processor.

For an indie developer selling primarily to European customers — especially B2B SaaS or higher-ticket digital products — routing domestic payments through Pay by Bank and falling back to Stripe for international/card customers is worth the extra integration work. The fee savings compound fast at scale.

The licensing point you raise is interesting too — PIS payments don't solve the offline license key problem either, but they do give you full customer ownership with no merchant-of-record lock-in, since you're the direct payment initiator.

Collapse
 
nicodemanez profile image
Nico

Hi John! Interesting, contact me if you are working on one of those products, we can integrate it to Keylight.dev :)

Collapse
 
johnfrandsen profile image
John Frandsen

Hi Nico! Thanks for reaching out.

Yes — I maintain open-banking.io, a cert-free EU bank-data API. It's mostly on the account-information side (read-only bank data under PSD2), and the Pay-by-Bank / PIS angle I mentioned above is where it's heading. The core wedge: EU open banking normally needs a €5–15k/yr eIDAS QWAC certificate plus a 6–12 month AISP authorisation, which prices indie devs and small SaaS out entirely — open-banking.io strips that barrier out.

Genuinely happy to explore how it could plug into Keylight.dev. Easiest is to drop me a line at john@open-banking.io (or we keep going here) and I'll walk you through the integration surface. What's the use case you have in mind?