Usage-Based Billing in 2026: Stripe Bought Metronome, Adyen Bought Orb

I sell compute by the second, so I think about usage-based billing more than is healthy. The pitch sounds simple: count what customers use, multiply by a price, send an invoice. The reality is a distributed system with money at the end of it, where a retried HTTP request is a double charge and a late event is revenue you quietly never collect. This post explains how usage-based billing for SaaS actually works in 2026: the metering pipeline, the pricing models (pay-as-you-go, credits, commits), what changes when you bill for AI tokens, which tools exist now that the two biggest independents were bought this year, and the failure modes I would design against from day one.

What is usage-based billing, and why is everyone doing it?

Usage-based billing (also called metered or consumption billing) charges customers for what they consume: API calls, tokens, compute seconds, gigabytes, messages, resolved tickets. It sits on top of usage-based pricing, which is the commercial decision; billing is the plumbing that turns events into invoices.

Adoption is no longer the interesting question. Metronome's 2025 State of Usage-Based Pricing survey (100 SaaS companies, run with Greyhound Capital in January 2025) found 85% had adopted some form of usage-based pricing, and 77% of the largest software companies had some level of it. Treat those as vendor numbers from a vendor whose business depends on the answer, but the direction matches what anyone selling AI features has seen: when your own cost of goods is a per-token bill from a model provider, flat seat pricing becomes a bet that your heaviest users are not too heavy.

The market moved accordingly. Stripe completed its acquisition of Metronome on 14 January 2026, saying Metronome's metering already powers OpenAI, Anthropic and NVIDIA. Adyen agreed to buy Orb for $335 million in cash in June and closed on 1 July. Kong bought OpenMeter in September 2025. Payment companies now want to own the meter, because whoever owns the meter owns the invoice. I wrote about the commercial side of this shift in the 2026 SaaS repricing; this post is about the machinery.

How does usage-based billing work? The metering pipeline

Every usage-based billing system, bought or built, has the same six stages. The vendors differ mostly in which stages they own and how much latency sits between them.

Emit is your code: the product decides that something billable happened. Ingest receives events and deduplicates them. Validate checks the customer and timestamp. Aggregate rolls events into a quantity per customer per period, with a formula (Stripe's meters support sum, count and last). Rate applies prices, tiers, discounts, credits and commitments. Invoice produces the document a finance team, and an auditor, will read.

The hard part is not any single stage. It is that every stage is asynchronous and most of them accept data they will later reject. Stripe, for example, processes meter events asynchronously and reports invalid ones through a v1.billing.meter.error_report_triggered event, not as an HTTP error on the request that sent them. If you are not subscribed to that event, a misconfigured customer mapping is invisible until someone notices a suspiciously small invoice.

Pay-as-you-go vs prepaid credits vs commits: which pricing model?

The pricing model decides how much of the pipeline you need. Pay-as-you-go needs a meter and an end-of-month invoice. Prepaid credits need a real-time balance, because the whole point is stopping usage when the balance hits zero. Enterprise commits need contract logic: minimums, ramps, true-ups.

Stripe's own comparison of basic usage-based billing and Metronome is unusually candid about where the line falls:

Pricing model	Stripe Billing Meters (basic)	Metronome (Stripe)	Source
Pay-as-you-go	Supported	Supported	Stripe docs
Flat fee plus overages	Supported	Supported	Stripe docs
Credit-based pricing	Reconciled at invoice time only; customers can exceed balance mid-cycle	Real-time	Stripe docs
Prepaid credits with drawdown	Not supported	Supported	Stripe docs
Commits, minimums, ramps	Not supported	Supported	Stripe docs
Dimensional pricing (per model, region)	Not supported	Supported	Stripe docs
Real-time usage visibility	Not supported	Supported	Stripe docs

That "customers can exceed balance mid-cycle" footnote is the whole credits debate in one line. If your product sells credits but your billing system only reconciles at invoice time, you have built a post-paid system with a prepaid label, and someone will run a batch job on the 3rd that burns through a month of credits by the 4th.

My rough rule: pay-as-you-go for developer products where customers expect a cloud-style bill; credits when buyers need a budget they can approve once (most AI features sold to businesses land here); commits when sales is involved and the contract matters more than the meter. Most companies end up with a hybrid, a platform fee plus included usage plus overage, and that is fine as long as the meter is the single source of truth for all three.

How to bill for AI tokens without losing your margin

Billing for AI usage adds three problems that classic API metering never had.

Your cost changes without you doing anything. Model providers cut prices, release new models and change cache pricing. If your price is a fixed per-request number and your cost is a moving per-token number, your margin is a random walk. Stripe's LLM token billing, now in public preview for Metronome accounts, attacks exactly this: it syncs token prices for OpenAI, Anthropic and Google models and lets you set your own margin on top, with usage segmented by model and by token type (input, output and cached).

Token types are not interchangeable. Input, output and cached tokens have different costs, so a single "tokens" meter averages away the information you need. Meter them separately, or put the model and token type on the event so you can rate them separately later. If you are on basic Billing Meters, mind the dimension cardinality limits: 10,000 unique dimension combinations per meter per hour, 100 per customer, after which new combinations are rejected.

Customers hate surprises more than they hate prices. The cautionary tale of 2025 is Cursor, which moved its Pro plan from 500 requests a month to $20 of included usage at API pricing, communicated it badly, and ended up refunding unexpected charges between 16 June and 4 July 2025. The pricing was arguably fairer. The billing experience was not, because users could not see the meter running. Usage-based billing without a usage dashboard and spend alerts is a support queue you have not staffed yet.

The pattern I like for AI features is a custom credit unit (Metronome and Stripe's token billing both support defining an "AI credit") that maps to provider costs internally. It insulates your public price from provider churn and gives finance a number they can forecast. On the cost side, pair it with the FinOps for AI discipline of attributing every token to a tenant, because you cannot bill for what you cannot attribute.

Usage-based billing tools in 2026: Stripe, Metronome, Orb, Lago, OpenMeter

The vendor map changed more in the last twelve months than in the previous five. Here is where things stood on 31 October 2026:

Tool	Status in 2026	Licence / pricing signal	Good fit	Source
Stripe Billing Meters	Stripe docs now call it "Not Recommended" for new integrations, fully supported for existing ones	Included in Billing (0.7% of billing volume), up to 100M events a month	Simple pay-as-you-go already on Stripe	Stripe guide, pricing
Metronome	Owned by Stripe since 14 January 2026; Stripe's "primary usage-based billing platform"	Proprietary, sales-led	Credits, commits, real-time balances, AI token resale	Stripe newsroom, Stripe docs
Orb	Owned by Adyen since 1 July 2026 ($335M cash)	Proprietary	Event-first billing, especially if Adyen is your processor	Payments Dive
Lago	Open source, v1.55.0 released 7 October 2026	AGPL-3.0, self-host or cloud	Teams that want to own the billing database	GitHub
OpenMeter	Acquired by Kong (September 2025), being folded into Konnect; open-source project continues	Apache-2.0, latest v1.0.0-beta.236	Metering in front of APIs and LLM gateways	Kong, GitHub

Two things stand out. First, Stripe's own Billing Meters guide now opens with a box telling new integrations to use Metronome instead, and lists what basic meters lack: real-time usage visibility, prepaid credit burndown, commits and ramps, dimensional pricing. Second, Metronome has interoperability gaps with the rest of Stripe: the same comparison page marks Connect, Adaptive Pricing, Workflows and the Stripe Dashboard as unsupported, and Checkout as limited. If you are a Connect platform, basic meters may still be the only Stripe-native option. I walk through that path in the Stripe Meters how-to guide.

The AGPL on Lago deserves a sentence: it is fine for running Lago as your internal billing service, but read it with a lawyer before you modify it and expose it over a network to customers. Self-hosting billing also means you now operate a system where downtime is measured in money. That is a very DevOps-shaped responsibility, and the usual rules (backups you have restored, alerts on the error rate, runbooks) apply with extra force.

The pitfalls: idempotency, late events and the invoice that already went out

Most billing bugs I have seen discussed publicly are not pricing mistakes. They are distributed-systems mistakes with a dollar sign attached.

Idempotency has a time limit. Stripe enforces meter event identifier uniqueness within "a rolling period of at least 24 hours". A retry inside that window is harmless. A replay from a dead-letter queue three days later is a second charge. Generate the identifier deterministically from your own source event (never a fresh UUID at send time) and keep your own record of what you have sent.

Late events have a deadline you do not control. Stripe accepts timestamps up to 35 days in the past, but acceptance is not billing. Invoices have a default finalisation grace period of 1 hour, configurable up to 72 hours; usage that arrives after finalisation shows up in meter summaries but is never added to that invoice or the next one. Threshold invoices include only usage received before creation, and a mid-cycle price change makes the grace period ignore late usage entirely.

Corrections are cheap only briefly. A meter event adjustment can cancel an event, but only within 24 hours of sending. After that, your options are negative usage in the current period or a manual credit note. Design the pipeline so that wrong events are rare, rather than easy to fix.

Rate limits are per customer, too. Live-mode meter events are limited to 1,000 calls a second per account and one concurrent call per customer per meter. The v2 meter event streams take 10,000 events a second with 15-minute session tokens. Pre-aggregating per customer per minute is usually the simplest fix and makes every downstream stage cheaper.

The pattern that addresses most of this is a transactional outbox: write the usage row in the same database transaction as the work, then ship rows to the billing provider from a separate worker that can retry safely. A minimal drainer looks like this:

# outbox_drainer.py: ship usage rows to Stripe Billing Meters, safely retryable.
# Written for stripe-python 16.1.0 (API version 2026-10-28.endive).
#   pip install "stripe==16.1.0" "psycopg[binary]==3.3.6"
import os
import psycopg
from stripe import StripeClient

client = StripeClient(os.environ["STRIPE_SECRET_KEY"], max_network_retries=3)

BATCH = """
SELECT id, tenant_stripe_customer, meter_event_name, quantity, occurred_at
FROM usage_outbox
WHERE sent_at IS NULL
ORDER BY id
LIMIT 500
FOR UPDATE SKIP LOCKED
"""

def drain(conn: psycopg.Connection) -> int:
    sent = 0
    with conn.transaction():
        for row_id, customer, event_name, qty, occurred_at in conn.execute(BATCH):
            client.v1.billing.meter_events.create({
                "event_name": event_name,
                # Deterministic: the same outbox row always maps to the same identifier,
                # so a retry inside Stripe's 24h+ window is deduplicated.
                "identifier": f"usage-{row_id}",
                "timestamp": int(occurred_at.timestamp()),
                "payload": {"stripe_customer_id": customer, "value": str(qty)},
            })
            conn.execute("UPDATE usage_outbox SET sent_at = now() WHERE id = %s", (row_id,))
            sent += 1
    return sent

if __name__ == "__main__":
    with psycopg.connect(os.environ["DATABASE_URL"]) as conn:
        print(f"sent {drain(conn)} meter events")

The sent_at column is your own idempotency record, which outlives Stripe's 24-hour window. Add an alert on the age of the oldest unsent row, and set it well inside your invoice grace period. If you run a multi-tenant architecture, the tenant-to-customer mapping in that query is the thing to test hardest.

FAQ

What is the difference between usage-based pricing and usage-based billing?

Usage-based pricing is the commercial decision to charge by consumption, such as per token or per API call. Usage-based billing is the system that records that consumption, aggregates it, applies prices and produces invoices. You can change pricing in a spreadsheet; billing needs engineering.

Should I use Stripe Billing Meters or Metronome in 2026?

Stripe's documentation now recommends Metronome for new usage-based integrations and keeps Billing Meters supported for existing ones. Billing Meters remain reasonable for simple pay-as-you-go on Stripe, and for Connect platforms, which Metronome does not support. If you need prepaid credits with real-time drawdown, commits or per-model pricing, start with Metronome or another dedicated engine.

How do you bill customers for AI tokens?

Meter tokens per customer, split by model and token type (input, output, cached), and rate them against provider cost plus a margin or through a custom credit unit. Stripe's LLM token billing, in public preview for Metronome accounts, syncs OpenAI, Anthropic and Google token prices automatically. Whatever you use, give customers a live usage view and spend alerts.

How do you prevent double billing with metered usage?

Use a deterministic identifier per usage event derived from your own data, and record what you have sent in your own database. Stripe only guarantees identifier uniqueness for at least 24 hours, so replays after that window would be counted again. A transactional outbox with a sent marker handles both retries and replays.

This quarter, if I were adding usage pricing to a SaaS product, I would do three things before choosing a vendor: write usage to an outbox in the same transaction as the work, put a deterministic identifier on every event, and subscribe to the meter error events on day one. Then I would pick the billing engine by pricing model: Billing Meters for plain pay-as-you-go, Metronome or Orb when credits and contracts appear, Lago or OpenMeter if owning the data matters more than not operating it. The vendors will keep getting acquired. The outbox will still be yours.

Related: Seats Are Dying. What the 2026 SaaS Repricing Looks Like From the Compute Layer, FinOps for AI in 2026 and Multi-Tenant SaaS Architecture Explained.