Adyen Just Bought Orb for $335M: The Metering Layer Is Being Absorbed Into Payments (2026)

For three years, "usage-based billing" was its own product category. You had a payments processor (Stripe, Adyen, Braintree) that moved money, and separately you had a metering and billing engine (Orb, Metronome, m3ter, Lago) that turned raw usage events into priced invoices. The two layers were distinct because the problems were distinct: moving a dollar is not the same as deciding how many dollars to charge for ten million API calls under a contract with tiers, commitments, and overage. June 11, 2026 is the day that separation started to close. Adyen, one of the largest payments companies in the world, is buying Orb, one of the best-known standalone metering platforms, and the reason it gave was not "we want a billing feature." It was "we want to unify billing and payments." That is a category statement, and if you are picking a metering approach for an AI product in 2026, you need to read it as one.

What actually happened

• June 11, 2026: Adyen N.V. announced a definitive agreement to acquire Orb for $335 million, structured as a reverse triangular merger, funded from Adyen's cash.
• Orb: founded in 2021, headquartered in San Francisco, it provides an infrastructure engine that tracks real-time usage data and translates complex pricing contracts into invoices for global enterprises. It raised a $25 million Series B in 2024 (about $44 million total funding). Its customer list, the part that makes this acquisition land, includes Vercel, Replit, Supabase, and Glean: the exact roster of usage-billed, AI-heavy developer platforms.
• The close: expected around July 1, 2026, subject to customary closing conditions and regulatory approval, alongside Adyen's separately announced plan to acquire Talon.One (a loyalty and incentives platform). Orb's co-founders will reinvest a meaningful portion of their proceeds into newly issued Adyen shares.
• The structure: Orb becomes an indirect, wholly owned subsidiary managed under an "incubator model," with the stated intent to eventually create one infrastructure experience for merchants across billing and payments.

Two quotes carry the strategy. Adyen Co-CEO Ingo Uytdehaage: "Combining Orb's billing product with Adyen's payments platform closes the loop between what merchants charge and how those charges perform." Orb CEO Alvaro Morales: "Billing at serious scale is only half the equation. The other half is moving money across markets, currencies and enterprise requirements." Translation: the two companies agree that metering and money-movement are halves of one problem, and the future they are betting on is the integrated version.

Why a payments giant wanted a metering company

Adyen did not pay $335 million for an invoice generator. It paid for the metering layer because that layer is where the strategically valuable data now lives. When PYMNTS covered the deal it framed it bluntly: Adyen is tackling complex AI pricing. Here is why that framing is correct.

AI products broke the old billing assumptions. A SaaS seat was a flat monthly line item; an AI feature is a stream of token counts, model-mix variance, cached-vs-uncached reads, and per-task costs that swing with every prompt. The company that can meter that stream in real time knows, before the payment ever runs, what each customer owes, which customers are unprofitable, which workloads are spiking, and where fraud or runaway usage is happening. That is not billing trivia. That is the signal Adyen wants to fuse with payment performance, fraud risk, and transaction success, so a merchant can link a pricing decision to whether the resulting charge actually clears. Metering stopped being a back-office accounting step and became the front of the revenue pipeline. Owning it is owning the data that explains the payment.

This is the same shift we have documented from the buyer side all year: as flat-rate AI pricing ends and products move to consumption pricing, the meter becomes the most important system you run. Adyen reached the same conclusion from the seller side and decided to buy the meter rather than build it.

The signal: metering is now strategic infrastructure, not a feature

For most of the usage-billing era, metering was treated as plumbing, a thing you bolted on after you had a product. The Orb acquisition is the clearest evidence yet that the market no longer sees it that way. When a payments company with a multi-billion-dollar balance sheet spends $335 million to own a metering engine, it is declaring that the metering layer is strategic infrastructure, on par with the payment rail itself.

That has a direct consequence for how you should think about your own stack. If metering is plumbing, you wire in whatever is cheapest and forget it. If metering is strategic infrastructure, the choice of where it lives, who controls it, and whether you can move it becomes a first-order decision, the same way you would think hard about your database or your auth provider rather than your logging library. The Adyen-Orb deal is the market repricing that decision upward. The teams that internalized this early, the ones who already treated the meter as a layer that complements payments rather than a payment-provider afterthought, were ahead of the curve this deal just confirmed.

The consolidation is the pattern, not the exception

