Stripe usage-based billing charges a customer for what they consumed in a billing period. You report usage to Stripe as meter events, a meter totals them, a usage-based price turns the total into an amount, and the amount lands on an invoice after the period ends.
This explainer is drawn only from Stripe's documentation and pricing pages as they read in October 2026. It describes, and doesn't recommend. Billing Model isn't affiliated with Stripe, and the docs change, so confirm current behavior there before you rely on a detail.
Quick answer: In Stripe usage-based billing, a meter aggregates meter events (by sum, count or last value) for each customer over the billing period. A usage-based price attached to the meter rates the total per unit, per package or by tier, and Stripe invoices it in arrears. Stripe's docs now point new integrations to Metronome, a Stripe product, and keep the meter-based route for existing ones.
Two routes in Stripe's documentation
Stripe's docs describe two ways to bill for usage, and they say plainly which one they prefer. The page on basic usage-based billing calls Metronome, a usage-based billing platform that is now part of Stripe, the primary route "recommended for all new integrations". The meter-based method is described as a lower-level primitive that remains fully supported for businesses already using it.
Stripe's comparison page sets them side by side.
| Basic usage-based billing (meters) | Metronome | |
|---|---|---|
| Pay as you go | Supported | Supported |
| Flat fee plus overages | Supported | Supported |
| Credits | Supported, applied at invoice time | Supported, in real time |
| Prepaid drawdown, commitments, minimums | Not supported | Supported |
| Real-time usage visibility | Not supported | Supported |
| Stripe Dashboard and Connect | Supported | Not supported |
That is Stripe's own position on its own products, reported here as such. The rest of this article explains the meter-based route: meters, meter events and usage prices.
On names: Stripe's older method, usage records, is now labeled legacy, and that page still speaks of a "metered billing integration". In the API, a usage-based price is one whose usage type is metered. "Metered billing" in an older Stripe guide refers to the same model.
The model itself isn't Stripe's invention. The US National Institute of Standards and Technology lists "measured service" as a characteristic of cloud computing: resource use is metered, monitored and reported so that provider and customer can both see it. The guide to usage-based pricing explains the general case.
How Stripe usage-based billing works with meters
Four pieces sit between a customer's activity and their bill.
Meter events are the raw records. Stripe's page on recording usage with the API says each one carries the event name, the customer's ID, a numerical value and an optional timestamp. Values can be decimals. You can send events one at a time or in batches, and Stripe also documents a CSV upload in the Dashboard and a bulk route through Amazon S3.
The meter says how those events become one number. Stripe's page on configuring a meter gives three aggregation formulas.
| Formula | What is billed | A fit for |
|---|---|---|
| Sum | The total of all values in the period | Tokens, minutes, gigabytes transferred |
| Count | The number of events in the period | API calls, messages |
| Last | The most recent value reported in the period | A level, such as seats in use |
The examples in the third column are illustrations. After a meter is configured, the page says, nothing about it can be changed except its display name.
The usage-based price is attached to the meter and sets the rate. The subscription ties a customer to that price, and at the end of each period it produces the invoice.
From meter totals to invoice lines, using the worked example below.
Usage-based prices: per unit, per package and tiers
Stripe's pay-as-you-go guide offers three pricing structures when you create a usage-based price.
- Per unit. One rate for each unit the meter reports.
- Per package. One rate for a block of units. Stripe's own example charges 0.04 USD per 100 tokens, and its sample API call rounds a partial package up.
- Per tier. The unit rate changes with quantity, in one of two modes.
The two tier modes give different totals from the same table. In Stripe's tiered pricing page, with rates of 7 USD for units 1 to 5 and 6.50 USD for units 6 to 10, a customer with 6 units pays 39 USD under volume-based pricing (all 6 at 6.50) and 41.50 USD under graduated pricing (5 at 7.00 plus 1 at 6.50). The guide to tiered pricing examples works through both methods.
A tier can also carry a flat amount, which is how a fee with an included allowance is built. Stripe's legacy page shows one such table: 10 USD covers the first 10,000 requests and each request after that costs 0.10 USD.
How usage is invoiced in arrears
Usage is billed after the fact. Stripe's guide says pay-as-you-go pricing charges customers in arrears for the usage they accrue, with an invoice at the end of each billing interval. The billing period is the window the meter totals.
The handover from one period to the next has a short buffer. Stripe's page on the invoice finalization grace period says every invoice has a default grace period of 1 hour before it is finalized, during which you can still report usage for the period that just ended. You can extend it to as much as 72 hours.
Three more behaviors are documented:
- First invoice. A new subscription has no prior usage to bill. Depending on its billing mode, Stripe either leaves usage lines off the first invoice or adds them at zero.
- Proration. Usage-based charges aren't prorated when a plan changes.
- Sign-up. Payment links aren't supported for usage-based billing, and customers can't update a usage-based subscription in the customer portal. The guide to Stripe recurring payments covers those tools.
Worked example: one month's bill
Take a hypothetical transcription service that bills monthly through meters, with three prices on each subscription:
- Platform fee: $30 per month, a flat price
- Minutes transcribed, on a meter that sums: $0.020 per minute for minutes 1 to 5,000 and $0.015 per minute from 5,001 up, graduated
- Exports, on a second meter that sums: $0.50 per package of 100, with a partial package rounded up
In September 2026 one customer's meter events add up to 8,400 minutes and 2,350 exports.
Step 1: meter. The two meters report 8,400 and 2,350.
Step 2: rate. Minutes: 5,000 × $0.020 = $100.00, and the remaining 3,400 × $0.015 = $51.00, so $151.00. Exports: 2,350 ÷ 100 = 23.5, rounded up to 24 packages, and 24 × $0.50 = $12.00.
Step 3: bill.
| Line item | Quantity | Rate | Amount |
|---|---|---|---|
| Platform fee | 1 month | $30.00 | $30.00 |
| Minutes, first tier | 5,000 | $0.020 | $100.00 |
| Minutes, second tier | 3,400 | $0.015 | $51.00 |
| Exports | 24 packages | $0.50 | $12.00 |
| Total | $193.00 |
Which month's platform fee sits beside September's usage depends on how the flat price is billed, since fixed fees are commonly billed in advance.
Had the minutes price been volume-based, all 8,400 minutes would be charged at $0.015: 8,400 × $0.015 = $126.00, which is $25.00 less than the graduated $151.00.
Now suppose 600 more September minutes are reported three hours after the period ends, with the grace period left at 1 hour. At the second-tier rate they are worth 600 × $0.015 = $9.00. Stripe's docs say usage reported beyond the grace period can be accepted and shown in meter summaries, but it isn't added to the finalized invoice or to the next one. The $9.00 goes unbilled.
Thresholds, credits and alerts
Three add-ons change when or how much a customer is charged. All are described on Stripe's pages for monitoring usage and billing credits.
Alerts notify you when a customer passes a usage level on a meter, for instance so you can email them. You can create up to 25 alerts for each combination of meter and customer.
Billing thresholds issue an invoice as soon as accrued usage reaches a set amount, instead of waiting for period end. They don't apply to trials, and Stripe warns that the invoiced amount can come out slightly above the threshold.
Billing credits are prepaid or promotional amounts, recorded as credit grants, that pay down usage. They apply only to usage-based lines, after discounts and before taxes, at the moment an invoice is finalized. In the example above, a $50 promotional grant would reduce the usage lines from $163.00 to $113.00 and leave the $30.00 platform fee untouched, for an invoice of $143.00. Because credits are reconciled only at invoice time, the comparison page notes, a customer can exceed their balance during the cycle.
Limits and things to check
| Topic | What Stripe's docs say |
|---|---|
| Late events | A timestamp must be within the past 35 calendar days and no more than 5 minutes in the future. Acceptance doesn't guarantee the usage is invoiced |
| Corrections | An event can be canceled only within 24 hours of being sent. A finalized invoice isn't updated |
| Delay | Meter events are processed asynchronously, so totals and upcoming invoices can lag |
| Time zones | Hourly and daily windows for pre-aggregated events follow the timestamp in UTC. Billing cycle anchors use UTC too |
| Plan changes | If a price changes mid-cycle, usage reported during the grace period isn't captured |
| Volume | 1,000 meter event calls per second in live mode, or up to 10,000 events per second through the high-throughput API |
| Testing | Sandboxes are available, and alerts don't work with test clocks |
| Cost | Stripe's Billing pricing page lists 0.7% of Billing volume on the pay-as-you-go plan, with basic usage-based billing and up to 100 million events a month included. Metronome is listed as "Contact Metronome" (US page, checked October 2026) |
The time-zone row has a practical consequence. A billing period runs from one anchor timestamp to the next, so the "September" on an invoice may not match the calendar month where your customer sits. Print the period's start and end on the invoice, and send usage with its own timestamp instead of relying on arrival time.
Watch out: Report usage continuously, not in one batch at month end. A batch that arrives after the grace period is accepted by the meter and missing from the invoice.
Frequently asked questions
Is metered billing the same as usage-based billing in Stripe?
They refer to the same model. Stripe's current docs use "usage-based billing", its legacy usage records page still says "metered billing", and the API marks usage prices as metered. The mechanics differ between the legacy method, meters and Metronome.
Does Stripe bill usage in advance or in arrears?
In arrears. Stripe's guide says customers are invoiced at the end of each billing interval for the usage they accrued. A flat fee on the same subscription can still be billed in advance.
What happens to usage reported late?
Stripe accepts events with timestamps up to 35 calendar days old, but usage has to arrive before the invoice for its period is finalized. After that it can appear in meter summaries without being added to that invoice or the next.
Should a new integration use meters or Metronome?
Stripe's docs say Metronome for new integrations, and say existing meter-based integrations don't need to migrate. Which fits your pricing is your decision. The comparison page lists what each supports.
Can a Stripe subscription mix a flat fee with usage?
Yes. Stripe's comparison page lists flat fee plus overages as supported on both routes, and a tier can carry a flat amount as well as a unit price.
