Usage-Based Pricing: How to Meter and Bill

The value metric is the unit you charge for: API calls, messages sent, gigabytes stored, compute hours, transactions processed, active users. Stigg's guidance is that a good metric is one that aligns with customer value and that customers can understand and control.

Those three tests are worth applying one at a time:

m3ter cites a survey finding that the hardest part of deploying usage-based pricing is finding the right metric, and gives an example of a backend service for mobile games priced on the number of players. The customer already tracks players as their own measure of success, so the spend feels like "good" spend and is easy to forecast.

Two practical warnings. First, the metric must be something you can measure reliably in your own systems. If you cannot count it exactly, you cannot bill for it. Second, the metric should track your costs closely enough that heavy users do not make you lose money. A metric that customers love but that decouples from your infrastructure bill will eventually force a painful repricing.

Once you have a metric, you choose how the rate applies to it. Stripe lists the main types:

• Per unit. A fixed rate for every unit consumed.
• Tiered. The unit rate changes at thresholds.
• Pay as you go. No commitment, billed in arrears for exact usage.
• Prepayment. Customers buy a bucket of usage credits up front and draw it down.
• Hybrid. A recurring base fee with included usage, plus overage beyond it.

Tiered pricing has two variants that produce different bills for identical usage, and mixing them up is one of the most common pricing mistakes. Lago defines the difference:

In Lago's worked example, the same customer usage produces clearly different bills depending on whether overage is graduated or volume priced. Lago's advice is to model the amount immediately below and above every boundary before publishing the plan. If a customer can lower their bill by using slightly more, someone will notice.

For most SaaS products, Stripe suggests that a hybrid model combining a recurring base fee with variable usage overages gives the best balance of steady revenue and growth with adoption. Pure pay as you go suits infrastructure and API products whose own costs scale directly with usage.

Every usage billing system has the same stages. Lago describes them in sequence: the product emits an event for every billable action, a meter deduplicates and aggregates events per customer, rating applies the price plan, and the system generates an invoice, collects payment and retries failures.

Product action
   -> usage event (id, customer, type, quantity, timestamp)
   -> meter: validate, deduplicate, aggregate per customer and period
   -> rating: apply plan, allowances, tiers, negotiated rates
   -> invoice: line items traceable to metric and events
   -> payment, dunning, revenue recognition

The event. Ordway notes that each event typically includes a customer identifier, timestamp, event type and relevant properties such as quantity, and that the schema you define determines what you can bill for later. A minimal event looks like this:

{
  "id": "req_8f3a2c71",
  "customer_id": "cus_1042",
  "type": "api_call",
  "quantity": 1,
  "properties": { "region": "eu", "endpoint": "/v1/search" },
  "timestamp": "2026-10-17T09:14:03Z"
}

The meter. Aggregation turns events into a billable number. Lago lists the common functions: count, sum, max, unique count, last value and weighted sum. Check which ones your billing platform supports before you publish a price. UsageBox points out that some meters support only a few aggregations, so a metric like peak concurrent users must be computed upstream and reported as a resolved number.

Rating. This applies the price plan to the aggregated quantity. Lago recommends that you keep price versions dated so last month's invoice can be reproduced after a change. Without dated prices, a pricing change silently rewrites history.

The invoice. Each line should trace back to its metric and its events. Ordway calls this a full audit trail from raw event to invoice line item, and it is what lets you resolve a dispute in minutes instead of days.

Analytics pipelines tolerate small losses and duplicates. Billing pipelines cannot. UsageBox describes the two symmetric failures: over-counting from at-least-once delivery, where retries and redeliveries land the same action twice, and under-counting from events that arrive after the billing cut-off.

Deduplication. Attach a stable, unique identifier to every billable event and have the meter discard any identifier it has already seen within a window. The key rule from UsageBox: generate the identifier at the source of the billable action, not at send time. If your HTTP client creates a fresh ID on each retry, deduplication never catches anything. Where a natural key exists, such as a request ID or job ID, derive the event ID from it.

The same source recommends at-least-once delivery with exactly-once processing. Let clients and queues retry freely and rely on the identifier to fold duplicates at the meter. It quotes OpenMeter's position that it is better to report a usage twice and filter out duplicates later than to underreport it.

Late events. Every event carries the time the action happened, and the meter bills on that time, not on arrival time. m3ter describes this as event-time processing, based on your event timestamps, not arrival time, with late events backfilled into the correct billing period. Then hold the invoice open for a short acceptance window after the period closes so stragglers are counted. For events that arrive after the invoice is final, write down one policy: roll them into the current period, or issue a correction. UsageBox's warning is that the real failure is not picking either, so whoever is on call improvises.

Variable bills create a new kind of customer risk. Stripe names it directly: without automated usage alerts, spending caps or clear dashboards, customers may experience unexpected charges that lead to support tickets and churn.

Build these protections into the product:

1. A live usage dashboard. Show current-period usage and the projected bill, using the same numbers the invoice will use.
2. Threshold alerts. Email and in-app notices at levels the customer sets, such as half and most of their expected spend.
3. Spending caps. Let customers set a hard limit that stops or throttles usage. Some will choose interruption over surprise.
4. Commitments or prepaid credits. Stripe notes that companies use minimum spend commitments or prepaid credit models to create a predictable floor for both sides.
5. A readable invoice. Quantity, rate and amount on every line, with tiers broken out.

These features also protect you. A customer who can see their usage rising will raise a budget question in week two, not a dispute in week six.

Before you put a usage price in front of customers, run through this list. Lago recommends testing duplicate or late events, a midcycle plan change and a depleted credit balance, because those reveal more than a clean demo invoice.

• The value metric passes the value, understandable and controllable tests.
• The event schema is documented, with required fields and a stable ID minted at the source.
• The meter deduplicates on that ID and bills on event time.
• An acceptance window and a written late-event policy exist.
• Tier rules are modeled just below and just above every boundary.
• Price versions are dated so any old invoice can be reproduced.
• Every invoice line traces to a metric, a price version and the underlying events.
• Customers have a dashboard, alerts and an optional cap.
• Finance has agreed how usage, credits and invoices reconcile to the books, and revenue recognition has been reviewed with an accountant.
• You have replayed a month of real or realistic events through the whole pipeline and checked the totals by hand.

Usage pricing rewards the teams that treat the meter as financial infrastructure. Get the counting right first, and the pricing experiments that follow become cheap and safe.