Metered billing
Metered billing records how much of a product each customer uses during a period and bills them for that measured amount at the end of the period.
Metered billing is the plumbing behind usage-based pricing. Your product records usage events (API calls, messages sent, gigabytes stored), the billing system adds them up per customer for the period, and the invoice is generated from the total. Pricing decides what to charge for; metering is how you measure it.
How it works
- Define a billable event. What exactly counts: a request, a successful request, a unique active user in the month?
- Record usage. Your app sends events to the billing system as they happen, or in batches.
- Aggregate. Sum, count or take the maximum over the billing period.
- Price it. Apply a per-unit rate, a graduated or volume tier, or an allowance with overage.
- Invoice and collect. Usage is typically billed in arrears, after the period ends.
For example, a $20 platform fee, then 50,000 events at $0.002 for the first 20,000 and $0.0015 for the rest. That is $20 + (20,000 x $0.002) + (30,000 x $0.0015) = $20 + $40 + $45 = $105.
Stripe's approach
Stripe describes usage-based billing as a common pricing model for SaaS that lets you charge by consumption, and offers two routes: the classic Billing Meters API for existing integrations and Metronome, now part of Stripe, as its main platform for new usage-billing integrations. Stripe notes that classic Billing Meters reconciles usage only at billing time, while Metronome gives real-time visibility and supports prepaid credits and enterprise contracts (source). Check the current documentation before you build, since the recommended route has changed.
Metered billing vs adjacent ideas
- Usage-based pricing is the pricing decision. Metered billing is the mechanism that delivers it.
- Licensed billing charges for a quantity you set in advance, such as seats. Changing it mid-period triggers proration. Metered charges are billed after the fact, so they are not prorated.
- Pre-paid credits have the customer buy a balance first, which changes cash flow: you hold the cash as deferred revenue until the credits are used.
What can go wrong
- Metering bugs. Double-counted or lost events become wrong invoices. Use idempotency keys and reconcile totals against your own logs.
- Delayed visibility. If customers cannot see usage until the invoice arrives, you get bill shock and disputes. Expose a live usage page.
- Unpredictable revenue. Your forecast now depends on usage. Many teams combine a committed minimum with metered usage above it.
- Timing. Usage billed in arrears means you carry the cost before you collect. Watch cash if your costs run ahead of your invoices.
For a small SaaS, a billing platform that handles metering is worth paying for. Building event aggregation, tiered pricing and invoicing yourself is a project that tends to run into months.
Related terms
Sources
- Usage-based billing, Stripe documentation
- Prorations, Stripe documentation
- Overage charges: definition, structure and best practices, Solvimon