TL;DR: Metronome is a Stripe product as of January 2026. Nothing broke for existing customers, but the reason many teams chose it — a metering engine independent of any payment processor — is no longer true. If that independence was the point, the credible alternatives are Orb (now Adyen's, so read the same caveat twice), Lago, Flexprice, OpenMeter, Amberflo, Chargebee, or splitting the meter from the biller. Here is what each one is actually good at, and the two questions that decide it.
Stripe completed its acquisition of Metronome on 13 January 2026, in a deal reported at around $1 billion. Stripe's own billing page now describes Metronome as "a Stripe product purpose-built for the most sophisticated usage-based billing scenarios".
That sentence is why you are reading this page. Metronome won the AI segment by being the metering engine that did not care whose card you charged. It is now the sophisticated tier of one payment company's billing product. If you picked it for the engine, you still have the engine. If you picked it for the neutrality, that is the part that changed.
First: do you actually need to move?
Probably not urgently, and anyone telling you otherwise is selling something. Be concrete about the trigger instead:
- You process payments somewhere other than Stripe, or plan to. This is the real one. Ask your account team directly what the roadmap commitment is for non-Stripe processors and get the answer in writing.
- You are a Stripe competitor, or sell into one. Vendor-risk reviews at your customers will start asking.
- Your procurement requires an exit plan and cannot get a raw-event export commitment.
If none of those apply, the correct action is to write down your exit path and carry on. Migrating billing infrastructure to pre-empt a hypothetical is how teams spend a quarter to end up in the same place.
The alternatives
Orb — the closest like-for-like, with the same asterisk
Orb is the product most similar in shape: managed, developer-first, strong on sophisticated pricing models. It is also owned by Adyen now. Moving from Metronome to Orb to escape acquisition risk swaps Stripe's gravity for Adyen's. That may still be right — if you already process on Adyen it is arguably better — but do it with open eyes.
Lago — the open-source escape hatch
Open source, self-hostable, and notably processor-agnostic: Stripe, Adyen, GoCardless and others. If your objection to the Metronome deal is structural rather than technical, Lago is the most direct answer, because the licence means no future acquisition can take the code away from you.
The honest caveat: most teams who adopt Lago run the hosted tier. Self-hosting a billing database means owning its durability, its backups, and a restore drill you have actually performed. Choose it for the optionality, not because you are definitely going to operate it.
Flexprice — open core, credits-first
Aimed squarely at AI-native teams, with credit grants, prepaid balances and top-ups as first-class features rather than bolt-ons. If your pricing is credits-based — and increasingly AI pricing is — this is the one whose data model already matches your product. Younger than the others, with fewer public references at enterprise scale.
OpenMeter — metering and entitlements, deliberately not billing
Now part of Kong. OpenMeter meters and does entitlements/balances, then hands off to a billing tool for the invoice. That is not a gap in the product, it is the design: it is the metering half of the stack, and it expects you to pair it with something else.
Worth serious consideration if you already run a gateway, because metering at the gateway is where the events already are.
Amberflo — metering with a FinOps accent
Strong metering, aimed at cloud and AI cost governance as much as at monetisation. Work out which half you are buying: teams that want "what is this costing us" and teams that want "what do we charge for this" are buying different products from the same page.
Chargebee — only if usage is the minority of your bill
Mature subscription billing with metered add-ons. If you are a SaaS company with seats plus some usage, this is fine and the invoicing is better than most. If usage is the product and volumes are AI-shaped, its subscription DNA will show.
Split the stack — keep the meter independent
The structural answer to a consolidation wave is not to pick a different acquirer. It is to stop coupling the thing that counts to the thing that charges.
Metering and invoicing fail differently. A wrong invoice is visible and correctable. A usage event that was never counted is gone — the traffic has passed and cannot be replayed. Keeping the meter as its own layer means the next acquisition is a procurement problem rather than a re-instrumentation project.
This is what UsageBox is: an independent metering layer with idempotent ingest, a documented dedupe window, late-event handling and monthly rollups, on top of an open-source storage engine. Being straight about the limits, because this page is useless otherwise: it has no rating engine, no invoicing and no credits today. It is a meter you point at a biller, not a replacement for one.
The two questions that actually decide it
1. Can you get your raw events out, continuously, in a documented format? Not invoices — events. Invoices are a summary of a decision someone else made. Events are the evidence. If leaving a vendor requires re-instrumenting your product, the switching cost is your entire engineering roadmap for a quarter, and every vendor knows it.
2. Whose ecosystem are you joining? In 2026 this is the buying question. Metronome means Stripe. Orb means Adyen. m3ter means Salesforce. Lago, Flexprice and OpenMeter mean a licence instead of an owner. None of those is wrong; picking one without noticing is.
A migration checklist, if you do move
- Export the full raw event history first, before you give notice. Not aggregates — events, with their original timestamps and idempotency keys.
- Run both systems in parallel and reconcile per meter per period. Agreement on the total is not agreement; check each key.
- Do not cut over inside a billing period.
- Keep the old system readable for at least one full dispute cycle. The first argument about a number will happen after you have switched.
- Write down the dedupe window and late-event policy of the new system, because they will differ from the old one, and that difference is where the discrepancies come from.