Abhilash John

Apr 11, 2026

When Your Customer Is a Machine: What Agentic Commerce Means for Pricing and Billing Infrastructure

A deep dive into how AI agents handling automated payments and commerce are changing the architecture of billing systems, moving from human-initiated checkouts to machine-level authority and outcome-based pricing.

Something fundamental is shifting in how software gets bought and paid for. Not in the pricing model itself we’ve been talking about usage-based pricing for years but in who is doing the buying.

In March 2026, Stripe and Tempo launched the Machine Payments Protocol (MPP). A month earlier, Visa introduced card specifications and an SDK purpose-built for the same protocol. Coinbase’s x402 standard has now processed over 119 million transactions on Base alone, handling roughly $600 million in annualized volume. And at NRF 2026, 75% of retailer attendees said they were implementing or planning for agentic commerce.

The customer of the near future isn’t a person clicking “Buy Now.” It’s a piece of software acting on a person’s behalf browsing, evaluating, negotiating, and purchasing autonomously. McKinsey projects this could become a $3–5 trillion global market by 2030.

If you’re building or operating billing infrastructure, this isn’t a trend to monitor. It’s an architectural reckoning.

First, A Necessary Distinction: Two Very Different Sides of the Table

Before going further, it’s worth drawing a line that gets blurred in almost every conversation about agentic commerce: whose billing system are we actually talking about?

There are two distinct worlds, and they have very different requirements:

Side A The merchant receiving payment from a buyer-agent. Here, an AI agent owned by someone else (a consumer, a procurement team, another company) shows up at your checkout and wants to buy something. Your billing system sits on the receiving end of the transaction. Crucially, you don’t own the agent, you can’t see its reasoning, and you don’t need to. What you do need is to verify that the agent has the authority to spend, process the payment, and settle cleanly. This is the world MPP, x402, and Visa’s Trusted Agent Protocol were built for.

Side B The vendor selling AI work itself. Here, the AI agent is the product. You’re a SaaS company whose support bot resolves tickets, or whose AI drafts legal contracts. The agent is yours you own it, operate it, and log its behavior. Your billing problem is how to price and meter the value it produces for customers. This is the world Metronome, Orb, Lago, and Chargebee are currently evolving into, and it’s where outcome-based pricing lives.

The two worlds overlap at the edges (a buyer-agent might be purchasing from a vendor-agent, generating a machine-to-machine transaction between them), but the billing requirements are not the same. Getting them confused and I did earlier drafts of this article leads to building the wrong things.

With that distinction in mind:

The Five Levels and Where We Actually Are

The industry has converged on a useful framework for thinking about agentic commerce as a progression through five levels of autonomy:

1. Form-filling: The agent automates checkout. You pick the product; it handles the tedious shipping-and-payment dance.
2. Descriptive search: You describe a need in natural language (“waterproof hiking boots for a trip to Iceland in November”), and the agent reasons across reviews, weather data, and delivery times to surface options.
3. Persistent preferences: The agent remembers your taste, budget, and past behavior. You still decide, but from a curated shortlist.
4. Full delegation: You hand over a directive and a budget (“Handle back-to-school shopping, keep it under $400”). The agent searches, evaluates, and purchases without further input.
5. Anticipation: The agent acts without a prompt ordering groceries before you run out, rebooking a flight when it detects a schedule conflict.

Today, we’re hovering around Levels 1 and 2. Browserbase lets agents spin up headless browsers and pay per session via MPP. PostalForm lets agents pay to print and send physical mail. These are real, production use cases but they still involve a human defining the intent. Levels 4 and 5, where agents spend money without asking and eventually buy things before you know you need them, remain largely theoretical.

But here’s the thing about billing infrastructure: you can’t build it reactively. Payment systems and billing platforms take years to redesign. The protocols being laid down right now MPP, x402, Visa’s Trusted Agent Protocol, Mastercard’s Agent Pay are the foundation that everything from Level 3 onward will run on. If your billing system can’t speak these protocols by the time delegation-level commerce arrives, you won’t be scrambling to catch up. You’ll be irrelevant.

The Merchant Side: It’s Not About Volume. It’s About Verifying Authority.

The most common framing of this shift focuses on transaction volume: “AI agents will generate millions of micro-transactions!” That’s true, but for merchants it’s the least interesting challenge. Sub-ledger aggregation and event streaming are well-understood engineering problems. We’ve been scaling event ingestion pipelines for a decade.

The harder problem for the merchant side is authority. Traditional billing systems assume a clean mapping: one account, one human, one payment method. Agentic commerce blows this up in at least three ways.

