Subscription billing is the engine of a SaaS business. It turns sign-ups into revenue, month after month. It is also full of edge cases: a customer upgrades mid-month, a card expires, a company needs an invoice with its tax number, a customer in another country owes sales tax. Each needs a clear answer.
This guide covers what a billing setup needs, how to choose a provider and how to connect it to your product.
Do not build payments yourself
Use a billing provider for payment processing, card storage, recurring charges and invoices. Providers handle card security rules, retries, receipts and many payment methods. Building this yourself is slow, risky and rarely worth it. Your job is to connect the provider to your product: plans, access and limits.
Choosing a provider
- Payment platforms with billing features, such as Stripe Billing: flexible, widely used, with many integrations. You are responsible for sales tax, though tools help.
- Merchant-of-record services, such as Paddle: they sell on your behalf and handle sales tax and VAT worldwide, for a higher fee.
- Subscription management tools that sit on top of a payment platform, for complex pricing or revenue reporting.
Compare fees, tax handling, supported countries and payment methods, invoicing features and how well the provider fits your pricing model. See our Stripe and PayPal entries for AI tooling around them.
Define your pricing model
Before building, write down exactly how pricing works:
- Flat plans: fixed price per month or year.
- Per seat: price per user.
- Usage-based: price by volume, such as messages or storage.
- Hybrid: a base plan with usage on top.
Also decide on monthly and annual billing, discounts, currencies and what each plan includes. Simple pricing is easier to build, explain and change.
What lives in your app
The provider knows who pays what. Your app needs to know what each customer is allowed to do. Keep in your app:
- Plan features and limits, such as number of users or projects.
- The customer's current plan and status: trialing, active, past due, canceled.
- Usage counts, if you bill by usage or enforce limits.
Enforce limits in the app, with clear messages and a path to upgrade.
Keep in sync with webhooks
Billing events happen at the provider: payments succeed or fail, subscriptions renew or cancel. The provider sends these events to your app through webhooks. Your app updates the customer's status in response. Handle them carefully:
- Verify each webhook's signature.
- Process each event once, even if it arrives twice.
- Handle events arriving out of order.
- Log every event for troubleshooting.
Trials
Decide the trial length, whether a card is needed to start and what happens when it ends. Card-required trials usually convert a higher share of trials but get fewer sign-ups. Send reminders before the trial ends, and make upgrading easy from inside the product.
Upgrades, downgrades and cancellations
- Upgrades: usually immediate, with a prorated charge for the rest of the period.
- Downgrades: often at the end of the period, with a check that the customer fits the smaller plan's limits.
- Cancellations: usually at the end of the paid period. Ask why, and consider offering a pause.
Most providers offer a hosted customer portal for these changes, which saves building screens yourself.
Failed payments
Cards expire and payments fail. Without a plan, this quietly loses revenue. Use the provider's automatic retries, send clear reminder emails with a link to update the card and give a grace period before limiting access. Show a banner in the app for past-due accounts. This process is often called dunning.
Taxes and invoices
Sales tax and VAT rules depend on where you and your customers are. Some providers calculate tax automatically; merchant-of-record services take responsibility for it. Business customers need invoices with correct details, such as their company name and tax number. Get advice from an accountant on your obligations before launch.
B2B needs
Larger customers may want to pay by invoice rather than card, sign annual contracts, have custom prices or require purchase order numbers on invoices. Decide early which of these you support. Many providers handle invoice payments, but custom contracts often need manual steps.
Billing in multi-tenant products
In most SaaS products, the billing account is the tenant, not the individual user. Map each tenant to a customer in the billing provider, and enforce plan limits per tenant. See multi-tenant SaaS architecture explained.
Test every event
Providers offer test modes with test cards for success, failure and special cases. Test sign-up, trial end, upgrade, downgrade, cancellation, failed payment, card update and refund. Test webhooks arriving twice and out of order. Billing bugs cost real money and trust, so this step is worth the time.
Revenue reporting
Track monthly recurring revenue, churn, upgrades and failed payment recovery. Providers include basic reports; dedicated tools add more. Decide which numbers you will watch weekly. See how to set up automated reporting.
Billing for an MVP
For a first version, keep it simple: one or two plans, monthly and annual, the provider's hosted checkout and customer portal and webhooks to update status. Add usage billing, custom contracts and advanced features when customers ask. See how to plan a SaaS MVP.
Billing emails
Customers expect clear emails at each step: welcome and receipt, trial ending, payment received, payment failed, card expiring, plan changed and subscription canceled. Providers send many of these, but check the wording and branding match your product. Make sure each email has a clear link to act, such as updating a card or managing the plan. Good billing emails reduce support requests and recover payments that would otherwise be lost.
Security and compliance
Letting the provider handle card details keeps most card security rules outside your system. You still need to protect the billing-related data you hold, restrict who in your team can issue refunds or change plans and log those actions. For AI tools that read billing data, give read-only access. See MCP security best practices.
Common mistakes
- Trusting the browser to report a successful payment instead of webhooks.
- No plan for failed payments.
- Ignoring sales tax until it becomes a problem.
- Pricing so complex it is hard to build and explain.
- Not testing edge cases before launch.
Checklist
- Provider chosen for fees, tax and features.
- Pricing model written down.
- Plan limits enforced in the app.
- Webhooks verified, idempotent and logged.
- Trials, changes and cancellations defined.
- Failed payment process in place.
- Tax and invoice requirements checked.
- All events tested in test mode.
Billing is never finished. As the product grows, pricing changes, new countries open and larger customers arrive with new requests. A clean setup, with the provider handling money and your app handling access, makes each of those changes a small project rather than a rebuild.