The Machine Payments Protocol | AXD Observatory

The protocol is elegant. An agent requests a resource. The service names a price. The agent pays. The resource is delivered. Four steps. No account creation, no pricing page navigation, no subscription tier selection, no billing setup. Commerce reduced to its protocol-level essence: request, price, pay, deliver.

But MPP does not arrive in isolation. It is the third major payment protocol to emerge for the agentic economy in less than six months - alongside Stripe's own Agentic Commerce Protocol (ACP), co-authored with OpenAI, and Coinbase's x402 protocol. Google's Universal Commerce Protocol (UCP) preceded them all. Visa and Mastercard are building their own network-specific frameworks. The result is not convergence. It is proliferation.

This essay analyses what MPP is, what it solves, what it leaves undesigned, and why the protocol proliferation problem - the simultaneous emergence of multiple incompatible payment standards for autonomous agents - is the defining infrastructure challenge of agentic commerce in 2026.

The Four-Step Architecture of Machine Payments

The Machine Payments Protocol is built on a deliberately minimal architecture. Its designers - Jeff Weinstein, Stripe's Product Lead for Agentic Commerce, and Steve Kaliski, Stripe's Engineering Lead for Agentic Commerce - describe it as "an open standard, internet-native way for agents to pay." The protocol operates in four steps.

Step one: request. An agent sends an HTTP request to a service, API, Model Context Protocol (MCP) server, or any HTTP-addressable endpoint. The request is indistinguishable from any other HTTP request - the protocol does not require the agent to identify itself as non-human at this stage.

Step two: price. The service responds with a payment requirement. This is the protocol's key innovation: instead of presenting a pricing page, a subscription tier selector, or a checkout flow designed for human navigation, the service returns a machine-readable payment specification. The price, the currency, the payment methods accepted, and the conditions of the transaction are all encoded in the response.

Step three: pay. The agent authorises the payment using a Shared Payment Token (SPT) - a credential that can represent either a stablecoin wallet or a tokenised card. The dual-rail approach is architecturally significant: the same protocol supports both crypto-native and traditional payment methods, allowing agents to transact across the full spectrum of financial infrastructure.

Step four: deliver. The service delivers the resource to the agent. The transaction is complete. For Stripe merchants, the payment appears in their existing Stripe Dashboard alongside human transactions - same settlement, same payout schedule, same fraud protection, same reporting infrastructure.

The elegance of this architecture lies in what it removes. No account creation. No session management. No cookie-based authentication. No checkout redirect. No human-designed interface of any kind. As Matt Huang, co-founder of Tempo and managing partner at Paradigm, told Fortune: "Our team just came up with what we thought was the most elegant, minimal, efficient protocol that anyone can extend without our permission."

The early adopters reveal the emerging shape of the agent economy. Browserbase lets agents spin up headless browsers and pay per session. PostalForm lets agents pay to print and send physical mail. Prospect Butcher Co. lets agents order sandwiches for human pickup or delivery anywhere in New York City. Parallel Web Systems lets agents pay per API call for web access. And agents can now programmatically contribute to Stripe Climate - the first instance of autonomous charitable giving by machine.

What Tempo Brings to the Stack

Tempo is not a minor co-author. It is a payments-focused Layer 1 blockchain, incubated by Stripe and backed by Paradigm, that raised $500 million at a $5 billion valuation in 2025 from investors including Thrive Capital. Its mainnet launched on the same day as MPP - March 18, 2026 - after three and a half months in testnet. The simultaneous launch was not coincidental. MPP runs on Tempo today, but the protocol is designed to operate across multiple blockchains and payment rails.

What Tempo brings is the stablecoin rail. While Stripe provides the fiat infrastructure - card processing, PaymentIntents API, fraud detection, tax calculation - Tempo provides the crypto-native infrastructure: high-speed stablecoin settlement, programmable payment logic, and on-chain transaction finality. The combination creates what the AXD Institute has previously identified as the dual-rail architecture necessary for the protocol convergence phase of agentic commerce.

