Usage-based (metered) billing

Price scales with what people actually consume. You meter the calls, tokens, or gigabytes, then bill the total at period end.

charge per API callpay for what you usemetered billingconsumption-based pricingpay as you go billingbill them for the tokens they burnedusage based billlingcharge by the gigabyte

See it

Live demo coming soon

What it is

Usage-based billing turns the invoice into a function of measured consumption: API calls, tokens, seats-hours, gigabytes stored, minutes transcoded. You emit a usage event every time the thing happens, a meter aggregates those events over the period (sum, max, or last value wins), and the total gets charged in arrears at period close. This is how OpenAI, Twilio, and AWS price, and it is the default for anything whose unit cost you actually pay downstream.

Reach for it when your cost per customer varies wildly and a flat fee either bankrupts you on the heavy user or overcharges the light one. The usual shape is hybrid pricing: a fixed platform fee for predictability plus metered units on top. Price in credits or units rather than raw vendor cost, so your margin survives an upstream price change.

Two gotchas. First, usage events arrive late and duplicated, so send an idempotency key with every event and decide what happens to a call that lands after the invoice already closed (most teams roll it into the next period). Second, bill shock: a customer who leaks a key and wakes up to a 4,000 dollar invoice will dispute it. Ship spend caps, threshold alerts, and a live usage meter in the dashboard before you ship the pricing.

Ask AI for it

Implement usage-based (metered) billing for this product. Create a meter per billable unit (for example 'api_requests' and 'tokens_out'), and emit a usage event from the server every time the unit is consumed, with a customer id, quantity, timestamp, and an idempotency key so retries never double-count. Aggregate by sum over the billing period, expose a current-period usage endpoint plus a dashboard meter, and invoice the total in arrears at period close alongside the fixed subscription fee. Add a configurable spend cap with alerts at 50, 80, and 100 percent, and roll late-arriving events into the next period instead of reopening a closed invoice.

You might have meant

overageprepaid creditsprorationsubscription billing