# 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.

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.

---

Agentic Boilerplate: A Next.js repo your agent already knows. Free during launch, then $99 once.

- Site map for agents: https://agenticboilerplate.com/llms.txt
- Public API: https://agenticboilerplate.com/openapi.json
- Contact: agenticstudio@gmail.com