What is usage-based billing?

Usage-based billing (also called metered billing or consumption billing) charges customers based on how much they actually use, rather than a flat monthly fee. Common models include charging per API call, per active seat, per gigabyte of storage, per SMS sent, or per AI token consumed. Customers pay for what they use — nothing more.

This model is increasingly common in SaaS, particularly in API products, developer tools, and AI products where marginal costs are real and usage varies significantly between customers. It better aligns pricing with value but introduces real complexity: you need to accurately track and aggregate usage, present it clearly to customers, handle overage correctly, and generate invoices that reflect it.

Stripe has built metered billing infrastructure specifically for this — Stripe Meters and usage records — that reduces implementation work, but there's still substantial application-level instrumentation needed.

When does your app need it?

• You're building an API product or developer platform where different customers will use vastly different volumes
• Your marginal cost scales with usage (compute, storage, SMS, AI inference) and a flat fee would undercut profitability at high volumes
• You want to offer a low entry price (or free tier) and charge customers as they grow — without renegotiating plans
• You're building an AI product and charging per token, per generation, or per API call
• Your customers have unpredictable usage patterns and flat-rate pricing would either overprice low-usage customers or undercharge high-usage ones
• You want granular billing line items on invoices so customers can see exactly what they were charged for

How much does it cost?

Adding usage-based billing typically adds 11–21 hours of development — roughly $2,000–$5,000 AUD.

At the lower end: basic metered billing using Stripe's usage records API. Your app reports usage events to Stripe at the end of each billing period, Stripe aggregates them and charges the customer. Simple aggregation, one or two meters.

At the higher end: real-time usage tracking with multiple meters (e.g., seats + API calls + storage), a usage dashboard for customers showing current period consumption and cost projections, overage alerts at configurable thresholds, per-customer pricing tiers with volume discounts, carry-forward credits, and detailed invoice line items. The usage tracking infrastructure — instrumenting every metered event in your application and aggregating it reliably — is the most time-consuming part.

How it's typically built

Stripe Meters (introduced 2024) are the current recommended approach. You define meters in Stripe (e.g., "api_calls", "storage_gb"), and your app sends meter events to Stripe's API whenever a billable action occurs. Stripe aggregates the events over the billing period and automatically generates invoice line items.

For high-volume applications, calling the Stripe API on every event is impractical. Instead, events are queued in your database or a queue service (Redis, SQS) and flushed to Stripe in batches — or aggregated in your own database and reported as a summary at billing period close.

Usage tracking in your application involves instrumenting every metered action: wrapping API route handlers, storage operations, or AI inference calls to emit a billing event. These events are stored with a timestamp, user ID, organisation ID, meter type, and quantity.

Customer-facing usage dashboards query your usage events table and display current-period consumption with a projected cost. Real-time or near-real-time displays require a fast aggregation query or a pre-computed counter.

Overage alerts are typically implemented as a scheduled job that checks current-period usage against a threshold and sends an email notification (once) when the threshold is crossed.

Questions to ask your developer

• How are usage events tracked — in your database or sent directly to Stripe? For high-volume apps, your own usage table is more reliable and queryable than Stripe as the system of record.
• How are billing period cutoffs handled? Usage that occurs during the period transition needs to be attributed to the correct period reliably.
• Can customers see their usage in real time? A usage dashboard reduces billing surprises and support tickets.
• How are overage alerts implemented? Customers should know before they exceed limits, not after they receive an unexpectedly large invoice.
• How are usage events deduplicated? If your app retries failed event submissions, you need idempotency keys to avoid double-counting.

---

See also: Subscription billing · One-off payments · Invoicing and PDF generation · App cost calculator