Agent Payment Protocols Compared: AP2, x402, and ACP

The moment an AI agent holds a payment credential, the assumption every card network was built on breaks: that a human clicked "buy." Three standards now compete to rebuild that trust for autonomous transactions, and they are not rivals so much as different layers of the same stack. Google's AP2 handles authorization, Coinbase's x402 handles settlement, and the OpenAI and Stripe Agentic Commerce Protocol handles checkout. If you are scoping agent commerce this year, the first decision is not which one to back. It is understanding which problem each one actually solves.

Key takeaways

AP2, x402, and ACP address separate layers: authorization (who approved this and how do we prove it), settlement (how value actually moves), and checkout (how an agent completes a purchase with a merchant).
AP2 uses cryptographically signed mandates to create a non-repudiable audit trail from user intent to final payment, so liability can be assigned when an autonomous purchase goes wrong.
x402 revives the dormant HTTP 402 status code and settles in stablecoins using EIP-3009 gasless authorizations, letting an agent pay per API call in seconds with no account or key.
ACP keeps the merchant as merchant of record and passes a scoped payment token, so businesses accept agent orders without handing checkout control to the agent platform.
The Linux Foundation declared the x402 Foundation operationally live on July 14, 2026 with 40 members including Visa, Mastercard, Stripe, Google, and Coinbase, signaling that the settlement layer is consolidating.
These protocols compose. A production agent might authorize with AP2, check out through ACP, and settle machine-to-machine calls over x402.

What problem do agent payment protocols actually solve?

They solve the collapse of the human-present assumption. Every fraud model, chargeback rule, and 3-D Secure prompt in the card system exists to answer one question at the moment of purchase: is a real person, with authority over this account, choosing to spend this money right now? An autonomous agent removes that person from the loop, and with them the answer.

That leaves three gaps a protocol has to close. Authorization: proving the user actually granted the agent authority to spend, and within what limits. Authenticity: proving the request the merchant sees reflects what the user asked for, not something the agent drifted into or an attacker injected. Accountability: deciding who eats the loss when a transaction is wrong, because "the AI did it" is not a liability model any bank will accept.

The reason there are three protocols and not one is that these gaps live at different altitudes. Authorization is a trust and identity problem. Settlement is a money-movement problem. Checkout is a merchant-integration problem. A senior architect should read the landscape the same way: not as competing products, but as a stack where you may need one layer, or all three.

How does AP2 prove an agent had authority to pay?

AP2 answers authorization with signed mandates: tamper-evident, cryptographically signed digital contracts that record exactly what the user authorized, at each stage of the transaction. Google announced the Agent Payments Protocol on September 16, 2025 with more than 60 partners including Mastercard, American Express, PayPal, Coinbase, and Adyen, and released it as an open specification rather than a product.

The mechanism splits authorization into stages so intent and final commitment are provable separately. An Intent Mandate captures the user's initial instruction and its conditions, for example "buy these concert tickets when they go on sale, up to $150." A Cart Mandate is signed once the agent has assembled the actual items and price, creating an unchangeable record that what the user approved is what gets charged. A payment authorization then binds a specific instrument to that cart. Each is a Verifiable Digital Credential, and the chain of them forms a non-repudiable audit trail from intent to settlement.

That staging is the point. In a human-present flow, the user signs the cart directly. In a human-not-present flow, the user signs an Intent Mandate up front with explicit limits, and the agent generates the Cart Mandate autonomously when its conditions are met, without a second approval. The signatures are what let a bank or merchant reconstruct, after the fact, that the agent stayed inside its grant.

The trade-off a technical leader should note: AP2 is deliberately payment-agnostic and does not move money itself. It rides on top of the Agent2Agent protocol and the Model Context Protocol, and it defers settlement to card rails or to crypto through its x402 extension. You get a rigorous accountability layer, but you still have to choose how value actually moves.

How does x402 let an agent pay over HTTP?

x402 turns payment into a native part of the HTTP request cycle by reviving the 402 "Payment Required" status code that sat unused in the spec for nearly three decades. When an agent requests a paid resource, the server answers with 402 and a header describing the price: the chain in CAIP-2 format, the token contract, the amount in atomic units, and the recipient address. The agent signs an authorization for that amount and retries the request with the signature attached. A facilitator verifies and settles it on chain, and the server returns 200 with the data.

The cryptographic core is EIP-3009, "Transfer With Authorization," a gasless signature standard supported natively by the USDC and EURC stablecoins. Gasless matters here: the agent signs an off-chain authorization rather than submitting and funding its own blockchain transaction, so the facilitator can carry the settlement. The practical result is an agent paying per call in seconds, with no account creation, no API key, and no billing dashboard. The payment receipt itself becomes the access credential.

Coinbase contributed x402 to the Linux Foundation, which declared the x402 Foundation operationally live on July 14, 2026 with 40 member organizations across three tiers, among them Visa, Mastercard, American Express, Stripe, Google, AWS, Shopify, Cloudflare, Circle, and Coinbase. That roster is the signal worth reading: the settlement layer is consolidating under neutral governance rather than fragmenting across vendors.

The constraint is where x402 fits. It excels at machine-to-machine microtransactions, metered APIs, per-inference billing, data feeds priced per query. It does not, on its own, model a shopping cart, a merchant of record, or a consumer dispute process. Settlement today runs primarily on USDC on Coinbase's Base chain, with Solana driving a large share of volume, so backing it also means accepting a stablecoin-and-onchain operational footprint your finance team has to be ready for.

