What are AP2, MPP, and x402? The payment protocols behind AI agent commerce

What is the difference between AP2, MPP, and x402?

The three protocols solve three different problems in the payment layer:

• AP2 handles authorization. It produces verifiable, non-repudiable proof that a buyer approved what their agent is doing.
• MPP handles settlement. It defines how an agent transmits payment to a business over card rails or stablecoin rails.
• x402 handles web-native charging. It lets a server require payment for an HTTP request, just as it serves one.

Because each protocol operates at a different function, evaluating them as competitors misreads the architecture. Visa has contributed card specifications to MPP and holds premier membership in the x402 Foundation, while co-chairing the FIDO Alliance working group that stewards AP2. The same payment network participates in all three specifications simultaneously.

The specifications also reference each other directly. The AP2 documentation includes an integration guide for executing x402 settlement under an AP2 authorization. The Universal Commerce Protocol, which standardizes the shopping interaction one layer up, designates AP2 as its payment method rather than specifying its own.

The same principle applies here as at the commerce layer: no single protocol powers AI shopping, and no single protocol powers AI payment. Authorization, settlement, and web-native charging are separate functions. The industry is standardizing each one independently, with defined integration paths between them.

The relevant question for a brand isn’t which protocol wins adoption. It’s which functions intersect with your business, and what each specification requires of your systems when they do.

AP2 (Agent Payments Protocol): the authorization standard

The Agent Payments Protocol is an open specification for proving that a buyer authorized an agent’s transaction. Google announced the protocol in September 2025 with a coalition of payments and technology partners, then donated it to the FIDO Alliance on April 28, 2026 for platform-neutral, community-led governance.

• The problem it solves: Today’s payment systems assume a human is clicking “buy” on a trusted website. An agent-initiated payment breaks that assumption and raises three questions current infrastructure cannot answer: was the agent authorized, does its request reflect the buyer’s actual intent, and who is accountable if the transaction is wrong?
• How it works: AP2 anchors trust in verifiable credentials, which are cryptographically signed, tamper-evident digital objects. An Intent Mandate defines the conditions under which an agent may purchase on the buyer’s behalf. A Cart Mandate captures the buyer’s explicit, non-repudiable approval of a specific cart and price. A Payment Mandate signals agent involvement to the payment network and issuer.
• Autonomous transactions: AP2 v0.2, released alongside the FIDO donation, adds support for “Human Not Present” payments. An agent can execute a purchase without the buyer in the session, acting on pre-authorized instructions with defined constraints such as price ceilings and timing.
• Accountability: Verifiable Intent, a complementary standard co-developed with Mastercard and also donated to FIDO, records user-authorized agent actions in a tamper-proof, auditable log. Two FIDO technical working groups now develop the standards, with chairs including Google, OpenAI, CVS Health, Mastercard, and Visa.
• Payment methods: AP2 is method-agnostic. It authorizes rather than settles, covering cards today with a roadmap that includes real-time bank transfers such as UPI and PIX, as well as digital currencies.
• What it doesn’t cover: AP2 proves the buyer approved the purchase. It does not verify that the product data the agent evaluated was accurate. 

MPP (Machine Payments Protocol): the settlement standard

The Machine Payments Protocol is an open standard for agents to send and receive payments, co-authored by Stripe and Tempo, a payments-focused blockchain incubated by Stripe and Paradigm. It launched on March 18, 2026, alongside Tempo’s mainnet going live.

• The problem it solves: The tools of the current financial system were built for humans. Completing a purchase can require an agent to create an account, navigate a pricing page, choose a subscription tier, enter payment details, and set up billing. Each step assumes a person, and each is a point at which an autonomous transaction stalls. Stripe’s launch announcement frames MPP as the internet-native alternative: a standard way for agents to pay without human-shaped friction.
• How it works: MPP defines the request-and-settle flow between an agent and a business. It supports both fiat and stablecoin settlement, and while it currently runs on Tempo, the protocol specification is designed to operate across multiple blockchains and payment rails rather than binding to one.
• Merchant adoption path: Businesses on Stripe can accept MPP payments through the existing PaymentIntents API in a few lines of code, taking payment from agents in stablecoins as well as fiat methods including cards.
• Card network support: Visa contributed specifications for agents to pay with credit and debit cards over MPP, extending the protocol beyond stablecoin rails into card networks’ acceptance infrastructure.
• What it doesn’t cover: Unlike AP2 under the FIDO Alliance and x402 under the Linux Foundation, MPP has no neutral standards body. It is also the youngest of the three, with a mainnet that went live the same day the protocol did. 

x402: the web-native payment standard

When the HTTP specification was written in 1991, it reserved status code 402, “Payment Required,” for a future in which the web could natively charge for access. The code sat unused for more than three decades. x402 puts it to work: a server responds to a request with a 402, the agent pays, and the request completes. Payment becomes part of the HTTP exchange itself, with no account, no stored card, and no prior relationship between the parties.