First, the buyer is now a principal-agent pair. When an AI agent shows up to buy something, the merchant needs to record two identities: the principal (the person or organization who actually owes the money) and the agent (the software presenting the payment credential). The principal matters for tax nexus, dispute handling, and compliance. The agent matters for fraud detection, rate limiting, and reputation. Visa’s Trusted Agent Protocol and Mastercard’s Agent Pay are both built around this two-identity model they let merchants distinguish a legitimate, delegated AI agent from a malicious bot.

Second, the authentication model is fundamentally different. Credit cards were designed to be presented by humans. CVVs, 3D Secure, biometric verification none of these work when the buyer is software. The industry is converging on cryptographic delegation: agents carry signed mandates (via protocols like MPP’s Shared Payment Tokens or x402’s EIP-3009 authorizations) that prove the principal has authorized this specific agent to spend up to a specific amount at this specific merchant. The merchant’s billing system needs to validate these mandates at checkout not store the policies that generated them. The policy lives on the buyer’s side. The merchant just needs to trust the signature.

Third, the meaning of “customer” gets fuzzy. Is the customer the human principal, or the agent platform (OpenAI, Anthropic, a corporate agent orchestrator)? For loyalty programs, CRM, and marketing, it’s the principal. For fraud scoring and rate limiting, it’s the agent. Merchant billing and CRM systems will need to carry both identifiers and know which one to use in which context.

Note what’s not on this list: the agent’s reasoning. The merchant doesn’t need to know why the agent chose their product. That’s the buyer’s private business. All the merchant needs is a cryptographically valid mandate and a record of what was bought.

The Buyer Side: Where Governance and Reasoning Actually Live

If the merchant’s job is to verify authority, the buyer’s job is to define and enforce it. This is a completely different class of system and in my view, it’s where the most interesting infrastructure is going to get built over the next few years.

When a consumer or enterprise deploys AI agents to spend money, someone has to answer questions like: How much can this agent spend? At which merchants? Under what conditions does a human need to approve? What happens if the agent buys something we didn’t want? These aren’t billing questions in the traditional sense they’re closer to expense management, procurement policy, and AP workflow.

Call this the agent spend management layer. It doesn’t exist as a mature product category yet, but the pieces are emerging. At Level 4 (delegation), you need programmatic constructs like: “This agent can spend up to $400 on back-to-school items, but flag any single item over $50 for human approval.” “This agent can auto-renew SaaS subscriptions within 5% of last year’s price, but escalate if the vendor raises prices beyond that.” These are policy primitives, enforced before the agent presents a mandate to a merchant.

At Level 5 (anticipation), the reasoning trace finally earns its keep but on the buyer’s side, not the merchant’s. When your agent buys groceries before you’ve asked, you want to know why. Which calendar entry triggered it? Which past purchase pattern did it infer from? What alternatives did it consider? That audit log lives inside the agent’s own runtime and gets stored in the buyer’s spend management system alongside the transaction. The merchant who took the payment has no visibility into any of this, and shouldn’t.

This is an important correction to how agentic commerce often gets discussed. The “reasoning trace as the new invoice” idea is real but it’s a buyer-side artifact, not a merchant-side one. It’s the thing your CFO’s team will want when they audit the agent’s behavior at quarter-end. It’s the thing an enterprise procurement team will want when they dispute an agent’s purchase. It never needs to reach the merchant’s billing system.

The Payment Rails War: Fiat, Stablecoins, or Both?

There’s a popular narrative especially in crypto circles that stablecoins are the inevitable payment rail for agentic commerce. The argument is compelling on paper: 24/7 availability, sub-cent transaction fees on Layer 2 networks, programmable escrow via smart contracts, and no need for human authentication. The x402 protocol, built on USDC, has real traction. The GENIUS Act, signed into law in July 2025, gave stablecoins regulatory legitimacy by classifying them as payment instruments (not securities) and allowing banks to hold stablecoin reserves.

But I think the “stablecoins win everything” narrative overstates the case at least for the next 3–5 years. Here’s why.

Stripe’s MPP deliberately supports both fiat and crypto. Businesses can accept agent payments via stablecoins or via cards and buy-now-pay-later methods through Shared Payment Tokens. Visa has published card specifications for MPP. This isn’t hedging it’s recognition that the installed base of fiat payment infrastructure is enormous, and merchants aren’t going to rip it out overnight. The winning billing platforms will be the ones that abstract over payment rails, letting merchants accept whichever method the agent presents.

The micropayment problem is mostly already solved by credit ledgers, not by stablecoins. This is worth dwelling on because it’s widely misunderstood. The argument that “card fees of $0.30 make sub-cent transactions impossible” is true at the per-transaction level and entirely beside the point at the system level. OpenAI, AWS, Twilio, Stripe itself every high-volume micro-event vendor already handles this by aggregating millions of sub-cent events into a single settlement against a real payment rail. Prepaid credit balances decrement as the agent consumes services; postpaid ledgers accumulate usage and settle periodically. Either way, the card rail only gets invoked once per billing cycle, over a large bucket. The per-transaction cost is amortized away. This is how usage-based billing already works, and it scales to agent-driven volumes just fine.

