ap2 and x402

two protocols got most of the attention in agentic payments over the last year. they answer different questions. most of the confusion comes from treating them as competitors.

ap2 is the agent payments protocol, announced by google in september 2025 with about 60 launch partners and since donated to the fido alliance. its core idea is the mandate. an intent mandate is a cryptographically signed record of what the user asked for, like “find me running shoes under $120”. a cart mandate signs the exact final cart before the purchase executes. when a dispute happens, there is a chain of evidence connecting the charge back to a human decision. ap2 does not care how the money actually moves. cards, bank transfers, and stablecoins all fit under it, which is what you would expect from a protocol designed with card networks at the table. it exists to make liability answerable.

x402 comes from coinbase and cloudflare, and it revives http status code 402, payment required. a server answers a request with 402 and a price. the client retries with a signed stablecoin payment in a header, usually usdc on base or solana, and gets the response. no account. no api key. it is metering for machines, sized for payments as small as a fraction of a cent. by spring 2026 it had processed around 165 million transactions from roughly 69,000 active agents, and when stripe shipped support for it in february the protocol stopped being filed under crypto experiments. the honest caveat: measured real-commerce volume is still only tens of thousands of dollars a day. a lot of the current traffic looks speculative.

put them side by side. the split is clean. ap2 answers “was this purchase authorized, and who eats the loss when it wasn’t”. x402 answers “how does an agent pay for one http request without a signup flow”. a serious agent stack will end up using both, and there is already an a2a extension wiring x402 payments into ap2-style flows.

what neither protocol gives you is the agent-side spend layer. something still has to enforce the budget, deduplicate the retries, and keep books the user can reconcile against a bank statement. that is double-entry bookkeeping with an idempotency key, and nobody has standardized it yet.