Agentic payments: what x402, AP2 and MPP mean for builders

Four competing standards for agentic payments shipped within little more than a year. x402 from Coinbase, AP2 from Google, and MPP from Stripe and Tempo all use the dormant HTTP 402 status code and all settle in stablecoins. The Agentic Commerce Protocol (ACP) from OpenAI and Stripe targets a different layer entirely: structured retail checkout between agents and merchants, settled over the merchant's existing payment rails. If you are building anything that involves an AI agent spending money, you need to decide which one, or which combination, to support.

This is the current state of each protocol, where they actually differ, and the four things you must build correctly regardless of which you choose.

Why this converged on HTTP 402

HTTP 402 ("Payment Required") has been reserved since 1991. For thirty years no one used it. The specification simply said "reserved for future use." It turns out the future is autonomous agents that need to pay per API call without a human's credit card in the loop.

Three of the four protocols share the same basic flow (ACP is the exception, more on that below):

No accounts. No OAuth flows. No subscription billing. The payment substitutes for the API key.

By April 2026, x402 alone had processed 165 million transactions across approximately 69,000 active agents, at an average transaction size under $0.31. Roughly 98.6% of machine payments settled in USDC, according to Keyrock's "Who Pays the Agent?" report. The micropayment thesis is proving out faster than most expected.

The four protocols

x402, Coinbase's open standard

Coinbase open-sourced x402 in May 2025, then donated it to the x402 Foundation at the Linux Foundation in April 2026. The foundation's launch members include Adyen, AWS, American Express, Circle, Fiserv, Google, Mastercard, Microsoft, Polygon Labs, Shopify, Solana Foundation, Stripe, and Visa, a deliberately broad coalition.

The protocol is deliberately minimal. A server returns a 402 with a JSON body describing the payment requirements (token, amount, destination address). The client pays, attaches the payment proof in a header, and retries. No custody, no session state, no central intermediary.

