The SaaS Billing Process Explained Step by Step
The SaaS billing process looks straightforward until you try to build it — then you discover webhooks arrive twice, checkouts time out, and your provisioning logic needs to be safe to run more than once. Getting this right means understanding every step of the flow, not just the card charge. Here's the complete billing process, step by step.
Quick Answer
The SaaS billing process is the end-to-end flow from a customer choosing a plan to your app granting access and charging them each cycle. The steps are: create a customer, start checkout, collect payment, receive a verified webhook, provision access, then handle renewals, failures, and cancellations. Each step should be idempotent so a retry or a duplicate event never charges or grants twice.
The billing process, step by step
Customer + plan selection. The buyer picks a plan; you create or reuse a customer record with your provider and in your database.
Checkout. You start a checkout session; the provider securely collects the payment method (you never touch raw card data).
Payment + subscription creation. The provider charges and creates the subscription.
Webhook verification. The provider sends a signed event (for example,
checkout.session.completed); you verify the signature.Provisioning. On the verified event, you grant entitlements and store the subscription status.
Renewals. Each cycle the provider charges again and sends a renewal event.
Failures + dunning. On failed payment, the provider retries; you notify and, after a grace period, downgrade.
Cancellations + refunds. You revoke access at period end (or immediately) and handle refund events.
Why idempotency matters
Webhooks can arrive more than once and checkouts can be retried. If your handlers are not idempotent, you risk double-charging or double-granting access. The fix: record processed event IDs and make provisioning safe to run twice.
How this maps to FastStaq
FastStaq implements this exact flow. It uses Stripe Checkout (or Lemon Squeezy), verifies and deduplicates webhooks via StripeEvent / LemonSqueezyEvent ledgers, and runs an idempotent money path (provisionOneTimeGrant) so a replayed event never grants twice. Subscription state lives in Subscription with BillingInterval, and entitlements in PackageEntitlement. That makes the billing process reliable out of the box. See how subscription billing works and the billing guide.
Frequently asked questions
When should I grant access — on redirect or webhook? On the verified webhook. Redirects can be missed or spoofed.
How do I prevent duplicate charges? Make checkout and webhook handling idempotent by tracking processed event IDs.
What happens when a renewal payment fails? The provider retries (dunning); you notify the customer and downgrade after a grace period.
Next steps
Read how subscription billing works
See how to integrate Stripe with Next.js
Back to the SaaS billing guide