The strategic implications are significant. Stripe now controls both sides of the agentic payments stack. ACP, co-authored with OpenAI, is the buyer-side protocol - it enables agents to discover products, compare options, and complete purchases on behalf of humans. MPP is the seller-side protocol - it enables services to accept payments from agents programmatically. Together, they form a complete circuit: an agent using ACP to find and select a product can pay for it using MPP, with Stripe processing both sides of the transaction.

This is not merely a product strategy. It is an infrastructure play of the kind that defined the early internet. Just as PayPal captured both sides of the eBay marketplace, Stripe is positioning itself to capture both sides of the machine customer marketplace - the protocol through which agents buy and the protocol through which services sell.

Visa's Card-Native Extension: Command Line Commerce

Visa's participation in MPP is the most consequential endorsement the protocol has received. The world's largest payment network did not merely announce support - it released two concrete technical artefacts on launch day.

The first is a Card-Based MPP Specification: a full technical document that defines how tokenised card credentials are passed, authenticated, and processed inside MPP-compatible workflows. The specification is openly available, processor-agnostic, and designed to allow any merchant, payment service provider, or acquirer to participate in MPP payment flows using existing card infrastructure.

The second is a Visa SDK for Card-Based MPP: a software development kit that implements the specification and gives developers a path to building card-based transactions for MPP. The SDK is designed for what Visa calls "programmatic, terminal-native environments" - the command-line interfaces and API endpoints where agents operate, not the browser-based checkout flows where humans shop.

Both are built on Visa's existing Intelligent Commerce and Trusted Agent Protocol infrastructure. This is architecturally important: Visa is not building a separate system for agent payments. It is extending its existing infrastructure to accommodate a new category of payer. The tokenisation, authentication, and agent identity verification that Visa has been developing through its Intelligent Commerce programme now have a concrete protocol-level implementation.

Visa coined a term for this: Command Line Commerce. The phrase captures a structural truth. Agents do not browse. They do not click. They do not navigate visual interfaces. They issue commands, receive responses, and execute transactions at the protocol level. Commerce for agents is not an experience to be designed in the traditional UX sense - it is a protocol to be specified. Visa's recognition of this shift, embedded in the very name it gives to the category, signals that the world's largest payment network understands that the machine customer is not a human customer using a different device. It is a fundamentally different kind of economic actor.

Rubail Birwadker, Visa's Global Head of Growth Products and Strategic Partnerships, framed the challenge precisely: "We're entering a moment where agents can make decisions, move resources and pay for services on their own. But for these kinds of payments to scale, security isn't optional - it has to be built into every layer, from authentication and data privacy to fraud prevention."

The Protocol Proliferation Problem

MPP is elegant. But it does not exist in a vacuum. It arrives into a landscape where at least five major payment protocols are competing simultaneously for the agentic commerce stack, with no interoperability standard connecting them.

The comparison reveals a structural problem. Each protocol solves a real problem. ACP enables agents to shop. MPP enables services to be paid by agents. x402 embeds payment requirements directly into HTTP responses. UCP provides a cross-platform framework. Visa and Mastercard are building network-level agent identity. But none of them interoperate. A merchant who wants to accept payments from all types of agents must implement all of them - or choose a subset and exclude the rest.

This is not a temporary inconvenience. It is a structural feature of the current phase of agentic commerce. The AXD Institute has identified this as the protocol proliferation problem: the period in which multiple incompatible standards compete for adoption before market forces, regulation, or industry coordination produce convergence. The internet went through this with networking protocols in the 1980s. The web went through it with browser standards in the 1990s. Mobile payments went through it with NFC, QR codes, and proprietary wallets in the 2010s. Agentic commerce is going through it now.

The difference is speed. The internet's protocol wars took a decade. The browser wars took five years. The agentic protocol proliferation is happening in months. Five major protocols in less than a year. The compression of the timeline means that the costs of fragmentation - merchant confusion, developer fatigue, agent incompatibility, and consumer harm from inconsistent trust guarantees - will accumulate faster than in any previous protocol transition.

