Merchant of Record in 2026: Stripe, Paddle, Polar, and the Lemon Squeezy Question Nobody Wants to Answer

Merchant of Record in 2026

The first time I sold software to someone in Germany, I did not think about VAT for even one second. I thought about whether the webhook fired.

That is the default state of most developers shipping their first paid product, and it is fine right up until it is not. The moment your Stripe dashboard has customers in eleven countries and your revenue crosses the point where somebody might actually care, you discover that "collect the money" and "be legally allowed to have collected the money" are two different projects, and you only built one of them.

Merchant of record providers exist to sell you out of the second project. They become the legal seller. They collect and remit the tax. They handle the chargebacks and issue the compliant invoices. You get one payout and one problem instead of forty.

Three things changed in 2026 that make this decision worth revisiting even if you settled it last year. Polar raised its headline rate by 25%. Lemon Squeezy is being absorbed into Stripe's own MoR product. And Stripe Tax got good enough that the "just use Stripe" answer is now genuinely correct for a bigger slice of founders than it used to be.

Here is the actual math, and the part most comparison posts skip: when the MoR tax is not worth paying.

What a Merchant of Record Actually Buys You

Strip the marketing off and an MoR sells you exactly one thing: they become the legal seller of record, so the tax obligation is theirs and not yours.

In practice that unbundles into a handful of chores you stop doing.

Sales tax and VAT registration. The EU wants VAT on digital goods sold to EU consumers, at the customer's local rate, remitted through a scheme you have to register for. The UK wants its own. Over 40 US states now have economic nexus rules for SaaS. Some of those thresholds are low enough that a modest product trips them without you noticing.

Filing. Registration is the easy half. Filing quarterly returns across multiple jurisdictions, forever, is the half that eats weekends.

Invoices that satisfy an accountant. B2B customers in the EU want a VAT-compliant invoice with your VAT number and theirs, reverse-charged correctly. "Here is a Stripe receipt" gets you an email from their finance department.

Chargebacks and fraud liability. With an MoR, the dispute is against them, not you.

The pitch is that this is worth about 5% of revenue. Whether it is depends almost entirely on where your customers are and how much money you are making, and that is the calculation nobody runs before signing up.

The 2026 Fee Landscape, Honestly

Here is where the four main options actually sit as of this month.

Stripe (not an MoR). 2.9% + $0.30 for cards, plus Stripe Tax at roughly 0.5% per transaction if you enable it. Stripe Tax calculates and tracks thresholds for you, and it tells you when you have crossed a registration threshold somewhere. It does not register or file for you. You are still the seller. Effective cost around 3.4%.

Paddle. 5% + $0.50, true merchant of record. The deepest platform of the group for actual subscription businesses, with real dunning and failed-payment recovery through Retain. If you have a subscription product past the hobby stage, Paddle is the one built for you rather than adapted to you.

Polar. This is the one that changed. Polar spent two years being the developer-first MoR with a flat 4% + $0.40, which was genuinely the cheapest real MoR on the market and got recommended everywhere on that basis. In 2026 they moved to a tiered model where the free Starter tier is 5% + $0.50, matching Paddle and Lemon Squeezy. To get back to the old economics you subscribe to a paid plan on top: Pro at $20/mo, Growth at $100/mo, Scale at $400/mo. Organizations created before May 27, 2026 keep 4% + $0.40 on a grandfathered Early Member plan indefinitely.

That is a 25% increase on both the percentage and the fixed fee for anyone who signs up today on the free tier. It does not make Polar a bad choice. It does make every 2025 blog post recommending Polar "because it is 20% cheaper" out of date, and those posts are still the ones ranking.

Lemon Squeezy. 5% + $0.50, acquired by Stripe in 2024, still running as its own product with its own dashboard and API. Pricing has not changed since the acquisition. Here is the part that matters: in January 2026 Lemon Squeezy announced Stripe Managed Payments, which is Stripe's own merchant of record product, built by the Lemon Squeezy team. Their CEO has publicly called it "the future" and said the goal is to give Lemon Squeezy users an easy path to migrate over.

No shutdown date has been announced. New signups are still open. But you would have to work quite hard to read that as anything other than a product on a glide path into a bigger one.

