TL;DR: The independent usage-billing market closed in 2026. Stripe bought Metronome, Adyen bought Orb, Salesforce bought m3ter. What is left splits into three groups: billing suites that own the payment rail, open-source engines you run yourself, and metering layers that deliberately stop before the invoice. The right question is no longer "which product is best" — it is "whose ecosystem am I joining, and can I get my raw events back out". The comparison table below is the short answer; the rest is how to read it.
If you are pricing an AI product in 2026, you are choosing a usage-billing stack whether you mean to or not. Tokens, GPU-seconds, agent runs and API calls all have to be counted before they can be charged for, and the counting is the part that goes wrong.
This page compares the platforms that are actually in play, with an honest note about where each one stops.
The platforms, side by side
"Metering" below means ingesting raw usage events and aggregating them defensibly. "Rating" means turning a quantity into an amount. A surprising number of tools do one and imply the other.
| Platform | Best for | Metering | Rating & invoicing | Credits | Self-host | Payment rail | Main weakness |
|---|---|---|---|---|---|---|---|
| Stripe Billing | Stripe-centric SaaS with simple metered add-ons | Meters, basic | Yes, mature | Yes | No | Stripe only | Stripe now routes sophisticated usage cases to Metronome rather than to Stripe Billing itself |
| Metronome (a Stripe product) | High-volume AI metering inside Stripe | Very strong | Yes | Yes | No | Stripe-native | Independence is gone; standalone and non-Stripe-processor commitments were conspicuously absent from the acquisition messaging |
| Orb (Adyen) | Sophisticated managed billing | Strong | Yes | Yes | No | Adyen-aligned | Same question as Metronome, one acquirer later |
| Lago | Teams that want control and a real escape hatch | Strong | Yes | Yes | Yes, open source | Stripe, Adyen, GoCardless, others | Self-hosting is real operational work; the hosted tier is where most teams end up anyway |
| Flexprice | AI-native teams wanting credits and open core | Strong | Yes | Yes, a focus | Yes, open core | Integrations | Younger; fewer public references at enterprise scale |
| OpenMeter (Kong) | Metering plus entitlements next to a gateway | Very strong | Hands off to a billing tool | Entitlements/balance | Yes, open source | Via Stripe et al. | Deliberately not a billing suite — you still choose one |
| Amberflo | Metering and cloud/AI cost governance | Very strong | Yes | Yes | No | Integrations | Positioned as much at FinOps as at monetisation; evaluate which half you are buying |
| Chargebee | Subscription-first SaaS adding some usage | Basic | Yes, mature | Limited | No | Many | Subscription DNA; heavy usage volumes are not what it was built around |
| UsageBox | An independent metering layer you can point at any biller | Yes — idempotent ingest, dedupe, late events, monthly rollups | Not yet — rollups carry quantities, not amounts | No | Storage engine is open source (usagedb) | Stripe for its own plans | Early. No rating engine, no invoicing, no credits. It is a meter, not a billing suite |
That last row is deliberately unflattering. A comparison page whose author's own product scores best on every axis is worth nothing to you, and you would find out in week two anyway.
The three groups, and what each choice actually commits you to
1. Billing suites that own the payment rail
Stripe Billing with Metronome, and Orb under Adyen. These give you the whole path from event to charged card, and they are the fastest way to bill something this quarter.
What you are committing to is the rail. Stripe's own product page now describes Metronome as "a Stripe product purpose-built for the most sophisticated usage-based billing scenarios" and points at native Stripe payment integrations. That is a good product and a clear statement about which processor the sophisticated path assumes.
Ask the vendor two questions before signing: can I run this with a processor you do not own, and can I export raw events — not invoices, events — continuously and in a documented format. The answers tell you the real cost of leaving.
2. Open-source engines
Lago, Flexprice, and OpenMeter. The pitch is control: you can read the code, you can host it, and no acquisition changes your roadmap without your consent.
Be honest with yourself about the operational half. Self-hosting a billing database means you now own its durability, its backups, and its restore drill. Most teams that adopt these run the hosted tier and treat the open source as insurance rather than as a deployment plan. That is a perfectly good reason to choose them — optionality is worth paying for — but it is a different reason than the one on the marketing page.
3. Metering layers that stop before the invoice
OpenMeter, Amberflo in its metering mode, and UsageBox. These count and aggregate; something else charges the card.
The argument for splitting the stack is that metering and invoicing fail differently. Invoicing failures are visible and fixable — a wrong invoice gets corrected. Metering failures are silent: an event that was never counted cannot be recovered, because the moment has passed and the customer's traffic is gone. Keeping the meter independent of the biller means you can change how you charge without re-instrumenting your product.
The argument against is obvious: two systems, two integrations, and a reconciliation job you now own. If your pricing is one meter and a flat overage, this is over-engineering.
How to choose, in the order the questions actually bite
- Can you get your raw events back? Not invoices — events, continuously, in a documented format. If leaving requires re-instrumenting your product, you are not a customer, you are collateral. This is the question the 2026 consolidation made urgent.
- Is ingestion idempotent, and what is the dedupe window? Every serious vendor publishes one. If they cannot tell you the window in seconds, they have not thought about retries, and retries are guaranteed.
- What happens to a late event? An event timestamped inside a period you have already invoiced either folds into it, is rejected, or is silently dropped. All three are defensible; not knowing which is not.
- Can you reconstruct a past invoice? If prices are edited in place, the answer is no, and every billing dispute becomes unwinnable. Ask whether price changes are versioned.
- Only then: does it do credits, commitments, tiers, the pricing model you want? This is the question everyone starts with, and it is the one that is easiest to change later.
Where AI pricing specifically breaks the older tools
Three things about AI workloads are harder than classic SaaS metering, and they are where subscription-first tools show their age.
- Volume. Millions of events per customer per day is normal. Aggregation that works at thousands of events falls over at millions, usually by getting slow before it gets wrong.
- Dimensionality. You rarely want to bill on one number. Input tokens, output tokens, cached reads, model, and customer are five dimensions of the same event, and prompt caching quietly adds more.
- Credits. Prepaid balances that draw down in real time, expire, and must be visible to the customer before they run out. This is a ledger, not a counter, and it is the feature most often missing.
Related reading
- Stripe bought Metronome: what it means, and the alternatives
- Adyen bought Orb: usage billing absorbed into payments
- The vendor landscape after the 2026 consolidation
- Idempotent usage metering: dedupe and late events
- What a billing API must actually do
- Build vs buy: what you actually have to build
- The usage metering hub — everything we have written on the topic