Hanad KubatVisit Website →
← Back to blog

SaaS Payments Setup: A Founder's Guide to Getting Paid

October 31, 2026
SaaS Payments Setup: A Founder's Guide to Getting Paid

A SaaS payments setup has five parts: a pricing model, a hosted checkout, a subscription record in your own database, webhook handling for everything that happens after the first charge, and a test pass before real money moves. For most early-stage products, the simplest working version is a hosted checkout from a major processor, a webhook endpoint, and a database table that your app trusts over the browser. Everything below explains how to build that, where founders usually go wrong, and when to buy a different kind of tool instead.

I'm Hanad Kubat, a senior software engineer in Vienna. I build payments and logins into first versions of products and into prototypes that have outgrown their no-code or AI-generated shells. This guide is what I'd tell a founder across a table.

Hanad Kubat
hanadkubat.com
Build Payments Into Your First Version
Hanad builds working software with payments and logins, or rebuilds prototypes that have outgrown their no-code or AI-generated shells.
Explore software builds

Key Takeaways

  • Separate three jobs in your head: processing the card, managing the subscription lifecycle, and handling tax. One tool may cover all three, but you should know which is which.
  • Your database, updated by verified webhooks, is the source of truth for who has paid. A success page in the browser is not.
  • Use hosted checkout so card numbers never touch your servers. That shrinks your PCI burden but does not remove it.
  • Failed charges, cancellations and proration are where revenue leaks. Design them before launch, not after the first angry email.
  • Test the unhappy paths in a sandbox: declines, cancellations, mid-cycle upgrades and retries.

Table of Contents

What a SaaS payments setup actually includes

Founders often say "add Stripe" as if it were one task. It is several.

A payment processor handles the secure transaction itself. A billing platform manages the subscription lifecycle: upgrades, downgrades and recurring invoice automation, a distinction Maxio draws in its guide to choosing payment processing and billing tools. Some providers bundle both, but ProcessorFit cautions that having a processor does not guarantee features like usage metering or complex prorations. Check this before you commit, not after.

Stripe describes the whole thing as a payment suite: checkout, subscription management and reporting connected so that you have one source of truth for revenue. That framing is useful. You are not picking a button. You are picking how money, customer state and reports stay in agreement.

In practice, a working setup has these pieces:

PieceWhat it doesWhere it lives
Products and pricesDefines plans, intervals, currenciesProcessor dashboard or API
CheckoutCollects payment detailsHosted by the processor
Subscription recordStores status per customerYour database
Webhook endpointReceives events from the processorYour backend
EntitlementsDecides which features a user getsYour backend
Tax and invoicesCalculates and documents taxProcessor, add-on, or a merchant of record
Customer portalLets users update cards and cancelUsually the processor

If any row is missing, you will feel it within a month of launch.

Choose the pricing model before you write code

The model decides your data structure, so settle it first.

One common rule of thumb: one-time pricing suits a fixed result with little ongoing service, subscriptions suit repeated value, and usage pricing suits cases where value and variable cost both grow with consumption. For most B2B SaaS, that means a subscription, with usage added only when your costs genuinely scale per call. LLM features are the classic example: every request costs you money, so a flat plan with no cap can lose money on your heaviest users.

Comparison of three SaaS pricing models

Two marketplace-billing docs, written for another platform but sound on the principles, are worth reading for plan design. Shopify's app billing guidance recommends simple pricing, a limited number of plans, free trials and local billing currency. Its usage docs recommend usage-based billing when value or delivery cost scales with consumption, and describe fixed, graduated and volume pricing.

If you want more examples of how B2B products structure revenue, my piece on revenue model examples for B2B SaaS goes through them.

Plans, intervals and trials

Keep the first version small: two or three plans, monthly and annual intervals, one trial rule.

Hybrid pricing, a base fee plus usage, is possible, but implementations have limits. In Shopify's documented version, usage charges must use a monthly billing cycle. Whatever processor you use, check how it combines annual plans with metered usage before you promise customers both.

