Machine-to-machine (M2M) payments: Why governance matters more than payment rails

To understand where M2M fits, it’s worth looking at the broader agentic commerce landscape. As the space matures, we’ll likely see multiple ways for agents to transact. At a high level, these transaction models differ in three ways: who the end-consumer is, how autonomous the transaction is, and what is actually being purchased.

With that framework in mind, we reached out to more than 70 enterprise merchants and ecosystem players. They’re the people closest to the problem and helped us map where machine-to-machine payments are already real, where it’s early, and what needs to change for adoption to scale.

Most agentic commerce is still concentrated around human-in-the-loop flows. An agent discovers options, prepares a purchase, and stages a payment, but the buyer is still a person, and the thing being purchased is ultimately consumed by that person. 

M2M payments are different. Here, the buyer is another agent (or system), and the purchase supports that agent’s execution of a task, even if the specific actions required to complete it were not explicitly spelled out by the user.  

Instead of buying consumer goods or services, an agent might purchase compute capacity, a domain name, access to a data feed, paywalled content, or additional model calls — all without a person creating an account or entering payment credentials at the time of purchase.

Four groups play a role in this ecosystem:

• Agent developers: Build and operate agents, choose the payment protocol, and manage the agents’ credentials and logic for responding to payment challenges. 

• Merchants: Expose products and prices in an agent-readable way, decide which rails and models to accept, and rely on their PSP for orchestration, controls, and settlement so agent-driven purchases fit existing billing flows.

• PSPs: Bridge agent-driven checkout with merchant systems by handling orchestration, policy enforcement, risk controls, and settlement across rails.

• Buyers: Set the objectives for agents, choose how they are funded (cards, credits, stablecoins), define limits and approvals, and review usage and spend to adjust policies over time. A buyer might be a company giving its engineering team's agent a capped monthly budget, or a person funding a personal AI assistant.

For example, a developer (buyer) is running an AI coding agent to build and ship a feature, giving it a budget of $50 to spend autonomously on infrastructure and data it might need along the way.