• Origin and governance: Coinbase built x402 and contributed it to open governance. The x402 Foundation launched operationally under the Linux Foundation on July 14, 2026, with 40 member organizations. Premier members include Visa, Mastercard, American Express, Stripe, Adyen, Fiserv, Google, Amazon Web Services, Shopify, Cloudflare, and Coinbase itself.
• How it works: The protocol embeds payment instructions in standard HTTP requests and responses. The x402 whitepaper specifies the flow: a resource server returns a 402 with payment requirements; the client submits a signed payment payload; a facilitator verifies and settles it; and the server delivers the resource. Settlement today runs primarily on stablecoins, with the Foundation’s scope supporting payment types ranging from cards to stablecoins.
• Ideal transaction profile: x402 is built for payments that the card economics of the last three decades made unworkable: high-frequency, sub-dollar, machine-to-machine transactions such as per-request API access, data queries, and compute. An agent can pay a fraction of a cent per request, thousands of times a day, with no subscription or invoice on either side.
• Production status: The protocol processes live transaction volume, and all three major card networks pay for premier membership in its governance body. Genuine commercial demand is still maturing; the strongest evidence of momentum is who has committed to the standard, not yet how much moves across it.
• What it doesn’t cover: x402 charges for a request. It has no view into whether the data or product behind that request is correct. The protocol’s own economics compound the risk: at machine speed and sub-cent cost, an agent transacting on wrong data does so thousands of times before anyone notices.

How do the protocols work together?

Payment protocols don’t operate alone. They sit at the bottom of a stack that includes the protocols that power AI shopping agents: MCP, which connects agents to merchant systems, and UCP and ACP, which standardize the shopping interaction and checkout. A single agent-driven purchase can traverse all of them.

Consider a real transaction. A contractor tells their AI assistant: “Reorder the 240V compressor motor we bought in March, under $300, by Friday.”

The agent finds the product through the merchant’s MCP server. It confirms specifications and stock through UCP catalog capabilities. It initiates checkout through the merchant’s ACP endpoints. It presents an AP2 Intent Mandate proving the contractor pre-authorized this purchase within a price ceiling and deadline. The payment settles over MPP.

Five protocols, one purchase, no human clicking anything. And every layer trusted one input, none of them verified: the product record that said “240V.” If that record is wrong, MCP serves it, UCP confirms it, ACP transacts on it, AP2 binds the buyer to it, and MPP settles it. The stack moves the data faithfully. It does not check it.

AP2 vs. MPP vs. x402: comparison table

None of the three protocols carries a license fee. All are free, open specifications. What differs is the cost of using them, who does the implementation work, and how ready each one is for production today.

How do you choose the right payment protocol?

For most brands, choosing a payment protocol is an exercise in awareness. Implementation falls to payment providers, AI platforms, and infrastructure vendors. Three questions determine which protocols reach your business, and through which vendor.

1. Who is buying from you? 

For consumers purchasing through AI assistants, AP2, which arrives bundled, is designated as the payment method by UCP. Agents buying goods, services, or software at conventional transaction sizes means MPP; businesses on Stripe can enable acceptance through the PaymentIntents API. Machine-to-machine, sub-dollar transactions mean x402.

2. What does your payment provider already support? 

Check what your PSP, commerce platform, and card network have shipped.

3. What can you defer?

Most of it. The protocols interoperate by design, so an early wrong bet is cheap to correct. What must be ready from day one is the input every protocol transacts on: your product data.

What does the future of e-commerce look like with AI shopping agents?

The evidence points to three shifts already underway.

Discovery compresses. 

Traffic from AI sources to U.S. retail sites grew 393% year over year in the first quarter of 2026, on Adobe data covering more than a trillion retail visits. Gartner predicts that SEO and pay-per-click give way to agent engine optimization, with procurement shifting to autonomous machine-to-machine transactions. An agent evaluates structured product data and returns a shortlist. Brands compete to be in it.

Transactions happen without shopping sessions. 

AP2’s “Human Not Present” support exists because buyers want delegation with boundaries. Visa’s own research found that 58% of Americans are comfortable with AI comparing prices, 38% are comfortable with AI completing a purchase autonomously, and 60% are unwilling to let an agent spend without prior approval. Pre-authorized mandates are the design answer to that gap. For purchases inside those mandates, the product record is the entire customer experience. No human sees a product page.

The layers standardize at different speeds. 

Payments went from vendor projects to two standards bodies inside a year. Product data has no standards body coming. Adobe’s content visibility analysis found retail product pages average 66% readable to the AI models driving that traffic. The transaction infrastructure is being built industry-wide. The readiness of what agents transact on is built merchant by merchant.

Is your product data ready for agents to transact on?

AP2 proves the buyer authorized the purchase. MPP settles it. x402 charges for it. None of them verify that the product record the agent acted on was accurate. A wrong specification travels through every protocol intact and comes out the other side as an authorized, settled, wrong transaction.

Agent-ready product data means every record is complete, validated, and current when an agent reads it, across all protocols that request it. That is an operational discipline. Inriver orchestrates it: product data from any source, governed through AI-driven validation, so what reaches an agent through any protocol is trusted product information.

The protocols will keep multiplying. Product data that agents can trust is the requirement that stays constant.

See how Inriver prepares your product data for agent-driven commerce. Book a personalized demo today.