Stripe just acquired Metronome (PYMNTS, December 2025), a billing infrastructure company. The official reason is to “enhance usage-based pricing for AI”, but there’s a bigger story here.

I noticed this while helping a friend set up payments for their online business using Stripe. The custom pricing model had some interesting parts. Card Account Updater costs 25¢ per card update. Network Tokens cost 15¢ per token provisioned.

That seemed straightforward at first as merchants like my friend would pay for what they use, right? If her customer’s card expires, the issuer would send Stripe an update, and Stripe will update that card on file and she will see 25¢ charge for it in that month.

A quick math for her mid-sized e-commerce business revealed something interesting. For 500,000 customers, assuming 10% of the cards get updates each month (cards expire, or are reported stolen, etc), then the charge to the business would be $12,500 per month.

But the problem is that not all those updated cards get used in the next one to two months. Some might not even get used for a year if it’s for an annual subscription and the card was recently charged. Assuming 25% of all card updates are for customers who eventually churn without using their updated cards, she'll pay $37,500 annually. That’s 25% of her $150K Card Account Updater bill and for updates that create no value.

Stripe isn’t unique. I checked Adyen’s pricing page as well and they do the same. This is the norm in the entire payments industry. Adyen’s interchange++ pricing model appears to be usage based on the first look. However, when you look closely, they define interchange++ as:

This is rather a more transparent way of charging merchants, but it is still not fully usage based. Fees for products like Account Updater and Network Tokens are bundled into “scheme fees”. When Visa updates the card, Adyen passes through the cost to the merchant regardless of the card ever being used in a charge. Using numbers from the previous example, the merchant would be paying for updates of 12,500 cards monthly (25% of the 50,000 monthly updates, or $3,125/month and $37,500/year) in the scheme fee that create no value.

Merchants are paying for infrastructure execution, and not value creation. Which defeats the entire point of Usage-Based Billing.

Why do Payment Processors do this?

The gap between infrastructure executed and value created is a deliberate trade-off caused by technical constraints and business realities.

In many ways, this is similar to advertising attribution problem. When a user sees a product ad on Instagram, and buys the product a few days later directly on the merchant’s website, should the ad get credit? What if they saw an ad for the same product on X? Which ad gets credit in this case? There is no objectively clear answer.

Payment optimizations face the same challenge. If a credit card gets updated by Stripe’s Card Account Updater product, and the customer makes a successful purchase using that card six months later, how much credit should the card update deserve? The customer could have manually updated the card on the merchant’s website without Stripe needing to update it automatically.

Technical constraints

Charging for value created requires tracking outcomes over time as well as maintaining state across multiple systems. For example, hypothetically a merchant could be charged six months later in the above scenario only when the successful transaction happened and the card number used in the transaction was the expired card number. This requires the systems to do the following when the transaction happens:

On top of that, there would be a need of complex reconciliation to verify if the linking of card updates to transactions was correct, across months.

However, charging for infrastructure executed is simple. The event like card update happened, a line item is added to merchant’s invoice for that month. No state tracking and no delays.

Business incentives

From the payment processor’s point of view, execution-based billing is more predictable and revenue is recognized immediately. There is no risk involved. They know the size of the merchant and the cards they bring to the processor, which can be used to calculate current and future revenue.

The infrastructure now exists

Some companies like Metronome, for instance, provide billing infrastructure that can handle complex, multi-dimensional usage metrics and delayed billing. They ingest raw usage events in real-time and aggregate them based on arbitrary business logic. For Card Account Updater, this means they:

This is exactly why Stripe acquired Metronome in December 2025. It solves the infrastructure problem that makes true value-based billing possible. I am not sure whether Stripe will actually use it to fix their own pricing model. That remains to be seen. A hypothetical hybrid pricing model in the future could look like:

This model aligns incentives, where processors get base revenue while merchants only pay the full premium when updates actually drive transactions. Or even simpler, only charge when the updated card actually gets used.

Why this matters now?

Usage-based billing is now table stakes for SaaS providers. Customers expect (or hope) to pay for value and not bundled features they might not use. And the infrastructure to deliver on that promise exists.

Stripe’s acquisition signals true value-based billing is coming to payments. The question is when.

If you are on Stripe Custom Pricing or Adyen’s interchange++, I highly recommend auditing your costs to see what percentage of cards updated are actually used in transactions? If the waste rate (unused updates / total updates) is over a threshold you are not comfortable with, you have leverage to negotiate the price.

The execution-based billing era in payments is ending. Stripe's acquisition just accelerated the timeline.