What MPP Solves and What It Leaves Undesigned

MPP solves a genuine problem. The tools of the current financial system were built for humans. Making a purchase today requires an agent to create an account, navigate a pricing page, choose between subscription tiers, enter payment details, and set up billing - steps that often require human intervention. MPP eliminates all of them. It reduces commerce to a four-step protocol exchange that an agent can complete in milliseconds.

But the AXD discipline asks a different set of questions. Not "can the agent pay?" but "should the agent pay?" Not "does the payment clear?" but "was the payment authorised by a human whose current circumstances support it?" Not "did the transaction complete?" but "what happens when the transaction fails in a context where no human is watching?"

MPP answers none of these questions. It was not designed to. The protocol specification contains no mechanism for verifying that the agent has valid delegated authority from a human principal. It contains no mechanism for confirming that the human's current circumstances - financial, legal, situational - support the transaction the agent is about to execute. It contains no mechanism for Know Your Agent verification. It contains no mechanism for what the AXD Institute has termed Know Your Human - the continuous validation that the human behind the mandate is still the human who issued it, and that their authority has not drifted.

This is not a criticism of MPP's design. Payment protocols should not try to solve trust problems. TCP/IP does not verify the identity of the humans sending packets. SMTP does not confirm that the sender of an email is who they claim to be. HTTP does not validate the authority of the client making a request. These are infrastructure protocols. They move data. Other layers - authentication, authorisation, identity - are built on top of them.

The problem is that the "other layers" do not yet exist for agentic commerce. The payment protocols are being built. The trust protocols are not. The rails are being laid. The governance is not. The money can move. The authority cannot be verified.

The Trust Architecture Gap

The AXD Institute's analysis of the current protocol landscape reveals a consistent pattern: every major protocol solves the payment mechanics - how money moves from agent to service - but none address the trust architecture questions that the discipline identifies as primary.

Consider the four questions that any trust-governed agentic transaction must answer:

MPP addresses none of them. ACP addresses none of them. x402 addresses none of them. UCP addresses none of them. The payment rails are being built at extraordinary speed. The trust rails are not being built at all.

Visa comes closest. Its Trusted Agent Protocol and Intelligent Commerce framework include mechanisms for agent identity verification and tokenised credential management. Mastercard's Verifiable Intent protocol treats agent intent as an auditable object. But these are network-specific implementations, not open standards. They work within their respective card networks. They do not work across the broader protocol landscape.

The result is a structural inversion. In the human economy, trust infrastructure was built first - identity verification, credit scoring, fraud detection, consumer protection law - and payment protocols were built on top of it. In the agentic economy, payment protocols are being built first, and trust infrastructure is assumed to follow. The AXD Institute's position is that this inversion is not merely suboptimal. It is dangerous. Payment rails without trust rails create a system in which money can move faster than authority can be verified - and in which the consequences of that gap will be borne by the humans who delegated authority to agents they can no longer see.

The Merchant's Dilemma: Five Protocols and No Standard

For merchants, the protocol proliferation problem is not abstract. It is an immediate operational challenge. A merchant who wants to accept payments from autonomous agents in March 2026 faces a concrete decision: which protocols to implement, in what order, and at what cost.

Implementing MPP is straightforward for existing Stripe merchants - "a few lines of code," according to Stripe's documentation. But MPP only covers agents that use the MPP protocol. An agent built on OpenAI's infrastructure might use ACP. An agent built on Coinbase's infrastructure might use x402. An agent built on Google's ecosystem might use UCP. A merchant who implements only MPP will be invisible to agents that speak a different protocol.

The merchant readiness challenge is compounded by the absence of a discovery layer. In the human economy, customers find merchants through search engines, social media, advertising, and word of mouth. In the agentic economy, agents find merchants through protocol-specific discovery mechanisms. An agent using ACP discovers merchants through Stripe's commerce graph. An agent using x402 discovers services through HTTP 402 responses. An agent using UCP discovers merchants through Google's ecosystem. There is no universal directory. There is no agentic equivalent of Google Search that indexes all protocols simultaneously.

