Merchant of record for SaaS (2026): MoR vs Stripe, fees, and switching providers

If you sell software online, merchant of record (MoR) is the label on the receipt that decides who owes VAT, who answers chargebacks, and whether your weekend goes to tax filings or shipping features. Most founders still compare MoR vs Stripe as if they were two checkout buttons. They are not. Stripe is usually a payment processor (you stay the seller). A MoR is the legal seller on the invoice.

This guide explains what a merchant of record actually does, when Stripe plus Stripe Tax is enough without a MoR, which developer-friendly MoRs indie SaaS teams shortlist in 2026, and what switching billing providers changes in your codebase. Numbers below are from each vendor's official pricing or docs last checked October 27, 2026. For head-to-head fee tables, use our dedicated comparisons instead of repeating them here: Stripe vs Lemon Squeezy vs Polar vs Creem vs Dodo, Lemon Squeezy vs Stripe, Polar vs Stripe, and Creem vs Stripe.

What is a merchant of record?

Merchant of record (MoR) means the entity on the customer's card statement and tax invoice. The MoR:

• Calculates, collects, files, and remits indirect tax in the jurisdictions it covers
• Owns refunds and chargebacks as the seller of record
• Pays you as a supplier or partner after platform fees and holds

A payment processor (standard Stripe Payments, Adyen, Braintree, and similar) authorizes and settles card payments. You remain the merchant. The processor does not make you exempt from registering for VAT or US state sales tax when you cross economic nexus thresholds.

Creem's MoR documentation frames it cleanly: a processor handles moving money; a MoR takes legal responsibility for being the seller. Polar's MoR intro adds an important limit: a MoR handles indirect tax, not your income or corporate tax in your home country.

What a merchant of record handles (vs what Stripe alone does)

Use this checklist when you read vendor marketing. "We handle payments globally" is not the same as "we are your MoR."

Stripe Managed Payments is Stripe's MoR layer: Stripe becomes seller on eligible new Checkout and Payment Link sales, with an extra 3.5% per successful transaction on top of standard Stripe processing, plus separate Billing fees. Eligibility, product type, and country lists are stricter than plain Stripe; see Managed Payments eligibility and Polar vs Stripe for fine print.

When Stripe plus Stripe Tax is enough (no MoR)

You do not need a merchant of record for every SaaS. Stripe plus tax tooling is the right default when:

1. Most revenue is domestic or from a small set of countries where you can register once and maintain filings.
2. You want Connect, marketplaces, or fully custom checkout that MoR products rarely support.
3. Your effective rate matters more than outsourcing compliance and you have (or will hire) ops for tax.
4. You sell B2B with valid VAT IDs in Europe and can rely on reverse charge for many invoices (still document correctly; this is not "no VAT ever").

A practical Stripe-only stack for subscriptions often looks like:

• Stripe Payments for cards (US domestic 2.9% + 30¢ on the published US pricing page, October 27, 2026)
• Stripe Billing for renewals (0.7% of Billing volume on pay-as-you-go)
• Stripe Tax Basic where you are registered (0.5% per transaction on the Tax pricing page) to calculate and collect
• Your accountant or a filing partner for returns and remittance

Signals you have outgrown processor-only Stripe

• You crossed economic nexus in multiple US states or VAT OSS complexity in the EU and filings are slipping
• Chargebacks and refund policy for global buyers consume support time you do not have
• You need one global price with tax handled on the receipt without maintaining rate tables
• Investors or enterprise customers ask who is the seller of record and your answer is uncomfortably vague

If several of those are true, compare MoR headline fees against accounting time and registration costs, not just the difference between 2.9% and 5%.

Developer-friendly merchant of record options (2026)

"Developer-friendly" here means: documented REST APIs, webhooks, test mode, subscription primitives, and a path that does not trap you in a no-code-only UI. For TurboStarter users, first-class web providers are Stripe, Lemon Squeezy, Polar, and Dodo Payments (configuration). Creem and Paddle are common MoR choices in the wild but are not built-in TurboStarter providers today; you would integrate them yourself or stay on a comparison post's migration path.