One acquisition is an event. Two is a trend, and this is at least the second time the standalone metering category has been pulled into a larger payments or platform stack. The independent metering vendors raised on the premise that a neutral, best-of-breed billing layer would sit happily between your product and any payment processor. That premise is now under pressure from both ends: payments companies are acquiring upward into metering (Adyen and Orb), and payment processors that already had billing products are deepening them to keep usage-based customers from leaving for a specialist. The middle, the pure-play independent metering vendor, is the squeezed position.

If you are a buyer, the implication is not "metering is dying." It is the opposite: metering won so decisively that everyone wants to own it. The implication is about concentration. The neutral middle layer you might have picked in 2024 for its independence may, by 2027, be a feature inside a payments suite whose roadmap is set by what is good for the parent's payment volume, not by what is good for your pricing flexibility. That is not necessarily bad, integration can be genuinely useful, but it is a different bet than the one you signed up for, and you did not get to vote on the change.

What this means for build-vs-buy, right now

This deal sharpens, rather than settles, the build-vs-buy question we walk through in detail in our build-vs-buy breakdown. Three things changed on June 11.

1. "Buy" now carries acquisition risk, not just vendor risk. The classic argument against building your own metering was that a specialist does it better and you should not reinvent it. Still mostly true. But the new wrinkle is that the specialist you buy may be acquired, repriced, repositioned, or absorbed into a stack you did not choose. The risk is no longer just "will this vendor survive" but "will this vendor still be the same product, with the same neutrality and the same roadmap, in eighteen months." That is a real cost to weigh against building.
2. "Build" got more defensible for the metering core specifically. Not the whole billing stack, payments, tax, and dunning are still buy-it problems. But the metering core, the part that ingests usage events and aggregates them into priced quantities, is increasingly the part teams want to own, because it holds the data that explains their economics and because owning it removes the dependency that just got acquired. The pattern we describe in building billing without handing the core to a single vendor looks more prudent after a deal like this, not less.
3. Portability is now the load-bearing requirement. Whether you build or buy, the durable defense against consolidation is the same defense against any vendor event: keep your usage data and your pricing logic in a form you can move. If your meter is a layer you own or can export cleanly, an acquisition of your billing vendor is an inconvenience. If your meter is inseparable from a vendor that just became a feature of a payments giant, it is a migration project on someone else's timeline.

Vendor concentration: the question to ask before July 1

The practical move is not to panic-switch off any particular vendor. It is to map your concentration honestly. Ask three questions of your current setup:

• How many layers does one vendor control? If a single provider owns your payment rail, your metering, your pricing logic, and your invoicing, an acquisition or a strategy change at that vendor moves all four at once. The whole appeal of the unified Adyen-plus-Orb pitch, one experience across billing and payments, is also its concentration risk: convenience and single-point-of-failure are the same architecture viewed from two angles.
• Can you reconstruct an invoice without the vendor? If your vendor vanished tomorrow, do you still hold the raw usage events and the pricing rules to re-derive what every customer owes? If the answer lives only inside the vendor's system, you do not own your billing, you rent it. This is the same lesson the Fable 5 takedown taught on the model side: a dependency you cannot reconstruct or route around is a single point of failure, whether it disappears by export-control order or gets quietly re-prioritized after an acquisition.
• Is your metering decoupled from your money-movement? The strategic value Adyen is buying is the fusion of the two. For a buyer, the strategic protection is often the opposite: keeping the meter (what you charge) loosely coupled to the processor (how you collect), so you can change either one without rebuilding the other. Unification is great until the unified vendor's interests diverge from yours.

The honest take

Adyen buying Orb is good news disguised as a warning. It is good news because it confirms what usagebox has argued for two years: metering is not a feature you tack on, it is strategic infrastructure worth a nine-figure check, and usage-based billing is the durable shape of software pricing, not a phase. The warning is in the structure. The standalone metering layer is consolidating into payments giants, which means the neutral, independent, best-of-breed meter you might pick today could be a line item in someone else's payments roadmap by the time your contract renews. That does not make buying wrong, integrated billing-plus-payments will be genuinely better for many teams, but it raises the price of not thinking about portability. The teams who come out ahead are the ones who treat their usage data and pricing logic as assets they own and can move, whether they build the meter or buy it. Own the meter, or at least own the exit from it. The deal that just closed the loop between charging and collecting also closed the window on treating metering as an afterthought. If you are choosing how to bill AI usage this quarter, choose like the layer matters, because a payments giant just paid $335 million to prove it does.