Skip this at MVP stage

Don't build billing before you have customers. If you have fewer than ten, invoice them manually. A signed contract and a paid invoice prove willingness to pay far better than a Stripe integration, and manual invoicing teaches you what your pricing model should actually be.

Don't build a custom checkout. Stripe Checkout and the Customer Portal handle payment collection, card updates, cancellations, and invoice history. A custom flow means owning PCI scope and every edge case for a marginal design gain.

Don't build usage-based billing unless usage-based pricing is your model. It's substantially more complex than seats and most products don't need it at launch.

What you do have to get right

Webhooks are the source of truth, not your checkout redirect. The user closes the tab before redirect; the payment still succeeds. If you provision access on redirect, that customer paid and got nothing. Provision on the webhook.

Verify webhook signatures. An unverified endpoint lets anyone grant themselves a subscription with a forged POST. This is not theoretical.

Handle webhooks idempotently. Stripe retries and can deliver the same event more than once. Store processed event IDs and no-op on repeats, or customers get double-provisioned.

Reconcile state rather than mirroring it. Don't try to keep a full copy of Stripe's subscription state in your database. Store the customer and subscription ID plus the access level you derive, and re-read from Stripe when it matters. Divergence between two sources of truth causes the worst billing bugs.

Failed payments need a path. Cards expire constantly. Stripe's Smart Retries plus dunning emails plus a grace period before downgrade is the minimum. Cutting access on the first failure loses customers who simply need to update a card.

The events that matter

Four cover most of it: subscription created, subscription updated (upgrades, downgrades, cancellations), payment failed, and payment succeeded after a failure. Everything else can wait.

Proration and plan changes

Stripe handles the math. What you own is the access decision: does an upgrade apply immediately, does a downgrade apply now or at period end, what happens to work created above the new plan's limits?

These are product decisions and they need answering before you write the code: retrofitting them is where billing rewrites come from.

What we build

Stripe Checkout and Portal rather than custom flows, signature-verified idempotent webhook handling, access derived from subscription state instead of mirrored, dunning with a grace period, and the plan-change rules decided up front. Usually two to three days when the pricing model is settled, and considerably longer when it isn't, which is the real reason billing overruns.

FAQ

Should I build billing into my MVP?

Not before you have around ten paying customers. Invoice manually first: a signed contract and paid invoice prove willingness to pay better than a Stripe integration, and manual invoicing surfaces what your pricing model should actually be before you encode it.

Why should access be granted on the webhook rather than the redirect?

Because users close the tab before the redirect fires while the payment still succeeds. Provisioning on redirect means that customer paid and received nothing. The webhook is the reliable signal; the redirect is a UX convenience.

What's the most common Stripe integration mistake?

Two, equally common: not verifying webhook signatures, which lets anyone grant themselves a subscription with a forged request, and mirroring Stripe's full subscription state into your own database, which creates two sources of truth that inevitably diverge.