Stablecoins have a real edge in a narrower case than the hype implies: stateless, novel, one-off counterparties. Consider an agent that discovers a new API it’s never used, needs to pay $0.02 to access it exactly once, and doesn’t want to create an account, complete KYC, and fund a prepaid balance for a single call. For that interaction, x402-style instant on-chain settlement genuinely beats the alternatives it’s stateless, no signup required, settles in seconds. This is a real use case, and it’s why x402 has traction. But it’s not most of commerce. Most agent commerce will involve vendors the principal already has a relationship with (cloud providers, SaaS platforms, marketplaces), and for those, a credit ledger is not just sufficient it’s better, because it integrates cleanly with accounting systems, supports credit terms, and avoids the regulatory and FX complexity of holding stablecoins.

Stablecoins also win for cross-border settlement and programmable escrow. If an agent is buying from a vendor in Singapore while the principal is in London, instant on-chain settlement avoids FX fees and T+2 delays. And if a transaction requires conditional logic (“release payment only if the deliverable passes a quality check”), smart contracts are purpose-built for it. These are genuine strengths, not hype.

For everyday commerce buying groceries, booking flights, purchasing SaaS subscriptions card rails aren’t going anywhere. The consumer protections, chargeback mechanisms, rewards programs, and regulatory frameworks around card payments took decades to build and have no crypto-native equivalent.

The practical takeaway for billing infrastructure builders: the right mental model is three rails, not two. Credit ledgers for known counterparties with ongoing relationships (this is the default, and it handles most of the volume). Stablecoin rails for stateless one-off transactions and cross-border M2M. Card rails for consumer checkout and regulated contexts. Don’t build around a single assumption. And in particular, don’t fall for the “we need stablecoins because of micropayments” pitch that problem was solved before stablecoins existed.

From Metering Usage to Metering Outcomes

Here’s where things get genuinely interesting for the usage-based billing world.

Traditional usage-based billing meters discrete, predictable units: API calls, compute hours, storage gigabytes, seats. The pricing model is straightforward because the unit of consumption is clear.

Agentic workloads break this. A single agent “action” say, resolving a customer support ticket might fan out into multiple LLM calls, tool invocations, database lookups, and external API requests. The underlying resource consumption is wildly variable, but the value to the customer is the resolved ticket.

This is pushing the industry toward outcome-based pricing: charge for the ticket resolved, the contract drafted, the meeting booked not the tokens consumed or the compute burned. According to Metronome’s 2026 data, 77% of the largest software companies now incorporate some form of consumption-based pricing, and the frontier is rapidly moving from “consumption of resources” to “consumption of outcomes.”

For billing infrastructure, this creates a new metering challenge. You’re no longer just counting events. You need to:

• Define and detect “outcomes” which requires integration with business logic, not just infrastructure telemetry. A billing system needs to know that a support ticket was resolved, not just that 47 API calls were made.

• Handle variable cost-of-goods-sold (COGS) per outcome two “resolved tickets” might cost vastly different amounts in underlying compute. The billing system needs to track both the price charged and the cost incurred, in real time, to protect margins.

• Support hybrid models most companies will blend outcome-based pricing (for high-value actions) with usage-based pricing (for commodity resources). The billing system needs to compose these cleanly.

This is where today’s billing platforms Orb, Metronome, Lago, Chargebee face their biggest evolution challenge. They’ve gotten very good at metering and rating high-volume events. The next frontier is metering outcomes and letting pricing logic reference business context, not just raw event counts.

A Note on Tax Because It Cuts Across Both Sides

Tax is where the two sides collide in messy ways. If an agent operating on behalf of a London-based user purchases a digital service from a vendor in Singapore, who handles VAT? At what moment is nexus established? Traditional billing systems calculate tax at checkout based on a single buyer jurisdiction. In agentic commerce, the agent may be hosted in one jurisdiction, the principal in another, and the vendor in a third.

The merchant’s billing system needs to receive a trustworthy signal about the principal’s jurisdiction at checkout which likely means agent mandates will need to carry verified tax metadata alongside the spending authorization. On the buyer side, spend management systems will need to track cumulative spending by jurisdiction to flag when their agent is about to cross a registration threshold. Neither problem is solved today.

What Each Side Needs to Build Now

If I were running product at a billing infrastructure company, here’s how I’d split the roadmap by which side of the table I serve.

For merchant billing systems (Side A)

Multi-rail settlement abstraction. Accept payments via MPP (fiat and stablecoin), x402 (stablecoin-native), and traditional card/ACH rails through a single integration. The winning platform treats payment method as a runtime parameter.

