Subscription payments and recurring billing: what to get right
How recurring billing actually works, the parts that trip people up, trials, proration, failed payments, and when to use Stripe Billing versus building your own.
Charging a customer once is easy. Charging them every month, forever, without losing track of who’s on which plan, whose card just failed, and who upgraded halfway through the cycle, is where recurring billing gets deceptively hard. If you’re building a SaaS or any subscription product, this is one of the parts most likely to bite you, so let me walk through what actually matters.
I’ll cover the pieces that trip people up and the decision that saves the most time: how much of this you should build versus let a billing platform handle.
Recurring billing is more than “charge every month”
The naive picture is a card charged on a schedule. The real picture includes trials that convert (or don’t), upgrades and downgrades mid-cycle, proration when a plan changes, taxes that vary by country, invoices and receipts, and, above all, failed payments. Cards expire and get declined constantly; how you handle that quietly determines a big chunk of your revenue.
Underestimating this is the classic mistake. “Just charge them monthly” turns into a dozen edge cases the moment you have real customers.
The pieces that actually matter
When I scope billing, these are the decisions that shape it:
- Plans and pricing: flat tiers are simple; usage-based, seats, and add-ons get complex fast.
- Trials and conversions: free trials, when they convert, and what happens if a card fails at conversion.
- Proration: when someone changes plans mid-cycle, you have to charge or credit the difference fairly.
- Dunning: the process of retrying failed payments and nudging customers before you lose them.
- Invoicing and tax: receipts, invoices, and sales tax/VAT that depends on where the customer is.
None of these is glamorous, and all of them cost you money if you get them wrong.
Failed payments: the silent revenue leak
Here’s the one people skip and regret: a meaningful share of subscription churn isn’t customers deciding to leave, it’s cards failing and never getting retried. This is called involuntary churn, and it’s often the cheapest revenue you’ll ever recover. A good billing setup retries intelligently, emails the customer to update their card, and gives them a grace period before cutting access. Skip this and you’re leaking money you already earned.
Build it, or use a billing platform?
Here’s the decision that saves the most time. Platforms like Stripe Billing already handle plans, proration, trials, dunning, invoicing and tax, years of edge cases you’d otherwise rebuild badly. For the vast majority of products, you use the platform and build your product on top of it, not the billing engine from scratch.
You build custom billing logic only when your pricing is genuinely unusual, complex usage metering, marketplace splits, or requirements a platform can’t express. Even then, you build on the platform’s rails, not instead of them. Rebuilding billing from zero is one of the most expensive wrong turns a startup can take, the same “don’t rebuild what you can buy” logic I cover in build vs buy.
It’s part of your SaaS budget
Billing is a real chunk of building a subscription product, one of the pieces I flag in how much a SaaS costs. The good news is that leaning on a platform keeps it manageable; the bad news is that pretending it’s trivial guarantees rework. Budget for it as real engineering, because handling other people’s money correctly is exactly where “close enough” isn’t good enough.
Get the integration right, not just the charge
The charge is the easy part; the integration is where correctness lives. Your system and the billing platform have to stay in sync through webhooks, when a payment succeeds, fails, or a subscription changes, your app has to react reliably, even if the same event arrives twice. Getting that right (idempotent, verified, in sync) is what separates billing that just works from billing that quietly corrupts who-has-access-to-what.
How we approach billing
At AppsColombia we build subscription products on proven billing rails (Stripe and equivalents) rather than reinventing them, so your budget goes to your product, not to rebuilding proration. We handle the integration carefully, reliable webhooks, dunning for failed payments, access in sync with subscription state, because that’s where the money leaks otherwise. If you’re building something with recurring revenue, let’s talk.
Conclusion
Recurring billing looks like “charge every month” and turns out to be trials, proration, tax, and, above all, failed payments, the silent leak that quietly churns customers who never meant to leave.
For almost everyone, the right move is to build on a billing platform, not rebuild one, and to get the integration reliably in sync. Handle the money correctly and the recurring part of recurring revenue takes care of itself.