Skip to content

Merchant of record explained, what Polar takes on that Stripe leaves with you

With Stripe you are the seller and you owe VAT, GST and US sales tax yourself. Polar sells on your behalf and carries that liability. What actually changes, what it costs, and how little of it reaches your code.

Polar4 min readships at docs/solutions/polar/merchant-of-record-vs-stripe.md

Tags: polar · stripe · merchant-of-record · tax · vat · sales-tax · compliance

You sell a $20/month SaaS subscription. A customer in Germany buys it. Someone owes the German tax office 19% VAT on that sale, and someone has to be registered to hand it over.

Which "someone" depends on one decision you made when you picked a payments provider, and almost nobody makes it on purpose.

The two models

Stripe is a payment processor. It moves money from your customer's card to your bank. You are the seller of record: the contract is between you and the customer, the invoice carries your details, and every tax authority where you have customers sees you as the party that made a taxable sale. Stripe Tax calculates the rate and can help you file, but the registration is in your name and the liability is yours.

Polar is a merchant of record. Polar sells the product to your customer and buys it from you. The contract is between Polar and the customer. The invoice carries Polar's details and tax registrations. Polar collects the VAT, remits it and files the returns. Your revenue arrives as a payout from one counterparty.

Same card, same checkout, same $20. Very different obligations.

What "you are liable" means

Digital services have no VAT threshold in much of the world. Sell B2C digital services into the EU from outside it and VAT is due in the customer's country from the first euro. Selling worldwide as your own merchant of record means:

  • EU: register for VAT OSS in one member state, charge each customer's local rate, file quarterly, keep evidence of each customer's location.
  • UK: a separate registration and separate returns.
  • US: economic nexus rules per state. Many states tax SaaS, each with its own threshold, registration and filing cadence.
  • Elsewhere: Norway, Switzerland, Australia, India, Japan, Canada and a growing list have their own digital-services regimes.

None of it is hard to do. It is expensive to do properly (an accountant, filing software, a chunk of someone's month), and unremitted tax accrues interest and penalties that do not go away when you close the company.

What it costs

Polar's headline rate is higher than a card processor's because tax is included; see the pricing on its site for the current plans. Stripe is roughly 2.9% + 30c per card charge, plus Stripe Billing on recurring revenue, plus Stripe Tax, plus your accountant.

At a few thousand dollars a month, the difference in fees is smaller than any accountant's bill for VAT OSS. At a few hundred thousand a month, a finance person plus filing software is comfortably cheaper. Somewhere between is the real answer to "which should I pick", and it moves with how many countries you sell into.

What changes in your code

Very little, because billing here is one shared layer plus one adapter.

  • Gone: tax tables, VAT number checks, reverse-charge logic, invoice PDFs, country pricing. Checkout sends a product id and our user id; Polar works out what to charge and collects the tax.
  • The same: plans in src/lib/pricing.ts, /pricing, /billing, the purchases table, hasPlan() and requirePlan(). They do not know which provider is installed.
  • Different in the adapter: one Polar product per price, a webhook signed with Standard Webhooks headers, and no dispute webhook (the nightly reconcile covers it). The adapter is four files under src/lib/billing.
  • Different in feel: payouts arrive on Polar's schedule, after it has collected and remitted the tax. Model your runway on that, especially in the first month. And the name on the customer's card statement is Polar's.

What does not change

You still need webhooks, and they still have to be idempotent: delivery guarantees have nothing to do with who owes the tax. You still need stored billing state so a page render is not a network call. You still reconcile after an outage.

Choosing

Pick a merchant of record when you are small, selling digital goods worldwide, and would rather spend the fee than the month. Pick a processor when volume makes the percentage material, when you have finance staff anyway, or when enterprise buyers need your company on the invoice.

Merchant of record is a service you rent while compliance is the expensive problem, and outgrow when the fee gets bigger than the problem. Switching later changes one adapter here, not the app.