Stripe billing for SaaS MVPs

For a first SaaS product, billing is three things: a hosted Stripe Checkout that takes money, a webhook that marks the account as paid, and a gate on the workspace. Everything else, including plan tiers, proration, usage metering and a billing portal you built yourself, is a later sprint.

Billing is where first SaaS products quietly explode. The instinct is to model every plan, coupon and seat before a single customer has paid.

Checkout, not a billing platform

Use Stripe Checkout or a hosted invoice flow. Do not build a billing portal, proration engine or usage meter until you have a reason. Seats can be a quantity on a single product.

Trials belong in Stripe. Recreating trial logic in your database is how you get accounts that never convert and never expire.

When customers eventually need to update a card or cancel, use Stripe's own customer portal. It is a redirect with a session, it handles the cases you would get wrong, and it saves you a set of screens that produce no differentiation.

Webhooks are the source of truth

The app should not believe a success page. Believe checkout.session.completed and the subscription status events. Store the Stripe customer and subscription ids on the account. Everything else is derived.

The reason is simple. A customer can pay and then close the tab before your success page loads, or pay on a phone that drops connection. The payment happened. If your only path to "paid" runs through a browser redirect, that customer is now paying you for a locked account.

A handler that holds up in production does four things:

• Verifies the signature using the webhook secret, and rejects anything that fails
• Returns quickly, doing slow work after acknowledging the event
• Ignores events it has already processed, checked by the Stripe event id
• Ignores stale events, since retries and out-of-order delivery are normal

The events worth handling in v1 are few: the completed checkout session, subscription created and updated, subscription deleted, and a failed invoice payment. That is enough to know whether an account should have access.

Model access as one derived answer

The mistake that causes the most billing bugs is scattering "is this account allowed in" across the codebase. Keep the stored facts minimal and compute the answer in one place.

Store on the account: the Stripe customer id, the subscription id, the subscription status, and the date the current period ends. Then one function answers whether the workspace is active, and every screen and route asks that function. When billing rules change, you change one function rather than hunting through routes.

This is the same edge-integration discipline described in SaaS MVP architecture. Stripe is an edge, your own function is the interface, and the rest of the app never talks to the provider directly.

One paid plan is a feature

You can sell a second plan later. Two plans in v1 means twice the copy, twice the support, and a founder arguing with themselves about positioning instead of shipping the workflow.

A single plan also keeps upgrades out of scope, and upgrades are where the real complexity lives: proration, mid-period changes, downgrades that need to take effect at the period end. None of that is work you can do well before you know what people will pay for.

If you genuinely have two audiences with different needs, that is a positioning question rather than a billing one. Job Hunt has candidates and employers as separate account types, which is a product decision about who does what. Whether both sides pay, and for what, is a decision that can arrive after the loop is proven.

Test before launch, in test mode

Run these paths and confirm the account state after each:

• A successful checkout, then close the tab before the redirect completes
• A card that requires authentication, and one that is declined
• A cancellation, and confirm access ends when the period ends rather than immediately
• A failed renewal payment, and confirm the workspace behaves the way you documented
• The same webhook delivered twice, and confirm nothing changes on the second delivery
• A customer who pays with one email and signs in with another, so you know which record wins

The last two are where most first implementations break, and both are quick to check with the Stripe CLI forwarding events to your local machine.

What to write in the spec

Name the plan, the price, whether it is monthly, and what happens to the workspace if payment fails. If that paragraph is missing, billing is not scoped, it is assumed.

Write down the answers to these, in the quote:

• The plan name, the amount, the currency, and monthly or annual
• Whether there is a trial, how long it lasts, and whether a card is required to start it
• What a user can do before paying, if anything
• What happens on a failed payment, and how many days of grace they get
• What happens to the data if they cancel
• Whether tax is handled by Stripe or ignored for now, and who decided that

Six sentences prevents most billing arguments. Getting them into the fixed scope is the same discipline as everything else in how to scope a first SaaS system in 14 days.

What to leave out

Coupons and promotion codes, annual plans alongside monthly, usage-based metering, invoices you render yourself, dunning email sequences, multi-currency, and a revenue dashboard. Every one of those is straightforward to add once real money is moving, and every one is a distraction before then.

A first billing setup is judged on one question: when someone pays, does the product let them in, reliably, without you checking. If you want that built as part of a fixed-scope SaaS MVP sprint, that is the version worth shipping.