This creates a fragmentation problem that mirrors the early internet. In the 1990s, a business needed a different website for Netscape and Internet Explorer because the two browsers rendered HTML differently. In 2026, a business may need different protocol implementations for different agent ecosystems because the protocols do not interoperate. The cost is not just technical. It is strategic. Every protocol choice is a bet on which agent ecosystem will win.

Stripe's position is uniquely advantageous here. By controlling both ACP (buyer-side) and MPP (seller-side), and by providing the payment processing infrastructure that underlies both, Stripe offers merchants a single integration point for two of the five major protocols. This is not accidental. It is the same platform strategy that made Stripe the dominant payment processor for the human web: make the integration easy, make the developer experience excellent, and let network effects do the rest.

What This Means for Agentic Experience Design

The Machine Payments Protocol confirms three propositions that the AXD discipline has maintained since its founding.

First, that absence is the primary use state. MPP is designed for transactions that happen without a human present. No checkout page. No confirmation dialog. No "are you sure?" prompt. The agent pays and the resource is delivered. The human who delegated authority to the agent may not know the transaction occurred until they review their statement - if they review it at all. This is not a bug. It is the protocol's design intent. And it means that every design decision about what happens when things go wrong - when the wrong resource is delivered, when the price is higher than expected, when the agent's authority has expired - must be made in advance, by the designer, not in the moment, by the user.

Second, that payment rails are not trust rails. MPP moves money. It does not verify authority. It does not confirm delegation. It does not validate the human behind the agent. The distinction is not semantic. It is architectural. A system that can move money without verifying authority is a system that can be exploited - not by hackers or fraudsters, but by the ordinary drift of human circumstances against standing mandates. The customer who loses their job. The couple who separates. The elderly parent whose cognitive capacity changes. The mandate persists. The authority does not. MPP cannot see the difference.

Third, that protocol proliferation is a design problem, not just a technical one. The five competing protocols do not merely create integration complexity for developers. They create trust architecture fragmentation for users. A human who delegates purchasing authority to an agent has no way to know which protocol that agent will use, which merchants it can reach, what trust guarantees each protocol provides, or what recourse exists when a transaction fails. The operational envelope - the boundaries within which an agent is authorised to act - is defined differently by each protocol. The result is that the same delegation can produce different outcomes depending on which protocol the agent happens to use. This is not a user experience problem. It is a trust architecture failure.

The AXD Institute's position is clear. The organisations that will lead the agentic economy are not those with the fastest payment rails or the most elegant protocol specifications. They are those that build the trust infrastructure on top of the payment infrastructure - the delegation design frameworks, the Know Your Human validation layers, the failure architecture blueprints, and the observability standards that make autonomous commerce not just possible but trustworthy.

A Final Image

Imagine a city in which five different road systems have been built simultaneously. Each road system is well-engineered. Each connects a different set of destinations. Each uses a different set of traffic rules. Each has its own toll collection mechanism. But none of them connect to each other. A driver entering the city must choose which road system to use before they know where they need to go - and once they have chosen, they cannot switch.

Now imagine that the drivers are not human. They are autonomous vehicles acting on behalf of humans who are not in the car. The humans gave instructions - "get me to the best restaurant" - but they did not specify which road system to use, because they did not know that five existed. The vehicle chooses. The human discovers the consequences later.

This is the state of agentic commerce in March 2026. The roads are being built at extraordinary speed. MPP is a well-engineered road. But the city has no map. The vehicles have no unified navigation system. And the passengers - the humans whose money is being spent, whose authority is being exercised, whose trust is being consumed - are not in the car.

The Machine Payments Protocol is an important piece of infrastructure. It deserves the attention it is receiving. But infrastructure without governance is a road without rules. And in the agentic economy, the rules are not about how fast the money moves. They are about whether the humans who delegated the authority to move it are still the humans who should have it.