Partway through the task, the agent (agent developer's product) hits a rate limit on its inference provider and needs more compute to keep going, so it tops up directly with a cloud provider (merchant) charging per unit of usage. It then needs live pricing data to finish a calculation, so it queries a market data API (merchant) charging per call. Finally, it needs to test its output against another service, so it pays per-request to call a third-party tool (merchant).

Each of these is a discrete, usage-based transaction, and each follows the same pattern: the agent communicates its identity and intent to the merchant through a protocol suited to the rail. 

That’s how the merchant knows it's dealing with an authorized agent, and what that agent wants to buy. Payment then settles on whatever rail fits: a scoped virtual card for one merchant; a stablecoin wallet metering usage in real time for another. Each merchant applies its own seller policy, deciding how much it's willing to sell an unverified agent before requiring a real account or additional checks.

Rather than a single payment event, it’s more useful to think of M2M as a stack.

To better understand how businesses are approaching M2M payments, we asked enterprise merchants and ecosystem players about the opportunities, blockers, and use cases they see. Three themes emerged from those conversations.  

Theme 1: Demand is real, but narrow

Data pulled June 26, 2026, reflecting the latest machine to machine payments news available at time of writing.

Interest in M2M payments is genuine, but adoption is early and concentrated, with much of today’s volume coming from testing, hackathons, token purchases, and other early digital-native use cases. The numbers reflect that. 

As of mid-2026, the two leading machine-payment protocols, x402 protocol and MPP, show relatively modest activity. X402 protocol has processed roughly $50m in cumulative volume since October, while MPP has processed around $200k since March. Average transaction values remain roughly between $0.05 and $0.30, with many industry participants expecting that to settle closer to $0.50 over time. 

Usage also spiked around launch for both protocols and has fallen in the last 30 days, suggesting the market is in an experimental, early-building phase rather than a sustained, scaling one.

What matters more than the numbers, however, is where demand is emerging. 

The strongest signals are coming from businesses whose products already lend themselves to usage-based consumption: APIs, compute, data, messaging, and modular digital services. These organizations are the most willing to experiment with M2M because their commercial model already fits small, repeated transactions.

For usage-native businesses, M2M payments aren't a novelty. They're the monetization infrastructure that makes charging for tiny units of usage commercially viable. Once it becomes economically practical to charge fractions of a dollar per API call, unit of compute, or data request, pricing models that were previously only theoretical become realistic.

The weaker pull comes from more traditional subscription businesses and trust-sensitive industries. While many see machine payments as strategically important over the long term, their immediate challenges lie elsewhere.  

For subscription businesses, moving from predictable recurring revenue to usage-based pricing represents a commercial shift, and often a perceived shift in how investors value the business.

For regulated and trust-sensitive industries, the challenge is different again: before considering payment rails, they’re focused on fraud, liability, governance, and maintaining appropriate levels of control over autonomous purchasing.

Ultimately, what separates early adopters from everyone else is how much their existing commerce model would need to change:  

• Cohort 1: Net-new, usage-native businesses: Built now, with usage-based charging and agent-triggered workflows native from day one. Smaller today, but often the cleanest design partners because their architecture already assumes machine-driven workflows.

• Cohort 2: Usage-oriented digital businesses: Already support, or are experimenting with, usage-based pricing. These organizations are most likely near-term adopters, because their model already fits low-value, repeated, API-triggered purchases.

• Cohort 3: Subscription and fixed-price businesses: See the direction, but aren't operationally ready. Blockers are pricing-model changes, trust concerns, unclear demand, or dependence on broader product and GTM changes beyond payments alone. Some also haven't engaged with M2M proactively at all and don't yet see it as a priority. 

Theme 2: Rails will coexist, not compete

Much of the current conversation frames cards and stablecoins as competing alternatives. 

What we heard from merchants suggests otherwise. Rather than one replacing the other, different payment rails are likely to serve different parts of the transaction. 

Two separate questions get conflated under rails: how an agent is funded and authorized to transact, and how the merchant ultimately receives settlement. These are distinct problems, and the right answer may differ for each.

Viewed this way, the hybrid model becomes clearer. Agents may pay via card-based credentials or stablecoin wallets, while merchants settle via batching, direct stablecoin settlement, or intermediary-led flows. The question is less which rail wins and more which rail makes sense for each stage of the transaction.

Theme 3: The value is in the control layer

Merchant concerns are consistently clustered into three areas.

While none are unique to M2M payments, each becomes more pronounced as transactions become increasingly autonomous.

1. Fraud, liability, and who carries the risk 

Merchants are unclear on who is on the hook when an agent goes wrong, for instance if it buys something outside user intent. They worry about absorbing chargebacks and operational costs even when the fault sits in the agent layer. 

Disputes can get harder, with weaker evidence of explicit user consent and more "the agent did it" scenarios. Several also fear friendly fraud will rise as customers feel more detached from transactions. 

The blunt version, as one merchant put it: “Early agentic flows risk re-introducing the exact fraud and low-authorization patterns we spent years eliminating.” 

There are also questions to be answered around intent, authorization, what that means in practice, and who the arbiter is: does it live at the payment rail level, or somewhere else? 

2. Loss of control over discovery and checkout 

If agents sit between customers and merchants, many fear losing visibility into how buying decisions get made, which offers get surfaced, and what data they retain for risk and personalization. 

Protocols that pass only minimal fields to the merchant strip away the device, behavioral, and contextual signals that current risk models depend on, making good traffic harder to tell from bad.

3. Operational and governance concerns 

Merchants repeatedly stressed the need for new governance, not just new rails: internal work to build agent policies, permissions, and monitoring, effectively a "know your agent" discipline. And for businesses that aren't usage-native, moving from subscriptions or fixed pricing to fine-grained, agent-triggered usage raises questions about pricing, forecasting, and reporting.

Every one of those concerns points away from the rail and toward the same thing: not can the payment be made, but can it be governed. 

The consistent signal from merchants is that the hard, valuable problem isn't moving the money. It's verifying identity and enforcing spend policy. The organizations that’ll create the most value in autonomous commerce are those who can confidently answer two questions: 

• “Is this agent who it claims to be?”

• “Is this transaction operating within the rules it was given?” 

For all the discussion of rails and control, the questions merchants raise most are often foundational.

The first is discoverability. 

Before an agent can pay for anything, it has to find it. Most merchants are still working out how to make their pages and catalogs readable by agents. This is where a large share of near-term attention is going: not "How do we get paid by an agent," but "How does an agent even know what we sell." 

The second is monetization fit. 

Machine-driven purchasing assumes usage-based consumption, but most merchants weren't built that way. Moving from subscriptions or fixed pricing to per-unit, agent-triggered charging raises questions about whether the model fits the business: how to price, forecast, and report, and whether it’s compatible with existing commercial and valuation logic. For usage-native businesses this is a small step; for everyone else it's a strategic shift that has to be resolved before machine payments are relevant at all.

Both point to the same conclusion. 

From a merchant’s vantage point, protocol debates and new rails are background noise unless and until agents can discover what they sell and their commercial model fits machine-scale, usage-based consumption.

Machine‑to‑machine payments are still early, and a large share of today’s traffic is simulated or experimental — testing, hackathons, token activity — rather than durable, production‑scale demand. That makes it useful for merchants to treat M2M as an emerging pattern to understand and monitor, not a fully formed market they need to chase immediately.

In that context, the choice of rail matters less than it might seem. Cards, credits, and stablecoins are all likely to play a role, but the hard problem merchants describe is not “can an agent move money,” it is “can we govern what agents do.” The real leverage sits in the governance layer: how identity is established, what controls and limits are set, how intent is defined, and how spend policies are enforced when agents transact on behalf of people and businesses.

For most merchants, the most useful work right now is preparatory rather than reactive. 

The priority is to get product and architecture ready for agents — making at least part of the catalog machine‑readable, exploring where usage‑based pricing genuinely fits, and defining clear internal rules for how agents are identified, credentialed, and allowed to spend. 

The immediate risk for most merchants isn't failing to chase a fully mature market overnight. It's failing to prepare for the governance and infrastructure questions that will matter once the category materializes.