How does ACP keep the merchant in control of checkout?

ACP lets an agent complete a purchase while the business stays the merchant of record and never hands checkout to the agent platform. OpenAI and Stripe co-developed the Agentic Commerce Protocol and released it under Apache 2.0 on September 29, 2025; the two maintain it jointly, with a stable specification dated April 17, 2026.

The design centers on delegated payment. The agent collects the buyer's payment selection and passes the merchant a narrowly scoped token rather than raw card details. The merchant charges that token through any compliant payment service provider, keeping its existing processor, its risk controls, and its direct customer relationship. ACP defines the surrounding pieces too: a checkout API for creating and completing sessions, a product feed so agents can see catalog and availability, and order and authentication flows, with MCP integration in the current spec.

The reason this matters to a merchant is control. In an ACP transaction the business is not reduced to a fulfillment backend behind someone else's storefront; it processes the charge, owns the order, and carries the merchant-of-record obligations it already knows how to handle. The agent brings the buyer and the payment instrument; the merchant runs the sale.

The honest caveat is adoption. ChatGPT's Instant Checkout launched on ACP with Etsy and a set of Shopify brands, and real-world merchant uptake has been slower and narrower than the launch suggested. The protocol and its governance continue, but a leader betting on ACP should scope for a standard that is technically solid and still early in production, not one with ubiquitous merchant support today.

How do AP2, x402, and ACP compare across the stack?

The cleanest way to hold these three in your head is by the layer each one owns, who backs it, and what it settles in. They overlap far less than the shared "agentic payments" label implies.

Dimension	AP2	x402	ACP
Primary layer	Authorization and accountability	Settlement over HTTP	Merchant checkout
Lead backers	Google, plus 60+ payment partners	Coinbase, now Linux Foundation governed	OpenAI and Stripe
Core mechanism	Signed mandates as Verifiable Digital Credentials	HTTP 402 plus EIP-3009 gasless signatures	Scoped payment token to merchant of record
Settles in	Payment-agnostic (cards or crypto)	Stablecoins (USDC, EURC)	Cards and existing PSP rails
Best fit	Delegated, high-value or conditional purchases	Machine-to-machine microtransactions and metered APIs	Consumer purchases from real merchants
Merchant of record	Defined by underlying rail	Not modeled	The merchant, always
Released	September 16, 2025	Foundation live July 14, 2026	September 29, 2025

Read down the "primary layer" row and the picture resolves. AP2 is asking who approved this and how we prove it. x402 is asking how the money moves. ACP is asking how the agent completes a sale with a business that wants to stay a business. None of them fully answers the other two questions.

Do these protocols compete, or compose?

They compose, and the design of AP2 makes that explicit: x402 ships as an AP2 extension for stablecoin settlement, built with Coinbase, the Ethereum Foundation, and MetaMask. A single production transaction can legitimately touch all three layers.

Consider a delegated purchase. The user signs an AP2 Intent Mandate authorizing an agent to book travel under a budget. The agent negotiates a specific itinerary, produces a Cart Mandate the user's earlier grant covers, and completes the consumer purchase through ACP so the airline or hotel stays merchant of record. If part of that workflow calls a paid availability API, the agent settles those metered calls over x402. Authorization, checkout, and machine-to-machine settlement, each handled by the layer built for it.

This is why treating the three as a bake-off leads to the wrong architecture. The real question is which layers your use case touches. A B2B procurement agent buying from known suppliers may need AP2's accountability and little else. A data agent paying for API access needs x402 and nothing resembling a cart. A consumer shopping assistant needs ACP for the storefront and AP2 underneath if you want provable authorization. The overlap between the three is small enough that "which one" is usually the wrong framing; "which combination" is the right one.

What should a technical leader watch before committing?

Watch three things: where liability lands, how these protocols intersect prompt injection, and whether the settlement rail matches your finance operation. Each is a place where an agent payment system fails in production rather than in a demo.

Liability first. AP2's mandate trail is designed to make disputes resolvable, but the assignment of loss between user, agent operator, merchant, and network is still being worked out by the same institutions writing the protocols. Signed mandates give you evidence; they do not by themselves give you a chargeback framework. Treat the accountability model as a live contract question, not a solved one.

Second, the attack surface changes shape. An agent that can spend is an agent worth manipulating, and a malicious product page or tool response that pushes an agent toward an unwanted purchase is a payment exploit, not just a content one. The mandate and scoped-token designs limit blast radius by construction, but they assume the agent's own reasoning stayed clean. Pair any spending agent with the controls in defending tool-using agents against prompt injection, and enforce hard budget and scope limits at the identity layer described in isolating agents with scoped identities.

Third, match the rail to your books. x402's stablecoin settlement is fast and elegant for machine-to-machine flows, but USDC on Base or Solana is an operational reality your treasury and compliance functions have to accept, not an implementation detail. ACP and card-based AP2 flows keep you on familiar rails your finance team already reconciles. The right choice is the one your organization can actually operate, audit, and defend, which is a different test than which protocol reads best on paper.

The strategic read is that agent commerce is standardizing into a layered stack faster than most enterprises are ready to build on it. The teams that will move first are the ones that already treat authorization, settlement, and checkout as distinct problems, because that is exactly how these protocols have divided the work. For a wider view of what changes when agents hold budgets, see what autonomous spending agents signal for guardrails.