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

Three competing standards for agentic payments shipped within a single 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. 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.

All three protocols share the same basic flow:

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 those settled in USDC. The micropayment thesis is proving out faster than most expected.

The three 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.

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.

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 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

All three 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, 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.

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. 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.

The honest answer is that these protocols are not mutually exclusive. x402 and AP2 already have an explicit integration (the A2A x402 extension). Stripe supports both 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.