Usage based billing and subscriptions, designed to stay correct
Usage based billing charges customers for what they consume – API calls, seats active this month, tokens, gigabytes – instead of, or on top of, a flat subscription. It’s easy to announce and hard to get right, because it turns billing into a data pipeline that has to be accurate, auditable and explainable to the customer.
I design and build SaaS billing systems: metering, plans, proration, dunning and entitlements, on Stripe Billing or a dedicated billing platform, with a clear view of which parts you should build and which you shouldn’t.
The four parts of a SaaS billing system
Most billing problems come from treating billing as one thing. It’s four, and they fail differently.
- Metering. Capturing usage events reliably, once each, with enough context to explain a line item later. Events need a stable idempotency identifier so retries don’t double-count, and a timestamp that decides which billing period they fall into.
- Rating and invoicing. Turning usage into money: tiers, volume pricing, included allowances, minimum commitments, credits, currency and tax.
- Collection and dunning. Charging the card, retrying failed payments on a sensible schedule, emailing the customer, and deciding when to downgrade or suspend.
- Entitlements. What the customer is allowed to do right now. This is the part product teams forget, and it’s where most “why can this free user export?” bugs come from.
Keeping these separate in your code is the single most useful design decision. Entitlements in particular should be read from your own database, updated from billing events, and never looked up live from the processor on every request.
Proration, plan changes and the edge cases
Subscription billing gets complicated at the edges, and the edges are where support tickets come from. Before writing code I want answers to questions like these:
- Does an upgrade take effect immediately with a prorated charge, or at the next renewal?
- Does a downgrade refund, credit, or simply apply next period?
- What happens to unused included usage when a customer changes plan mid-cycle?
- If a card fails at renewal, does the customer keep access during dunning, and for how long?
- How do annual contracts with monthly usage overages invoice?
- Who can issue a credit, and where is it recorded?
Stripe Billing handles proration mechanically, but it can’t decide your policy. Writing the policy down first saves weeks of rework.
Build vs buy for usage based billing
Don’t build a billing engine unless billing is your product. For most SaaS companies the right shape is a bought billing system plus a thin, well-tested layer of your own for metering ingestion and entitlements.
Stripe Billing covers subscriptions, proration, invoicing and retries, and has usage-based pricing through billing meters. It’s the sensible default if you already take payments with Stripe and your pricing fits its model. Dedicated usage billing platforms such as Orb or Lago – and Metronome, which Stripe acquired in January 2026 – add stronger metering, more flexible rating and better tooling for complex contracts and commitments, at the cost of another product and another integration to keep consistent. I don’t quote pricing for any of these; check their current pages, because it changes.
The test I use: if finance is building invoices in a spreadsheet each month because the tool can’t express your contracts, it’s time to move up. If you have three plans and a per-seat price, you don’t need anything beyond Stripe Billing. My build vs buy guide covers the general version of this decision.
What I deliver
- A written billing model: plans, prices, meters, proration and dunning policy, agreed with product and finance before any code.
- A Stripe Billing integration (or other platform) driven by webhooks, with signature verification, deduplication and replay. The Stripe webhooks guide covers how I build that part.
- A metering pipeline that’s idempotent and auditable, so you can show a customer exactly what they were billed for.
- An entitlements service in your own database, so product features check one place.
- Reconciliation between invoices, payments and your internal records. See payment reconciliation.
- Migration of existing subscribers to new pricing without surprise charges.
Why me
Payments and billing are where I’ve spent the most time. I built the payment platform at Yola as it scaled to 11M users, architected the payment integrations for BLU Loyalty, and led architecture at Indiemaker on Stripe. The lessons went into Payments Playbook, the book I spent seven years writing. Billing is a close cousin of payments: the same need for idempotency, audit trails and reconciliation, with more product decisions on top.
For the payment side of the work, see payment integration services.
Questions
What is usage based billing?
Usage based billing is a pricing model where customers pay according to how much of the product they consume, such as API requests, compute or active seats, rather than a fixed fee alone. It’s often combined with a base subscription or minimum commitment and requires accurate metering.
Should we build our own billing system?
Almost never. Build the parts that are specific to your product – usage capture and entitlements – and buy the invoicing, proration, tax and payment retry logic. Billing engines look simple and accumulate edge cases for years.
Is Stripe Billing enough for usage based pricing?
For many SaaS companies, yes. Stripe Billing supports metered usage, tiers and subscriptions. Teams with complex enterprise contracts, real-time credit burn-down or high event volume often outgrow it and move to a dedicated usage billing platform.
How do you avoid double-counting usage?
Give every usage event a unique identifier at the source, deduplicate on ingestion, and aggregate from stored events rather than incrementing counters in place. That way retries are harmless and every invoice line can be traced back to raw events.
What is dunning?
Dunning is the process of recovering failed subscription payments: retrying the charge on a schedule, notifying the customer, prompting them to update their card, and eventually downgrading or cancelling if payment never succeeds.
Planning a pricing change?
Tell me the pricing model you want and the billing setup you have. In a two-week sprint I’ll design the billing model and ship the riskiest piece first.
GMT+2 · Full EU overlap · US East mornings