The Math Nobody Runs Before Signing Up

Take a product doing $2,000 MRR, average subscription $20/month, so 100 customers.

On Stripe with Stripe Tax: 2.9% + $0.30 per transaction is $0.88 per $20 charge, times 100 is $88. Stripe Tax adds roughly $10. Call it $98 a month, or 4.9% all in, because the fixed fee bites hard at a $20 price point.

On a 5% + $0.50 MoR: $1.50 per transaction, times 100 is $150 a month, 7.5% all in.

The MoR is costing you about $52 a month more, which is $624 a year. That is the number to hold in your head, because the real question is not "is 5% a lot." The question is whether $624 a year buys you more than the alternative use of that money and time.

If you are US-only selling to US customers, the answer is usually no. Stripe Tax handles US sales tax calculation, you register in the handful of states where you actually have nexus, and a bookkeeper handles the filings for less than $624 a year. Stripe is the right answer and it is not close.

If you have EU consumers, the answer flips fast. EU VAT on B2C digital goods starts at the first euro. There is no threshold to hide behind. Registering for the one-stop shop scheme, tracking rates across member states, and filing quarterly is either your weekend or your accountant's invoice, and either way it costs more than $624 and is more annoying than $624.

Now run the same math at $20,000 MRR. The MoR premium is now roughly $520 a month, $6,240 a year. At that size you can afford a real accountant and the MoR is starting to look like a subscription to a service you have outgrown. This is exactly the shape of decision I wrote about in pricing for indie hackers: the answer that is obviously right at one scale is obviously wrong two zeros later, and most people never revisit it.

The Thing That Actually Decides It: Your Customer Geography

Everything above collapses into one question. Where do your customers live, and are they businesses or consumers?

US-only, B2B. Use Stripe. Stripe Tax at 0.5% per transaction, register where you have nexus, done. B2B in the US is mostly exempt or resale-certificate territory anyway, and you get the best API in the industry as a bonus.

US-only, B2C. Still Stripe, probably. Watch the state nexus thresholds. Stripe Tax will tell you when you cross one.

Global, B2C. Use an MoR. This is the case they were built for. EU VAT with no threshold, UK VAT, and a dozen other regimes that all want their cut of a $9 subscription is not a problem you should be solving personally.

Global, B2B. Genuinely ambiguous. B2B in the EU is largely reverse-charge, meaning the customer self-accounts for VAT if they give you a valid VAT number. You still need to validate those numbers and issue correct invoices, which an MoR does for you. But the tax burden is smaller than the B2C case, so the 5% buys you less.

Selling to developers. Polar was purpose-built for this crowd and it shows in the API and the usage-based billing. If you were created before the May cutoff you are grandfathered at the old rate and should probably stay put.

Notice that "which platform has the nicest dashboard" did not appear anywhere in that list. It is the criterion people actually decide on and it is nearly irrelevant.

The Migration Cost Everyone Underestimates

The reason to get this right early is that switching later is genuinely painful, and the pain is not in the code.

Moving payment processors means migrating active subscriptions. Card details are held by the processor and are not always portable. Some migrations require every customer to re-enter their card, which means an email campaign asking your paying users to take an action, which means you will lose a percentage of them who never open it. I have watched founders lose 10 to 15% of their subscriber base to a "we're switching billing providers, please update your card" email, and no amount of good copy fixes it entirely.

You also lose your dunning history, your Stripe risk profile, and every integration built against the old webhook shape. If you have written any real logic around subscription lifecycle events, and you should have, that logic is provider-shaped. I wrote a whole post on handling Stripe webhooks in production and roughly none of it transfers cleanly to a different provider's event model.

So the practical advice is: pick based on where you expect customers to be in eighteen months, not where they are on launch day. If you are pretty sure you will end up with EU consumers, start on an MoR even if month one is all US traffic. The 5% on your first $500 of revenue is $25. The migration later is a weekend plus churn.

When Not To Bother With Any of This

Here is the section the comparison sites will not write, because they are all affiliate-linked.