Paddle vs Stripe is a common search pairing for founders comparing MoR bundles to processor pricing: Paddle is MoR-first at 5% + 50¢; Stripe is processor-first with optional Managed Payments. Compare total cost including tax labor, not logo preference.

Creem, Polar, and Dodo target the same indie SaaS MoR intent as Lemon Squeezy with different fee math and APIs. Do not re-derive every surcharge here; the four-way payments guide keeps the October 2026 table current.

Mobile: MoR on web, RevenueCat on iOS and Android

App Store and Google Play subscriptions are a separate stack. RevenueCat (or Superwall in TurboStarter) manages store billing; your web MoR or Stripe account does not replace that. Plan one entitlement layer in your backend so web and mobile unlock the same features (mobile billing docs).

What switching billing providers means in code

Switching from processor to MoR (or between MoRs) is rarely a database migration alone. Expect:

TurboStarter: swap provider exports, env vars, and config IDs

TurboStarter keeps checkout, webhooks, portal, and plan gating behind @workspace/billing and @workspace/billing-web. The active web provider is selected by exports in packages/billing/web/src/providers:

// Default: Stripe
export * from "./stripe";

// MoR examples (also update env.ts export):
// export * from "./lemon-squeezy";
// export * from "./polar";
// export * from "./dodo-payments";

export * from "./stripe/env";
// export * from "./lemon-squeezy/env";

Then align environment variables and dashboard objects with the provider docs:

• Stripe: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, Stripe Price IDs in billing configuration
• Lemon Squeezy: LEMON_SQUEEZY_API_KEY, LEMON_SQUEEZY_SIGNING_SECRET, LEMON_SQUEEZY_STORE_ID, variant IDs in config
• Polar: POLAR_ACCESS_TOKEN, POLAR_WEBHOOK_SECRET, POLAR_ORGANIZATION_SLUG
• Dodo Payments: API key, webhook key, environment flag per docs

Webhook routes stay under your app's billing API (for example /api/billing/webhook/*); only the handler implementation and signing secret change. Feature gating still reads the same internal subscription state once webhooks update your database (subscriptions).

Moving to Creem or Paddle (not built into TurboStarter)

If you choose Creem or Paddle, plan a custom provider module implementing the same @workspace/billing provider interface, or run MoR checkout outside the kit until you add one. Technically that means new REST clients, webhook parsers, and mapping MoR subscription statuses to your internal subscription table. Product-wise it is the same cutover problem: export catalog, recreate prices, migrate or dual-bill subscribers. Start from Creem vs Stripe for API shape and fee expectations.

How to choose (decision flow)

flowchart TD
  A[Selling digital SaaS online] --> B{Need Connect or marketplace?}
  B -->|Yes| C[Stripe processor]
  B -->|No| D{Comfortable registering and filing tax globally?}
  D -->|Yes| E[Stripe + Billing + Tax]
  D -->|No| F{Already all-in on Stripe Checkout?}
  F -->|Yes, eligible| G[Stripe Managed Payments]
  F -->|No| H[Compare MoRs: Creem, Polar, Dodo, Lemon Squeezy, Paddle]
  H --> I[Keep billing behind abstraction in app code]

1. Marketplace or custom payments UI → Stripe processor only.
2. Domestic or low-jurisdiction sales, cost-sensitive → Stripe + Billing (+ Tax where registered).
3. Want MoR but stay on Stripe → Managed Payments if you pass eligibility.
4. Want lowest published MoR rate → Creem (3.9% + 40¢, October 27, 2026).
5. Want open-source MoR and dev tooling → Polar (pricing).
6. Usage or credit billing for AI → Dodo (review).
7. Already on Lemon Squeezy and it works → Stay, but keep TurboStarter's provider swap path for later.

FAQ

Merchant of record is a liability and tax choice first and a API choice second. Stripe plus Stripe Tax stays the right default when you can own compliance and want control. MoRs trade margin for calendar time when you sell digital products globally. Whichever you pick, keep billing behind an abstraction so the next switch is configuration, webhooks, and price IDs—not a rewrite. TurboStarter ships that layer for Stripe, Lemon Squeezy, Polar, and Dodo on web, with RevenueCat on mobile, from one monorepo.