Connect checkout, subscriptions and your database

This is the core build, and it follows the same shape on most processors.

  1. Create the products and prices in the processor's dashboard, in test mode.
  2. Create a checkout session from your backend when a signed-in user picks a plan. Stripe Checkout is a low-code integration that supports one-time purchases and subscriptions, with PCI compliance and SCA-ready features built in.
  3. Redirect the user to the hosted payment page the session's URL points to.
  4. Listen for the completion event. The same docs describe fulfilling the order from the checkout.session.completed webhook.
  5. Write a subscription record linked to your user: customer ID, subscription ID, plan, status, current period end.
  6. Gate features on that record, server-side.

The last two steps are where prototypes fail. The SaaSify guide advises tracking statuses such as active, trialing, past_due, canceled and incomplete in your own database, and gating features on that server-side state rather than on a client-side success indicator. I agree completely. I regularly see Lovable or Bolt builds where a user who lands on the "thank you" URL gets premium access, and anyone who types that URL gets it too.

If you want this built for you, I describe the fixed-scope version on my page about Stripe billing for SaaS.

Webhooks: the part that keeps working after launch

The first charge is the easy event. The hard ones arrive weeks later, when you are not watching: a renewal, a declined card, a plan change, a dispute.

Your webhook endpoint needs four habits:

  • Verify the signature. Stripe's webhook documentation shows verifying events with your endpoint secret and recommends further protections such as IP allowlisting. Without verification, anyone can post a fake "payment succeeded" to your URL.
  • Process idempotently. Processors can deliver the same event more than once. A payment system checklist recommends processing by unique event ID, so a repeated event does nothing the second time. Store processed IDs.
  • Return quickly. Acknowledge the event, then do slow work in a queue.
  • Reconcile. Run a periodic job that compares your records against the processor's. Webhooks occasionally get missed, and a nightly check catches it.

On Cloudflare Workers, which I often use, the main thing to remember is reading the raw request body for signature checks. Parsing JSON first breaks verification. It is a small detail that eats an afternoon the first time.

Failed charges, cancellations, refunds and proration

Cards fail for ordinary reasons: expiry, insufficient funds, a bank's fraud filter. A setup without a recovery plan turns those into lost customers.

Retries. Stripe Billing can automatically retry failed subscription and invoice payments, and recommends its Smart Retries over a hand-built schedule. It does not retry in certain cases, for example when the issuer returns a hard decline code. Those customers need an email asking for a new card.

Dunning. Beyond retries, Freemius suggests a sequence of grace period followed by service restriction. My version is simple: on the first failure, mark the account past_due and email the owner; keep access for a set grace period; after that, restrict to read-only rather than deleting anything. Customers who come back should find their data intact.

Cancellations. Decide whether access ends immediately or at the period end. Period end is fairer and generates fewer disputes. Store the cancel-at date, not just a boolean.

Refunds and proration. Decide your policy in plain words first, then configure the tool. Mid-cycle upgrades should charge the difference, and downgrades should credit or take effect next cycle. Write your choice down; support will need it.

For the audit trail behind these changes, see SaaS audit logging for role and billing changes. When a customer disputes a charge, being able to show who changed what, and when, settles most arguments.

Failed charges, cancellations, refunds and proration

Security and PCI: what you still own

Hosted checkout means card numbers go straight to the processor. That is the single best decision you can make here. Never store card numbers in your database; use hosted pages or tokenization, as the SaaSify guide also stresses.

But outsourcing does not make you exempt. The PCI DSS standard, version 4.0.1 from June 2024, applies to entities that store, process, transmit or can affect the security of cardholder data. It says that outsourcing does not remove responsibility: you must oversee your providers, document who is responsible for what, and monitor their compliance status at least annually. It also forbids storing sensitive authentication data, such as CVV or PINs, after authorization. If you are unsure which self-assessment applies to you, ask your processor or a qualified security assessor.

Beyond cards, the everyday risks are mundane:

Tax: processor, add-on or merchant of record

