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. PYMNTS, December 2025 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. per card update per card update per token provisioned 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: the interchange fee that goes to the bank that issued the card,
the scheme fee that goes to Visa or Mastercard (this is where they hide it), and
the acquirer fee the interchange fee that goes to the bank that issued the card, the scheme fee that goes to Visa or Mastercard (this is where they hide it), and this is where they hide it this is where they hide it the acquirer fee 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. infrastructure execution infrastructure execution value creation value creation Usage-Based Billing 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. infrastructure executed value created 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: value created and and scan the database for card updates in the last N months,
find out through other systems if the card update was already charged for in a different transaction, and
link the card update to the transaction and actually charge the merchant scan the database for card updates in the last N months, find out through other systems if the card update was already charged for in a different transaction, and link the card update to the transaction and actually charge the merchant 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. infrastructure executed 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: Ingest a card updated event,
Ingest a successful transaction event,
Define billing rules that charges the first card update only when the successful transaction happens later,
Automatically reconcile these events over months Ingest a card updated event, Ingest a successful transaction event, Define billing rules that charges the first card update only when the successful transaction happens later, Automatically reconcile these events over months 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: Base fee: 10¢ per card update (to cover compute cost)
Value creation fee: 15¢ when that card is used within next 90 days Base fee: 10¢ per card update (to cover compute cost) Value creation fee: 15¢ when that card is used within next 90 days 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.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Stripe

From Buttons to Conversations: How Agentic AI Is Redefining System Design

Why 'Usage-Based' Billing in Payments Is Fake

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Year of AI in My Life as an Engineer

What I Learned Building a Food Delivery Analytics Tool with AI

A Year of AI in My Life as an Engineer

Meta-Prompting: From “Using Prompts” to “Generating Prompts”

3 Ways to Avoid that Huge Cloudwatch Bill

Accelerating Accounts Receivable with Automated Technologies

A Year of AI in My Life as an Engineer

What I Learned Building a Food Delivery Analytics Tool with AI

A Year of AI in My Life as an Engineer

Meta-Prompting: From “Using Prompts” to “Generating Prompts”

3 Ways to Avoid that Huge Cloudwatch Bill

Accelerating Accounts Receivable with Automated Technologies

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps