Merchant of Record vs Stripe: Why Our Templates Ship with Creem

The moment your SaaS takes its first international payment, you inherit a problem nobody warns you about: you may now owe sales tax in jurisdictions you've never heard of. EU VAT, UK VAT, Canadian GST, a growing list of US states with economic nexus rules — each with its own registration thresholds, filing schedules, and invoice requirements. This is the part of "just charge money for software" that quietly eats a solo founder's month.

Our web and desktop templates default to Creem, a merchant of record, specifically to make that problem someone else's job. Here's the trade-off, honestly stated.

What "merchant of record" actually means

With a plain payment processor like Stripe, you are the seller. The customer buys from your company, the money is your revenue, and the tax liability is yours. Stripe moves the money and (with Stripe Tax) can help you calculate what's owed — but registering, collecting, remitting, and filing in each jurisdiction is on you.

A merchant of record (MoR) flips that. Creem is the legal seller of record. The customer technically buys from Creem; Creem resells on your behalf; and Creem is the entity responsible for charging the correct tax everywhere and remitting it. You get paid out net of fees, and the multi-jurisdiction tax compliance simply isn't your problem. Paddle and Lemon Squeezy operate on the same model — Creem is the one we wired in by default.

The trade-off, stated plainly

MoR isn't free, and we won't pretend otherwise:

• Stripe — lower fees, maximum flexibility, direct relationship with your customer and your money. You own tax compliance, which for a global digital product is a real, recurring operational burden.
• Creem (MoR) — a higher effective cut in exchange for offloading global sales tax, VAT/GST registration, and remittance entirely. You trade margin for not thinking about tax law.

For a large company with a finance team, Stripe plus dedicated tax tooling is often the right call. For the audience most of our templates serve — solo devs and small teams selling globally who want to ship, not incorporate in seven countries — the MoR trade is usually worth it. That's why it's the default, not the only option.

We built it behind a provider abstraction

Because "usually worth it" isn't "always," the templates don't hard-code Creem. Payments sit behind a provider interface, and both a Creem and a Stripe provider ship in the box:

// src/lib/payment/index.ts
const providers = {
  creem: () => new CreemProvider(),
  stripe: () => new StripeProvider(),
};

Each provider implements the same contract — create checkout, handle the webhook, reconcile subscription state — so switching is a config change, not a rewrite. If you outgrow the MoR model, you move to Stripe without touching the rest of your app.

Both payment shapes, one flow

The templates support the two shapes a SaaS actually needs, through the same provider:

• Subscriptions — monthly and yearly plans.
• One-time purchases — including the "lifetime" model we use for the templates themselves.

Incoming webhooks are signature-verified and reconciled into a subscription table that becomes the single source of truth for entitlement — so your app checks one row to know whether a user has access, regardless of which plan or payment shape they bought.

Where mobile differs

One consistency note, since our templates span platforms: the mobile templates don't use Creem. On iOS and Android, Apple and Google are the merchant of record for in-app purchases — they take their cut and handle tax by mandate. There we use RevenueCat on top of the store billing systems (separate deep-dive here). Same principle throughout: let the platform's rightful merchant of record handle tax, and keep your own code focused on entitlement.

If you're selling a web or desktop product globally and don't want a second job as a tax filer, start from the payments docs — the Creem checkout, webhook, and subscription reconciliation are already wired up.