Metered billing on Stripe.

How metered billing works on Stripe

One change first. Stripe now calls Meters "basic usage-based billing" and recommends Metronome, now part of Stripe, for new integrations, while keeping Meters fully supported for existing ones (Stripe docs, checked Oct 18, 2026). Meters also replaced Stripe's older usage records API. For setup steps, follow Stripe's usage-based billing docs. This guide covers what the setup means for churn.

Stripe metered billing rests on four pieces: a meter, meter events, a usage-based price and a subscription. You report usage as it happens, Stripe totals it per customer, and at the end of the billing period it prices the total and puts it on the invoice.

The meter decides how events add up. Sum adds up the values (tokens, minutes, gigabytes). Count bills the number of events (API calls). Last bills the most recent value reported in the period. A meter's settings can't be changed after you create it, apart from its display name, so choose the aggregation with care.

Each meter event carries the event name, the Stripe customer ID, a number and an optional timestamp. Stripe accepts events up to 35 days old and no more than 5 minutes in the future, but usage only reaches an invoice if it arrives before that invoice is finalized. Events are processed asynchronously, so the upcoming invoice can trail real usage slightly. A wrong event can be canceled within 24 hours, or corrected with a negative value.

The usage-based price is a recurring price set to metered and linked to the meter. It can charge per unit, per package (per 100 tokens, say) or in tiers. One subscription can hold a metered price next to a flat one, which is how a platform fee plus usage works.

Usage-based vs metered billing

Usage-based billing is the pricing model: customers pay for what they use. Metered billing is the mechanism: usage is measured during the period and billed after it. Stripe uses both terms. In its API, a metered price is the opposite of a licensed one, where the quantity is set up front and billed in advance, like seats.

Stripe usage-based billing covers a few common shapes:

• Pay as you go. Every unit is metered and billed in arrears. Typical for APIs and AI products.
• Flat fee plus usage. A platform fee billed in advance, plus metered usage or overage billed after. Often called hybrid pricing.
• Credits. Customers buy or receive credits that usage draws down. In Stripe's basic usage-based billing, credits are applied only when the invoice is finalized, so a customer can run past their balance mid-cycle.

The difference matters for churn because of timing. On a licensed seat plan, a cut shows in Stripe the moment the customer lowers the quantity. On a metered plan, nothing in billing changes until the period closes.

How churn shows up on usage plans

On a usage plan, churn rarely starts with a cancel. Usage fades first, the invoice drops a period later, and the subscription often stays active the whole time. Stripe's own guide to usage-based billing says churn under usage pricing "is often more gradual" (Stripe, last updated Mar 20, 2025).

Three things make it easy to miss:

• No event fires. A customer who stops sending usage doesn't cancel and doesn't fail a payment. The subscription stays active, and the invoice simply gets smaller.
• Billing lags. Because usage is billed in arrears, a drop in the first week of a monthly period first appears in billing when that period closes.
• MRR leaves it out. Stripe's Billing overview excludes metered products from MRR, with usage MRR offered only as a preview (Stripe docs, checked Oct 18, 2026). Watch Stripe's MRR alone and a fading usage customer doesn't register.

Example: a customer averaging $1,200/mo in usage sends 40% fewer events in the first two weeks of the month. Nothing in Stripe changes until the month-end invoice comes in lower, and the full drop only shows on the one after.

On hybrid plans it hides better still. The platform fee keeps paying while usage fades, so the account looks stable until the customer cancels the base too.

To see this in money, you need one rule for usage revenue and the same rule everywhere you measure. A sound one is the average of the customer's last 3 metered invoices, added to any flat fee. Contraction then reads as a fall in that average. The MRR calculator explains how annual plans, discounts and usage change the number. A usage-only customer whose usage keeps sliding is fading; one who has stopped using the product while the subscription stays open has churned in all but name.

The signals worth watching

Watch usage against each customer's own baseline, not against other customers. A small account using steadily is fine. A large account using a third less than last quarter is not.

The signals that matter on usage plans:

1. A steady decline over several weeks against the customer's own recent average. One quiet week is noise; four in a row is a pattern.
2. Idle customers: no usage in 28 days while the subscription is still open. Track the share of customers who are idle each month.
3. Usage revenue per customer: the average of the last 3 metered invoices against the 3 before.
4. Usage-based NRR: whether existing customers spend more or less over time, which shows contraction across the whole base.
5. A meter going quiet. If a customer uses several meters and one stops, a feature or a workflow has left.
6. Billing signals, which still count: a failed payment, a scheduled cancel or a discount about to end.

Know your quiet months. A drop during a month that is always slow shouldn't raise alarm on its own.

The right response is usually a question, not a discount. A short note that names what the customer stopped using, and asks why, gets to the reason. A discount doesn't help a customer who isn't using the product. For a valuable customer whose usage dropped, a one-off usage credit fits better. For one with steady usage who says the price is too high, try a committed-spend plan: a lower unit price for a monthly minimum.

North Metric reads usage from Stripe Meters for customers on usage and fixed plus usage plans, flags usage drops against each customer's own baseline, and shows usage-only customers as fading before they stop. It doesn't read Metronome at launch. You mark your quiet months, and a drop inside one shows as "Seasonal?" without raising risk on its own. See how it works for usage-based SaaS, where the usual first move is a check-in that names what changed.