If you have zero paying customers, this decision does not matter and thinking about it is procrastination wearing a business-y costume. I have done this. Picking a payment provider feels like real work. It is not real work. It is a two-hour decision that people stretch across two weeks because it is more comfortable than talking to a stranger about whether they would pay for the thing.

The honest sequencing is: get one person to pay you anything, on whatever rail is fastest to set up. Then, when you have five or ten customers and some evidence the thing works, spend an afternoon on this properly. I made the case in why your first dollar of MRR beats your first thousand followers that revenue is the only signal that is not fakeable, and the corollary is that infrastructure built before revenue is infrastructure built on a guess.

The tax authorities are not going to come after you for the €4 of VAT you failed to remit on your first sale. They may well care at €40,000. Build for the second case when you can see it coming, not before.

What I Would Do Today

If I were starting a new paid product this month, US and EU customers expected, B2C leaning:

I would start on Paddle. Not because it is cheapest, it is not, but because it is the one built for subscription businesses that intend to grow, it is not on a visible glide path into another product, and its failed-payment recovery is the part that quietly pays for a chunk of the fee difference once you have enough customers for involuntary churn to be a real number. Recovering 30% of failed payments on a $10,000 MRR business is worth more than the delta between 4% and 5%.

If I were selling a developer tool with usage-based pricing, I would use Polar and pay for the plan tier that gets the rate back down, because the product genuinely fits that shape better than anything else on the list.

If I were US-only B2B, I would use Stripe and not think about it again.

And I would not start on Lemon Squeezy in September 2026. Not because it is bad, it is good, and pricing has not moved. But building your billing on a product whose own team is publicly building its successor is signing up for a migration you did not choose the timing of. That is a bet you can take with your eyes open, and you should at least know you are taking it.

The general principle here is one I keep relearning across every product I have shipped: the boring infrastructure decisions are cheap to make well early and expensive to fix late, and the way you tell them apart from the ones worth agonizing over is asking what breaks if you are wrong. Wrong framework, you rewrite some code. Wrong billing provider, you email your paying customers and ask them for a favor.

Frequently Asked

What is a merchant of record? A company that becomes the legal seller of your product. They collect payment, calculate and remit sales tax and VAT, issue compliant invoices, and take on chargeback liability. You receive a payout net of their fee.

Is Stripe a merchant of record? No. Stripe is a payment processor. You remain the seller and the tax obligation is yours. Stripe Tax calculates and tracks tax for you at about 0.5% per transaction, but does not register or file on your behalf. Stripe Managed Payments, built by the Lemon Squeezy team, is Stripe's separate MoR product.

How much does a merchant of record cost in 2026? Paddle, Lemon Squeezy, and Polar's free tier all sit at 5% + $0.50 per transaction. Polar's paid plans bring the rate down in exchange for a monthly fee. Stripe with Stripe Tax works out around 3.4% and is not an MoR.

Did Polar raise its prices? Yes. Polar moved from a flat 4% + $0.40 to a tiered model in 2026, with the free Starter tier at 5% + $0.50. Organizations created before May 27, 2026 keep the old rate on a grandfathered plan.

Is Lemon Squeezy shutting down? No announced shutdown, and new signups are open. But Stripe acquired it in 2024 and the Lemon Squeezy team is now building Stripe Managed Payments, with the stated goal of giving existing users a migration path.

Do I need an MoR if I only sell to US customers? Usually not. Stripe plus Stripe Tax plus registering in the states where you have nexus is cheaper and gives you a better API.

If you are sitting on this decision right now with no paying customers yet, close this tab and go get one. The provider you pick will be the right one either way, and the person who pays you will teach you more about your product than the fee comparison will.

Related Articles

Background Jobs For Indie Developers in 2026: When You Need A Queue, When You Do Not, And What I Actually UseEvery job queue tutorial is written for companies running ten thousand jobs a second. As a solo developer you do not ...Feature Flags For Solo Developers in 2026: When You Need Them, When You Do Not, And What I Actually UseEvery feature flag tool is pitched at companies with a hundred engineers. As a solo developer you do not need a $200 ...Multi-Agent vs Single-Agent Architecture in 2026: When the Crew Beats the SoloistMulti-agent systems are the architecture pattern everyone is talking about in 2026 and almost nobody actually needs. ...