TL;DR: Adyen closed its $335 million acquisition of Orb on 1 July 2026 and is running it under an incubator model, so nothing breaks today. The sentence to read carefully is that multi-PSP support "continues initially". If you chose Orb because it was processor-neutral, that is the word that should decide whether you act. The alternatives are Metronome (Stripe, so the same trade one acquirer along), Lago, Flexprice, OpenMeter, Amberflo, Chargebee, or splitting the meter from the biller.
Orb is a strong product. This page is not an argument that it stopped being one on 1 July — it is an argument that the reason many teams picked it has changed, and that the reason matters more than the feature list.
What actually happened
Adyen agreed to acquire Orb in June 2026 for $335 million in cash, alongside Talon.One, and completed on 1 July. Orb became an indirect wholly-owned subsidiary, operated under an incubator model that Adyen says is intended to preserve product momentum and operational continuity during the initial phase.
The strategic logic is straightforward and stated openly: link billing signals to Adyen's identification layer, use real-time payment data and risk scores to improve billing execution and transaction success. That is a genuinely good idea for merchants already on Adyen. It is also, unavoidably, an integration that gets deeper over time.
The word that matters
Adyen's messaging says multi-PSP support continues initially.
Nobody writes "initially" by accident in an acquisition announcement. It is not a commitment to remove anything, and it is not a commitment to keep it either. It is precisely the amount of ambiguity a company puts in writing when the honest answer is "we have not decided".
Six months earlier, Stripe bought Metronome and now describes it as "a Stripe product purpose-built for the most sophisticated usage-based billing scenarios", pointing at native Stripe payment integrations. That is where this pattern goes: not a removal, a gradual convergence in which the well-supported path is the acquirer's rail and everything else becomes the path that gets less attention each release.
Do you actually need to move?
Probably not this quarter. Be specific about the trigger instead of migrating on a feeling:
- You process on something other than Adyen and intend to keep doing so. This is the real one. Ask your account team, in writing, what the roadmap commitment is for non-Adyen processors and what notice you would get. The quality of the answer is the answer.
- You compete with Adyen, or sell into companies that do. Vendor-risk reviews will start raising it whether or not you do.
- Your procurement needs a documented exit and you cannot get a continuous raw-event export commitment.
- You are mid-evaluation and have not signed. The cheapest moment to weigh this is before the integration, not after.
If none apply: write down your exit path, confirm you can export raw events, and carry on. Migrating billing infrastructure to pre-empt a hypothetical costs a quarter and usually lands you somewhere with the same structural question.
The alternatives
Metronome — the closest match, with the identical asterisk
The most similar product in shape and sophistication, and the obvious swap. It is also Stripe's now. Moving from Orb to Metronome to escape acquisition risk trades Adyen's gravity for Stripe's — which is a fine trade if you process on Stripe, and no trade at all if the objection was structural.
Lago — the structural answer
Open source under AGPLv3, self-hostable, processor-agnostic across Stripe, Adyen, GoCardless and others. If your objection to the acquisition is that you do not want billing infrastructure owned by a processor, Lago is the direct answer, because a licence cannot be acquired away from you.
The honest caveat, since Lago's own marketing will not lead with it: the free self-hosted stack is Docker, Postgres and Redis, while the configuration behind its throughput figures is ClickHouse and Kafka — Lago migrated its own events engine for exactly that reason. At AI volumes, self-hosting means operating that. Most teams run the hosted tier and treat the licence as insurance, which is a perfectly good reason to choose it and a different one from the marketing page.
Flexprice — if the pricing is credits
Open source under AGPL-3.0, built around credits: recurring grants on renewal, one-time promotional grants, prepaid top-ups, per-grant expiry and rollover caps. Publicly priced at $500/month Starter and $1,000/month Premium, which is more transparency than most of this market offers. Younger, with fewer enterprise references.
OpenMeter — metering only, permissively licensed
Part of Kong since September 2025, Apache 2.0. It meters and does entitlements, then hands off to a biller — narrower than Orb by design. Note that it has also been acquired; the difference is that a permissive licence means the acquisition cannot reach the code you already have.
Amberflo and Chargebee
Amberflo for strong metering with a cost-governance slant — work out whether you are buying "what does this cost us" or "what do we charge". Chargebee when usage is the minority of the bill and mature invoicing matters more than metering sophistication.
Split the stack
The pattern that makes the next acquisition a procurement question rather than a project: keep the thing that counts separate from the thing that charges. Metering and invoicing fail differently — a wrong invoice is visible and correctable, an uncounted event is gone, because the traffic has passed and cannot be replayed. If your meter is independent, changing biller does not mean re-instrumenting your product.
The three questions, in order
- Can you export raw events, continuously, in a documented format? Events, not invoices. Invoices are a summary of someone else's decision; events are the evidence. If leaving requires re-instrumenting your product, your switching cost is a quarter of engineering and every vendor knows it.
- Whose ecosystem are you joining? Orb means Adyen. Metronome means Stripe. m3ter means Salesforce. Lago, Flexprice and OpenMeter mean a licence instead of an owner. In 2026 this belongs on the evaluation matrix, not in the footnotes.
- Are prices versioned? If a price edit overwrites history, no past invoice can be reconstructed and every dispute becomes unwinnable. Ask before you sign; it is not something you can add afterwards.
If you migrate
- Export the full raw event history before giving notice — with original timestamps and idempotency keys.
- Run both systems in parallel and reconcile per meter, per period. Matching totals is not agreement.
- Record both systems' dedupe windows and late-event policies. They will differ, and that difference produces every discrepancy you will see.
- Do not cut over inside a billing period, and keep the old system readable for one full dispute cycle.