Why we chose a merchant of record over raw Stripe

If you're a solo founder in the EU or Switzerland shipping a SaaS to a global audience, the first billing decision you make is bigger than it looks. It determines who is legally on the hook for VAT/GST across dozens of jurisdictions, who issues invoices, and who your customer's bank actually sees on their statement. We spent longer thinking about this than about which database to pick, and we still went back and forth. Here is the reasoning we landed on.

What "merchant of record" actually means

A merchant of record (MoR) is the legal seller on the receipt. When a customer in Germany pays for your product through an MoR, the MoR — not you — is the party that collected the money, charged the correct VAT, remitted it to the German tax authority, and issued a compliant invoice. Your relationship becomes B2B with the MoR: they pay you a payout, minus fees, under a single revenue contract.

If you wire Stripe (or Paddle Billing, or Braintree) directly and act as your own merchant, you are the seller. That means:

• You need to determine the customer's location and apply the correct VAT rate at checkout (there are ~30 different EU rates plus reduced rates plus reverse-charge rules for B2B).
• You need to register for OSS (One-Stop Shop) or, if you're outside the EU, IOSS/non-Union OSS, and file quarterly returns.
• For non-EU customers you need to figure out sales tax nexus in the US, GST in Australia/India/Singapore, HST in Canada, and so on.
• You issue the invoices, and they need to meet each country's format rules (sequential numbering, VAT ID display, reverse-charge language, storage duration).

None of this is impossible. Founders do it. But every hour spent on it is an hour not spent on the product, and every mistake is a compounding liability that surfaces years later during an audit.

Where MoRs earn their fee

MoRs charge more than raw payment processors. Polar, Lemon Squeezy, and Paddle sit somewhere in the 4–7% range depending on volume and product type; Stripe alone is closer to 2.9% + fixed. The delta is what you pay for having someone else own the tax problem.

For a small indie SaaS the math almost always favours the MoR: the extra 2–4% is cheaper than a bookkeeper, cheaper than a tax adviser retainer, and dramatically cheaper than getting VAT wrong for eighteen months and then owing back-taxes plus penalties. It stops mattering somewhere past €1–2M ARR, when hiring finance headcount to do it properly becomes cheaper than the MoR fee. Until then, an MoR is one of the highest-ROI outsourcing decisions you can make.

There is also a subtler benefit. An MoR gives you a single, clean revenue stream from one counterparty. Your accounting is "Polar paid me €X on date Y." That's it. No per-country revenue splits, no VAT liability accounts, no separate OSS filings. Your accountant will thank you.

Why Polar specifically

Once we accepted we wanted an MoR, the shortlist was Polar, Lemon Squeezy (now part of Stripe), and Paddle. We chose Polar for a few narrow reasons:

• The API surface is small and well-documented. Products, checkouts, webhooks, license keys, customer portal — that's essentially it. We wired the whole flow in an afternoon and it fits inside a single server function plus one webhook route.
• Standard Webhooks signatures. Verifying webhook payloads is not optional and Polar uses the community standard, so our verification code is boring and reusable.
• License keys are a first-party primitive. If you're selling to developers or shipping a CLI or desktop app, being able to validate/activate/deactivate keys through the same platform you already bill through is a real time-saver.
• The pricing is transparent and there's no minimum. That matters for a starter kit where a buyer might make one sale in month one.

Lemon Squeezy would have been fine. Paddle is stronger at higher volumes. If you're already deep in the Stripe ecosystem and can absorb the tax-compliance work, raw Stripe is defensible too. The point isn't that Polar is objectively best — it's that "MoR yes/no" is the decision that actually matters, and any of the good MoRs will save you months of compliance work.

Tradeoffs we accept

• Higher effective take rate. We eat a few extra percentage points per sale. We've decided that's cheaper than the founder hours we'd otherwise spend on VAT, and we'd rather ship features.
• Payout timing. MoRs typically hold funds slightly longer than raw Stripe. Not a problem at our scale; worth knowing if cashflow is tight.
• Customer-facing entity. The invoice says "Polar," not your company. Some enterprise buyers care; most self-serve customers do not.
• Vendor lock-in. All MoRs have some. Migrating billing is painful. Mitigate by keeping product IDs in your own config and treating the webhook payload as the source of truth in your own database — both patterns are wired into this kit.

If you're building on this kit, the entire pattern is already in `src/lib/checkout.functions.ts` and the Polar webhook route — swap product IDs and you're ready to sell.