Stripe now steers new usage-based billing toward Metronome

The workload

Billing a customer for metered usage rather than a flat subscription requires recording usage events against a customer's account, aggregating them into a billing period, and reconciling that total against the agreed price, all before an invoice can be generated correctly. Verified: Stripe's own usage-based billing documentation, retrieved 16 September 2026, describes two paths: Metronome, which Stripe states is now part of Stripe and recommends for all new integrations, and basic usage-based billing built on the Billing Meters API, described as a lower-level primitive that remains fully supported for existing integrations but is not recommended for new ones.

What the documents show

Verified: the documentation states a founder should stay on the older Billing Meters approach only if already using it, or if the integration needs features Metronome does not yet fully support, including compatibility with Connect, Checkout, Adaptive Pricing or Workflows. It also states that Billing Meters only reconciles usage at invoice time, meaning a founder cannot show a customer a running usage total in real time without building that separately, whereas Metronome is described as supporting real-time usage visibility. Stripe's Billing product page, also retrieved 16 September 2026, adds that the underlying metering infrastructure handles up to 100,000 events per second and supports more than 15 built-in pricing models, including flat rate, per seat and tiered, though it does not itself state a percentage or flat fee for Stripe Billing, directing the reader to a separate pricing page instead.

The operating cost

Neither document names a specific fee for Stripe Billing on the page cited here; the product page states Billing can be purchased as an annual subscription paid monthly, or on a pay-as-you-go plan, and that Metronome usage-based billing is pay as you go, with custom pricing available for larger needs, without stating a percentage or per-event rate. Because no figure is given, a founder cannot determine the actual cost of implementing usage-based billing from these two documents alone; that requires the separate Stripe Billing pricing page or a sales quote, which is outside what this pair of documents establishes.

The stop condition

This is editorial, since the documents describe a migration path rather than a stop condition: the point to revisit a Billing Meters integration is whenever the product needs real-time usage visibility, prepaid credits, or dimensional pricing, since the documentation names those specifically as reasons to move to Metronome rather than remain on the older primitive.

• Does the product actually need real-time usage visibility, or is invoice-time reconciliation sufficient for the billing model?
• Has the separate Stripe Billing pricing page been checked for the actual percentage or subscription cost before committing to either path?
• If already on Billing Meters, does the current integration use any Connect, Checkout or Workflows feature Metronome only partially supports?

Stripe's documentation names a clear default for new integrations, but it is explicit that the default is a recommendation about which primitive to build on, not a statement of what either path costs.