Mandate verification, not policy storage. Validate cryptographic mandates at checkout signature, expiry, amount cap, merchant scope. You don’t store the principal’s spending policy; you just confirm that this specific transaction falls within a signed authorization. Think of it like OAuth scopes, not like a permissions database.

Two-identity transaction records. Every transaction should carry both the principal identity (for tax, compliance, CRM) and the agent identity (for fraud, rate limiting, reputation). Downstream analytics need to know which one to use for which question.

Credit ledger as the default settlement pattern. When an agent executes 2,000 transactions in an afternoon, you don’t want to run 2,000 card authorizations. You want a credit ledger prepaid or postpaid that decrements (or accumulates) in real time and settles against a real payment rail on a periodic cadence. This is how mature usage-based billing already works, and it’s the right answer for agent-driven volume too. Card or stablecoin rails are used only for the periodic settlement, not the per-event transaction. Treat the ledger as the primary unit of billing infrastructure; treat the payment rails as plumbing underneath it.

Machine-speed dispute APIs. When a human buyer gets the wrong item, they email support. When an agent buys something that doesn’t meet spec, you need programmatic recourse an API the buyer’s agent (or spend management system) can invoke directly, without a human clicking “dispute” in a dashboard.

For the emerging agent spend management layer (Side B, buyer-owned)

Programmable policy engines. Budget caps, per-transaction limits, merchant allowlists, category restrictions, conditional approvals, automatic escalation. These are the rules the buyer writes before an agent is allowed to spend. They generate the mandates that merchants then verify.

Reasoning trace capture and indexing. Store the agent’s decision log what it considered, what it evaluated, why it chose alongside every transaction. This is the artifact your finance team audits, your procurement team disputes, and your compliance team reviews. It lives on your side, not the merchant’s.

Multi-agent orchestration. A single buyer might deploy several agents with different mandates (office supplies vs. SaaS subscriptions vs. travel). The spend management layer needs to manage them as a fleet: shared budgets, category isolation, cross-agent reporting.

Reconciliation with corporate finance systems. Every agent purchase eventually has to land in an ERP, a GL, and an expense report. The spend management layer has to speak fluent NetSuite, SAP, and whatever the CFO’s team runs.

For AI vendors selling agent work (the other Side B)

This is the world today’s usage-based billing platforms Orb, Metronome, Lago, Chargebee are actively evolving toward. The key shift here is from event metering to outcome metering.

Outcome-aware metering. Move beyond counting API calls and tokens to detecting and pricing business outcomes tickets resolved, contracts drafted, meetings booked. This requires deep integration with the vendor’s own orchestration stack (LangChain, CrewAI, internal agent runtimes), because the business system is where “outcome” is defined.

Real-time COGS tracking. Two “resolved tickets” can cost radically different amounts in underlying compute. The billing system has to track both the price charged and the cost incurred, in real time, so the vendor can protect margin and detect runaway jobs before they eat the quarter.

Hybrid pricing composition. Most AI vendors will blend outcome pricing (for high-value actions) with usage pricing (for commodity resources) and seat pricing (for access). The billing engine has to compose these cleanly, not force customers to pick one.

The Uncomfortable Truth

Here’s the part that the agentic commerce hype cycle glosses over: most billing systems in production today including many that bill themselves as “usage-based” are fundamentally designed around a human-initiated purchase loop. Monthly invoice cycles, manual dispute resolution, PDF receipts, dashboard-driven analytics. None of this works when your customer is a machine making 500 purchases before lunch.

The transition won’t be graceful. It’ll look like what’s happening right now: a proliferation of new protocols (MPP, x402, Agent Pay, Trusted Agent Protocol), a scramble by incumbent billing platforms to add “agentic” features, and a new generation of startups building agent-native billing from scratch.

The companies that win won’t be the ones with the best metering pipeline. They’ll be the ones that understood, early enough, which side of the table they serve and built for it without conflating the two. Merchants need mandate verification, two-identity records, and multi-rail settlement. Buyers need policy engines, reasoning traces, and fleet-level governance over their agents. AI vendors need outcome metering and real-time COGS. These are three different products, and the platforms that try to be all of them at once will end up being none of them well.

The clock is ticking. Level 4 isn’t five years away. It’s two.

And if there’s one thing I’d want billing infrastructure teams to internalize, it’s this: the shift from human-to-machine commerce isn’t primarily a payments problem. It’s a trust architecture problem. Trust has to get operationalized somewhere in how agents prove authority to merchants, in how buyers enforce policy over their own agents, and in how vendors price and justify outcomes to customers. The billing layer is where that trust becomes enforceable. In a world of autonomous agents, billing isn’t just the thing that sends invoices. It’s the governance surface for an economy that runs while everyone sleeps.

References

Note: The Stripe Annual Letter expands deeply on their vision of agentic commerce and heavily outlines the strategic direction for foundational infrastructure built to support machine-to-machine payments.