If you’re building a SaaS product, payment integration is one of the few pieces of
the stack you genuinely cannot get away with bolting on later. Get it right early and
billing quietly does its job for years. Get it wrong and you’ll be migrating live
subscriptions, chasing failed renewals, or explaining to an accountant why nobody
registered for VAT in three countries. This guide is for founders and product leads
who are about to wire payments into a SaaS product and want to make the big calls —
provider, architecture, compliance — before a single line of checkout code gets written.
We’ll cover how to choose between Stripe and the merchant-of-record platforms,
what a production-grade SaaS payment integration actually needs beyond “add a
checkout button,” and the compliance and reliability traps that catch teams who
treat payments as a weekend integration.
Start with a business decision, not a technical one
The first choice isn’t an SDK, it’s a business model question: who is legally
responsible for collecting and remitting sales tax on every transaction?
With Stripe (and similar processors like Braintree or Adyen), you are the merchant
of record. Stripe moves the money and can calculate tax for you via Stripe Tax, but
the legal obligation to register, collect and file in every jurisdiction where you
have paying customers sits with you. That’s manageable if your customers are
concentrated in the UK and EU. It gets expensive fast once you have subscribers in
twenty different US states and a handful of VAT jurisdictions, each with their own
registration threshold.
Platforms like Paddle and Lemon Squeezy act as merchant of record: legally, they
buy your software and resell it to the customer, which means they own the tax
compliance burden. You pay a materially higher take rate for that — typically in the
5%+ range against Stripe’s roughly 2.9% + a fixed fee — but for an early-stage team
without a finance function, that premium is often cheaper than the accountant and
compliance overhead of handling international sales tax yourselves.
Our rule of thumb: if your buyers are mostly UK/EU businesses and you’re
comfortable with Stripe Tax, use Stripe. If you’re selling a self-serve product to
individuals and small teams across multiple countries from day one, a
merchant-of-record platform will save you real founder time. This is exactly the
kind of build-vs-buy trade-off we help clients reason through during
product discovery, before any commitment to a provider is made.
What a production-grade SaaS payment integration actually needs
A demo checkout button is a few hours of work. A payment system your finance team
can trust is a longer list:
- Subscription lifecycle handling — trials, upgrades, downgrades,
proration, cancellations and reactivations, all reflected correctly in what you bill. - Webhook-driven state, not redirect-driven state — never mark an
account as paid purely because the browser redirected back to a success URL. Users
close tabs, connections drop, and redirects can be replayed or spoofed. The
authoritative signal is the provider’s webhook (e.g. Stripe’s
checkout.session.completedandinvoice.paidevents),
verified against its signature. - Idempotency — webhooks and retries can and will arrive more than
once. Every handler that changes billing state needs to be safe to run twice. - Dunning — a plan for failed renewal payments: automatic retries,
grace periods, and clear emails before you lock a customer out of the product they’re
still trying to pay for. - Metered and usage-based billing, if your pricing needs it — this
is meaningfully more complex than flat subscriptions and worth scoping honestly at
the start rather than retrofitting later. - A test mode that mirrors production — every provider offers a
sandbox; use it for automated tests covering renewals, failed cards, and refunds, not
just the happy path.
The teams that get burned are usually the ones who built the checkout flow, called
it done, and never built the webhook handling and dunning logic that make billing
resilient to the real world — cards expire, banks decline, users’ connections drop
mid-payment. None of that is exotic; it’s just work that’s invisible until it’s missing.
Compliance: keep cardholder data out of your hands
The single best decision you can make for PCI DSS compliance is to never let raw
card data touch your own servers. Using a hosted checkout page or a client-side
tokenisation library (Stripe Elements, Stripe Checkout, Paddle Checkout and
equivalents) means the card number never transits your infrastructure — the provider
tokenises it in the browser and your backend only ever sees a token.
Done properly, this qualifies most SaaS businesses for PCI DSS Self-Assessment
Questionnaire A (SAQ A), the shortest of the standard’s assessment paths, rather than
the much larger set of controls that apply if you’re handling card data directly. One
detail worth knowing under PCI DSS v4: even scripts loaded on your checkout page —
an analytics tag, a support widget — now fall under scope requirements for payment
page script integrity, so keep third-party scripts on payment pages to a minimum and
review what you add.
The same “don’t touch it” principle applies to broader data handling. If you’re
also thinking through GDPR obligations for customer and billing data more generally,
our data protection by design guide
covers the engineering side of that in more depth.
Build it in-house, or use a billing layer?
Beyond the raw payment provider, there’s a separate question: do you build
subscription logic yourself on top of Stripe’s primitives, or use a billing layer
like Stripe Billing, Chargebee or Recurly that handles plans, proration and invoicing
for you?
For most early-stage SaaS products, using Stripe Billing (or your MoR’s equivalent)
rather than hand-rolling subscription state is the right call. Proration math, tax
recalculation on plan changes, and invoice generation are exactly the kind of code
that looks simple until a customer downgrades halfway through a billing cycle while
also changing currency. Reserve custom billing logic for genuinely unusual pricing
models — heavily usage-based products, marketplaces splitting payments between
parties, or per-seat pricing with complex proration rules — where the standard
tooling doesn’t fit.
This is a good example of a wider pattern we see across client engineering
decisions: buy the commodity infrastructure, build only the part that’s actually your
product. It’s the same logic behind our
build vs buy guide for authentication,
and it applies just as cleanly to payments.
Practical checklist before you launch billing
- Confirm who is the merchant of record and who owns tax compliance.
- Use hosted checkout or client-side tokenisation — never handle raw card numbers
on your own servers. - Build webhook handlers as the source of truth for subscription state, verified
and idempotent. - Write automated tests against the provider’s sandbox for renewals, failed
payments and refunds, not just successful checkout. - Put dunning and grace-period logic in place before you have paying customers to
lose. - Decide early whether you need usage-based billing — it changes your data model,
not just your invoices.
None of this needs to be built from scratch, and most of it shouldn’t be. If
you’re scoping a SaaS build and want a second opinion on the payment architecture
before you commit engineering time to it, we’re happy to talk it through —
book a free consultation and we’ll help you
get the decision right the first time.
FAQ
Should a new SaaS product use Stripe or a merchant-of-record platform like
Paddle?
If most of your customers are in one or two tax jurisdictions you’re comfortable
registering in, Stripe with Stripe Tax is usually cheaper. If you’re selling
self-serve internationally from launch and don’t have finance support, a
merchant-of-record platform’s higher fee is often worth it to offload tax compliance.
Do we need to be fully PCI DSS compliant to take payments?
Yes, but the scope depends on how you handle card data. Using a hosted checkout or
tokenised payment fields keeps card numbers off your servers entirely, which
qualifies most SaaS businesses for the much shorter SAQ A assessment rather than the
full standard.
What’s the most common mistake in SaaS payment integrations?
Treating the redirect back from checkout as proof of payment instead of relying on
verified webhooks. Redirects can fail to fire even on successful payments, and
webhooks are the only reliable source of truth for subscription state.
Can payment integration be added after an MVP launch?
Technically yes, but the subscription lifecycle, tax setup and webhook handling take
real design time, so it’s worth scoping upfront even if implementation comes in a
later phase — retrofitting billing onto live user accounts is far harder than
building it in from the start.
