AI agents can now browse, compare, and negotiate — but the checkout was built for humans. Cards assume a person behind a form; "pay on behalf of" produces disputes nobody can adjudicate because there is no machine-readable record of what the user actually authorized. Three protocols launched within weeks of each other in late 2025 to close that gap: Google's Agent Payments Protocol (AP2), Coinbase's x402, and Stripe and OpenAI's Agentic Commerce Protocol (ACP). They compete in places — but they mostly address different layers, and they already interoperate.
AP2: The Consent and Evidence Layer
AP2, released by Google in September 2025 under Apache 2.0 with more than sixty partners (Mastercard, Adyen, PayPal, American Express, Coinbase, Worldpay and others), is a payment-agnostic authorization framework. Its core primitive is the Mandate — a tamper-evident, cryptographically signed verifiable digital credential that binds a user's instruction to a transaction:
- Intent Mandate — captures what the user asked for ("buy white running shoes under EUR 120"), the auditable context for everything that follows.
- Cart Mandate — the user's signed approval of a specific cart: exact items and price, so what you saw is what you paid.
- Payment Mandate — tells the payment network which method and agent credentials are in play.
Two flows are defined: real-time purchases (human present, Intent → Cart → Payment chain) and delegated tasks (human absent — "buy tickets the moment they go on sale" — where a detailed upfront Intent Mandate encodes budget, timing, and constraints). AP2 ships as an extension to the A2A protocol and composes with MCP — for the agent-side plumbing, see our piece on agentic workflows and MCP. Cards are supported today; real-time bank transfers and digital currencies are on the roadmap via extensions.
x402: Payments at the HTTP Layer
x402, built by Coinbase and now stewarded by a foundation co-founded with Cloudflare, revives the long-dormant HTTP 402 "Payment Required" status code. The flow is deliberately minimal: a client requests a resource, the server answers 402 with machine-readable payment requirements, the client signs a stablecoin payment (USDC, typically on Base), and a facilitator verifies and settles it on-chain — usually inside a second, with fees low enough for micropayments. That turns pay-per-request into a first-class API model: per-call data access, per-inference compute, per-crawl content licensing — no accounts, no API keys, no invoicing.
Two design choices matter beyond crypto circles. First, x402 is a settlement rail, not a commerce framework — it says nothing about carts or consent, which is why it can plug into protocols that do. Second, it already ships as the stablecoin extension inside AP2 (the a2a-x402 spec embeds its payment payloads in AP2 Cart and Payment Mandates, in both standalone and embedded flows), so "AP2 vs x402" is largely a false dichotomy. An x402 "bazaar" adds service discovery — agents can find and pay new endpoints without manual integration.
ACP: The Checkout Experience
ACP, built by Stripe with OpenAI and open-sourced under Apache 2.0, powers Instant Checkout in ChatGPT — live since September 2025 with Etsy sellers and Shopify merchants. Where AP2 standardises proof of intent, ACP standardises the order hand-off: the agent collects the buyer's payment via a shared/delegated payment token, passes it to the merchant, and the merchant — who stays merchant of record — processes, fulfils, and owns the customer relationship through its existing stack. ACP is the most production-deployed of the three today precisely because it is the narrowest: it maps agentic checkout onto card rails merchants already run.
How the Three Fit Together
- AP2 = the consent layer — verifiable mandates proving what the user authorized, agnostic to how money moves.
- ACP = the checkout layer — how an agent completes a purchase with a merchant on existing rails.
- x402 = the settlement layer — programmatic stablecoin payment for machine-to-machine micropayments, and AP2's crypto rail.
The composition is already happening in the specs: an agent talks commerce via AP2, presents an Intent Mandate, and settles through an x402 extension — or completes a merchant checkout via ACP on cards. For EU readers, the adjacent work is familiar: mandates are machine-executable evidence of consent in the PSD2 sense, and stablecoin settlement in Europe runs into MiCA's e-money-token regime — the same regulatory boxes we mapped in our asset tokenization explainer and DORA for crypto piece. Where payments touch production networks, Stellar's anchor model is the closest working analogue for regulated on/off-ramps.
What Still Has to Be Solved
Three gaps remain open across all three protocols. Identity: mandates sign intent, but binding an agent instance to an accountable user — "agents that sign in as themselves" — is where MCP's auth roadmap and verifiable credentials converge. Disputes: card-network chargeback rules and PSD2 refund rights were drafted for human-initiated transactions; mapping them onto delegated Intent Mandates is policy work, not code. And interop breadth: AP2 leads on partners, ACP on live volume, x402 on machine-native design — the winner is likely a stack, not a protocol.
Frequently Asked Questions
Do AP2, x402, and ACP compete?
Partly, but they target different layers: ACP standardises agentic checkout, AP2 standardises verifiable consent, and x402 standardises programmatic settlement. x402 already ships as the stablecoin extension inside AP2 — expect composition more than a single winner.
Can agents actually pay in crypto today?
Yes — x402 settles USDC payments over HTTP right now, and the a2a-x402 spec makes it an AP2 payment method. In the EU, euro-denominated flows engage MiCA's e-money-token rules, so issuer licensing matters on both sides of the transaction.
Who is liable when an agent buys the wrong thing?
AP2's mandate chain exists to answer that question — a signed Cart Mandate is non-repudiable proof of what was approved. But card-network chargeback rules and EU payment-refund law still assume human initiation, so treat mandate evidence as necessary, not yet sufficient, in disputes.
Does this work for B2B procurement?
That is the designed-for case: delegated Intent Mandates encode budget ceilings, conditions, and time windows upfront, giving finance teams an auditable authorization trail for autonomous purchasing — stronger control than a shared corporate card, not weaker.
Which protocol should we build on first?
Match the layer to the product: selling into agent-driven shopping → ACP; exposing APIs or content to paying agents → x402; building an agent that transacts on a user's behalf → AP2, because mandates are the only artifact that travels across all three.
