Usage-based billing without the headaches
Metering, dunning, and proration explained — the architecture behind reliable SaaS revenue.
Usage-based billing sounds simple — count the things, multiply by the price — until the first dispute, the first mid-cycle plan change, and the first webhook that arrives twice.
The architecture that survives: meter events into an append-only table first, aggregate on a schedule, and treat Stripe as the source of truth for money while your database stays the source of truth for usage. Never compute an invoice from live counters.
Idempotency is non-negotiable. Every webhook handler must be safe to run twice, because it will run twice. Store processed event IDs, make state transitions explicit, and reconcile against Stripe nightly — silent drift between your records and theirs is how billing bugs become refund seasons.
Dunning is where revenue quietly dies: a failed card with no retry strategy is churn you caused. Smart retries, pre-expiry emails, and a grace period recover a surprising share of 'lost' customers — ours was 41%.