The short answer: The usage-based billing category was bought in 2026. Stripe took Metronome, Adyen took Orb, Salesforce took m3ter. What used to be a shortlist of independent metering vendors is now mostly a set of features inside larger payment and CRM platforms, and that changes the evaluation question from "which product is best" to "whose ecosystem am I joining".
If you are picking a billing stack now, the durable question is not features. It is what happens to your metering layer when your payment processor and your billing vendor are the same company.
For a few years the usage-based billing category looked like a healthy independent market. A handful of specialists competed on metering quality, and you could pick one without picking a payments provider or a CRM. That market closed.
What happened
| Vendor | Acquired by | What it means |
|---|---|---|
| Metronome | Stripe, completed January 13, 2026 | Metering becomes native to the largest payments platform |
| Orb | Adyen | Usage billing absorbed into a payments stack |
| m3ter | Salesforce | Metering pulled toward CRM and quote-to-cash |
We covered each individually as it happened: Stripe and Metronome, Adyen and Orb, and Salesforce and m3ter. Read together, the pattern is clearer than any one of them: metering turned out to be a feature that payment and CRM platforms needed to own, not a standalone business the acquirers were content to integrate with.
Why they all bought rather than built
It is worth asking why three sophisticated engineering organisations chose to buy a metering layer instead of writing one. The answer says something useful about the problem.
Metering looks like summing numbers, which is why it is routinely underestimated. What makes it hard is everything around the sum: deduplicating events from producers that retry, deciding what to do with usage that arrives after a period closed, keeping a live balance fresh enough to enforce a spend cap, and retaining raw events so an invoice line can be proven months later. Those are correctness guarantees under load, and they take years to get right. Buying three to four years of that is a rational trade even for companies that could build it.
It also tells you something about your own build-versus-buy decision. If Stripe concluded the layer was worth roughly a billion dollars rather than a team-quarter, the scope of doing it properly is probably larger than your first estimate.
What this changes for buyers
Three practical consequences, none of which show up on a feature comparison.
- Ecosystem lock is now part of the purchase. Choosing a metering vendor increasingly means choosing a payments or CRM ecosystem. If your processor is not the acquirer, ask directly and in writing what the long-term support commitment is for your configuration. Acquisition announcements are typically quiet about standalone availability for competitors' stacks, and quiet is not a commitment.
- The independent shortlist is shorter. Fewer independents means less competitive pressure on price and roadmap. It also means the remaining independents have a clearer story to tell, and are worth a look precisely because they are not attached to someone else's payment rails. We keep the case for that in independent usage-based billing after the acquisitions.
- Owning your own meter got more attractive. Not necessarily your invoicing, which is genuinely commodity work you should buy. The counting layer, though, is where your pricing model and your customer trust live, and it is now the layer most likely to be bought out from under you. Keeping the raw events under your control makes every future migration a data export rather than a re-instrumentation.
The questions to ask any vendor now
The old evaluation asked about features. The post-consolidation evaluation should ask about continuity.
- If my payment processor is not your parent company, what is the support commitment, and can that go in the contract?
- Can I export raw usage events, not just aggregates, on demand and at termination?
- If I need to leave, what exactly do I have to re-instrument in my application code?
- Are closed billing periods immutable, so a future platform change cannot restate an invoice I already sent?
The export question is the one that matters most and the one most often skipped. A vendor that hands back aggregates has kept your history. A vendor that hands back raw events with their idempotency keys has given you the ability to recompute anything, anywhere, later.
The honest take
Consolidation is not automatically bad. Metering inside a payments platform is genuinely simpler to operate if you are already on that platform, and these acquisitions will make usage billing more accessible to companies that would never have integrated a specialist.
The risk is narrower and worth naming plainly: your metering layer is now a strategic asset of someone whose main business is not metering. That is fine while incentives align. Protect yourself the cheap way, by keeping raw events exportable and keeping your instrumentation vendor-neutral, so that if the alignment ends you are facing a migration rather than a rebuild.