x402 currently runs primarily on Base (Coinbase's Ethereum L2), settling in USDC. The Coinbase CDP wallet infrastructure handles the agent-side wallet management. Coinbase launched a Bazaar MCP server to make paid APIs discoverable by agents.

AP2, Google's mandate-based protocol

Google's Agent Payments Protocol (AP2) takes a different approach. It extends the Agent2Agent (A2A) protocol and Model Context Protocol (MCP) with a mandate system: cryptographically-signed digital contracts that establish what an agent is authorized to buy and under what conditions.

AP2 distinguishes between two authorization modes:

Human-present: An Intent Mandate captures the user's request. A Cart Mandate is generated from the specific items and prices. The user approves the cart before payment. This is closer to a traditional checkout with an agent doing the browsing.

Human-absent (delegated): The user pre-authorizes conditions upfront ("buy concert tickets under $150 when they go on sale"). The agent generates a Cart Mandate autonomously when conditions are met and executes the purchase. The mandate creates a non-repudiable audit trail.

AP2 is payment-agnostic, it supports cards, stablecoins, real-time bank transfers, and stored value. Google collaborated with Coinbase, the Ethereum Foundation, and MetaMask on an A2A x402 extension that handles stablecoin settlement within the AP2 framework. The protocol launched with 60+ partner organizations including Adyen, American Express, Mastercard, PayPal, Worldpay, Etsy, and Intuit.

MPP, Stripe and Tempo's session-aware protocol

Stripe co-authored the Machine Payments Protocol with Tempo in March 2026. Tempo is a purpose-built Layer-1 blockchain, developed with Paradigm, designed specifically for high-frequency stablecoin transactions. MPP runs on Tempo mainnet, settling in USDC.

MPP uses the same HTTP 402 handshake but adds a dual-method architecture. A server can advertise both a crypto method (on-chain via Tempo) and a fiat method (via Stripe's Shared Payment Tokens). The client selects:

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="chal_abc123", method="tempo", intent="charge", ...
WWW-Authenticate: Payment id="chal_def456", method="stripe", intent="charge", ...

This means an agent with a funded USDC wallet uses the Tempo path; a traditional service consuming the API can use the SPT/card path. Same endpoint, two rails.

Stripe's PaymentIntents API handles both paths. Crypto payments auto-capture when funds settle on-chain. Visa, Stripe, and Lightspark have already extended MPP to cards, wallets, and Bitcoin Lightning respectively.

ACP, OpenAI and Stripe's checkout standard

The Agentic Commerce Protocol is the odd one out. It does not use HTTP 402 and it is not built for micropayments. Announced by OpenAI and Stripe in September 2025, ACP standardizes how an AI agent completes a retail checkout against a merchant's existing commerce backend. It is the protocol behind Instant Checkout in ChatGPT, which launched with Etsy sellers and expanded to Shopify merchants including Glossier, Vuori, and SKIMS. The spec is Apache 2.0 licensed and maintained by OpenAI and Stripe, with the reference documentation in OpenAI's agentic commerce docs.

ACP has three building blocks. Product feeds give the agent a machine-readable catalog so it can surface items in conversation. Checkout sessions are a REST flow the merchant implements: the agent creates a session, updates the cart and fulfillment options, and completes it. Delegate payments move the money: the agent passes a Shared Payment Token instead of raw card credentials. If that name sounds familiar, it is the same Stripe primitive that MPP's fiat path uses.

The authorization model is human-present by design. The buyer confirms each purchase inside the chat, and the SPT the agent carries is scoped to a single merchant, capped at a maximum amount, and expires with the checkout session. There is no standing delegation and no autonomous spending. The merchant stays merchant of record, keeping control of pricing, fulfillment, returns, and fraud decisions.

Settlement is deliberately boring: the merchant's existing payment processor charges the token like any other payment, on card rails, with card economics. The spec is processor-agnostic even though Stripe shipped the first SPT implementation. No wallets, no stablecoins, no chains.

Choose ACP when you sell physical goods, digital products, or subscriptions and want them purchasable where agent traffic already is. It solves distribution, not machine-to-machine metering. An agent paying $0.003 per API call has no use for a checkout session; a merchant who wants ChatGPT users to buy without leaving the conversation has no use for a USDC wallet. The protocols barely overlap, which is why most stacks will end up with both.

Protocol comparison

The key difference is authorization philosophy. x402 is minimal by design: if the agent can pay, it can access the resource. AP2 adds a formal consent and delegation layer that creates an auditable record of what the user authorized. MPP sits between them, structured enough for compliance, simple enough to implement in a few lines via the Stripe SDK. ACP sidesteps delegation entirely: a human confirms each purchase, and the token the agent carries is scoped to one merchant, one amount, one expiry window.

What you actually have to build

Whatever protocol you support, four components matter. None of them are exciting. All of them break in production.

1. Authorization and mandate management

For human-absent flows, you need a way for users to define spending policies upfront. At minimum: per-category spending caps, a maximum per-transaction amount, and a hard daily/weekly ceiling. For AP2, those constraints are encoded in the Intent Mandate. For ACP, the Shared Payment Token enforces merchant, amount, and expiry scoping at the token layer. For x402 and MPP, you enforce them yourself in the agent runtime before allowing a payment to proceed.

Do not skip this. An agent with open-ended wallet access and a bug is an expensive bug.

2. Settlement and custody

The three 402-based protocols currently bias toward USDC on Ethereum-family chains (Base for x402, Tempo for MPP, chain-agnostic for AP2's crypto path). Your agent needs a funded wallet. The questions are: who holds the keys, how is the wallet topped up, and what is the float strategy.

Self-custody gives you control but puts key management in your stack. MPC wallets (Coinbase CDP, Privy via Stripe) delegate that complexity to a custodian. The same trade-offs we covered when building stablecoin payment rails apply here, custody is the decision you will keep revisiting as volume grows.

For fiat flows (MPP's SPT path, ACP checkouts, AP2's card rail), you are back in traditional payment processing territory. Stripe's dashboard handles reconciliation. The complexity is lower but fees are higher.

3. Idempotency

Agents retry. Networks drop packets. The 402→pay→retry loop is inherently at-risk of double payments if your server or client is not idempotent.

On the server side: deduplicate payment proofs. An x402 payment receipt is an on-chain transaction hash, treat it as the idempotency key. Cache it with a TTL that exceeds your maximum retry window (5 minutes is the recommendation in the MPP docs; longer is safer). On the client side: do not retry a payment unless you have confirmed the previous payment either failed or was not submitted.

A double payment in a micropayment context (sub-$1 per call) is manageable. A double payment on a $500 software license purchase via an autonomous agent is a support ticket you cannot easily resolve.

4. Reconciliation

Agent payments break the assumption that a human initiated each transaction. Reconciliation tooling needs to answer: which agent, for which task, authorized by which user, at what time, for what amount. AP2's mandate chain gives you that audit trail by design. x402 gives you on-chain transaction data. MPP gives you Stripe Dashboard events plus on-chain receipts. ACP gives you checkout session records and order webhooks. The matching problems are the same ones we cover in building a payment reconciliation engine, except the initiating party is now software.

Plan for this before you have 10,000 transactions a day and someone asks you to reconstruct the spending for a specific user's agent session last Tuesday.

The competitive picture

Juniper Research projects $8 billion in agentic payments spend in 2026, growing to $1.5 trillion by 2030. Visa invested in Replit in May 2026 specifically to build agentic payment tooling for developers. The card networks are not standing still.

The interesting observation from the x402 traction numbers is that the average transaction value is under $0.31. That is firmly micropayment territory, API calls, data access, compute. At that price point, card rails are economically unworkable (Visa/Mastercard minimum fees exceed the transaction value). Stablecoins win by default at the bottom of the value distribution.

AP2's card support and MPP's SPT path matter for higher-value delegated purchases: software licenses, SaaS subscriptions, B2B procurement. ACP's bet is different again, distribution rather than rails: Instant Checkout puts merchant catalogs directly in front of ChatGPT's traffic, on ordinary card economics. That is a different problem from paying $0.003 for a vector search API call.

Which one to build for

If you are building a paid API or data service that agents will call: x402 is the fastest path to production. The protocol is minimal, the SDK is small, and the ecosystem is the largest.

If you are building an agent that makes purchasing decisions on behalf of users, and you need defensible consent capture for compliance or fraud reasons, AP2's mandate model gives you an audit trail that a payment receipt alone does not.

If you are already using Stripe for payment processing, MPP is the obvious path. You get both crypto and fiat rails from the same API, and it integrates with your existing Stripe Dashboard reconciliation.

If you sell products and want them purchasable inside ChatGPT and whatever agent surfaces adopt the spec next, ACP is the only one of the four with a live consumer channel today. Implement the product feed and checkout spec, keep your merchant-of-record status, and your existing payment processor handles the money.

The honest answer is that these protocols are not mutually exclusive. x402 and AP2 already have an explicit integration (the A2A x402 extension). Stripe co-authored MPP and ACP, sits in the x402 Foundation, and supports MPP and x402 from the same endpoint stack. You will likely end up implementing multiple.

If you are scoping out the payment authorization, settlement, or reconciliation layers for an agent-native product, that is exactly the kind of architecture problem we work through with fintech and Web3 teams. Get in touch if you want a second opinion.