Tax is where a payments setup stops being only technical. If you sell to US customers, state sales tax can apply once you pass economic nexus thresholds, which depend on where you and your customers are and how much you sell. Stripe's guide to US sales tax and economic nexus walks through the steps. Whether SaaS is taxable also varies by state, so confirm with an accountant.

For customers in the EU, consumer-facing digital services also fall under consumer protection rules. The European Commission's notice confirms that the Consumer Rights Directive covers service contracts, including digital services such as SaaS, between consumers and traders. VAT is handled per country, for instance with quarterly OSS returns in Poland.

There are two broad ways to deal with this:

ApproachYou handleGood fit
Processor plus tax add-onRegistrations, filings, liabilityB2B sellers in a few known markets
Merchant of recordLittle tax admin; the provider is the sellerSolo founders selling globally from day one

Freemius argues that a merchant of record takes on local tax compliance, fraud and chargebacks, and that for global scaling the saved admin can justify the higher fee. That is a fair trade for a one-person company selling cheap subscriptions to many countries. For higher-priced B2B contracts with invoices and purchase orders, a standard processor with tax tooling usually fits better.

Test before real money moves

A payment flow that works once is not a payment flow that works. Freemius recommends auditing the configuration in a sandbox: successful signups, declines, coupons, and subscription lifecycle changes, including mid-cycle proration, cancellations and dunning.

My launch checklist:

  1. Sign up with a successful test card; confirm the subscription row and feature access.
  2. Sign up with a declining card; confirm no access is granted.
  3. Replay the same webhook twice; confirm nothing doubles.
  4. Send a webhook with a bad signature; confirm it is rejected.
  5. Upgrade mid-cycle; confirm the amount charged.
  6. Cancel; confirm access runs to period end.
  7. Force a renewal failure; confirm the past_due path and emails.
  8. Check that production keys exist only on the server.
  9. Run one real low-value charge and refund it.

If you do only one thing from this article, do steps 3 and 4. They are the ones prototypes skip.

My view: keep it boring, own it

I have spent ten years in software, including systems work for Deutsche Bahn, BMW and the Austrian Federal Computing Centre. The lesson I keep relearning is that payments code should be dull. Use the processor's hosted checkout. Store a small, clear subscription table. Handle a short list of events well. Resist custom billing logic until a paying customer asks for it.

I also tell founders when not to build. If your needs are a single product at a single price, a payment link or a ready-made billing portal may be all you need for the first months. Custom work pays off when plans, entitlements and usage start interacting, which is usually when a no-code prototype starts to creak.

Whatever you build, you should own it: the code, the accounts and the keys, from the first commit, so the next developer can pick it up without a rewrite.

— Hanad Kubat

Getting payments built properly

If your prototype takes payments but you do not trust it, or you have no code yet and need billing working before an investor demo, I build this as a fixed-price engagement. Builds start from €12,000 and take two to four weeks. You see working progress before you pay, and you own the code from the first commit. There is no agency layer, no project manager and no offshore markup, which is why the price can stay fixed. You can see the details at hanadkubat.com.

FAQ

What is the simplest SaaS payments setup for a solo founder?

Use a hosted checkout from a major processor, one webhook endpoint, and a subscription table in your database. Start with two or three plans and one trial rule. If you sell to many countries and want little tax admin, consider a merchant of record instead.

Do I need a separate billing platform?

Not at first. A processor's built-in subscription features cover plans, trials, proration and retries for most early products. Add a dedicated billing platform when you need complex usage metering, custom invoicing or revenue reporting that the processor does not provide.

Am I responsible for PCI compliance if I use hosted checkout?

Yes, in a reduced form. Card data stays with the processor, but PCI DSS still expects you to document responsibilities and monitor your providers' compliance status. Ask your processor which self-assessment questionnaire applies to you.

How do I know if a customer has actually paid?

Check your own database, updated by verified webhooks from the processor. Do not rely on the success page, because anyone can visit that URL. Gate features on the stored subscription status, such as active or trialing.

Sources