--- title: "AP2 vs ACP vs x402: agent payment protocols compared" description: "AP2, ACP, and x402 each verify that an AI agent had permission to spend. Here is what every protocol covers, who backs it, and the reconciliation gap none of them close." date: "2026-09-02" category: "payments" faq: - q: "What is the difference between AP2, ACP, and x402?" a: "AP2 is Google's protocol, now co-governed with the FIDO Alliance, and it wraps a purchase in a chain of signed mandates so an auditor can check the charge against what a person actually approved. ACP comes from OpenAI and Stripe and is built around checkout: an agent negotiates a cart, then a payment token takes over and Stripe settles it. x402, from Coinbase and now managed by a Linux Foundation project with Visa, Mastercard, and Ripple involved, drops the signed-approval step entirely and lets an agent pay per HTTP request in stablecoin. The card networks run their own agent-token schemes alongside all three. Every one of them answers the same question: was the agent allowed to spend." - q: "Does x402's transaction volume represent real commerce?" a: "Not mostly, no. By April 2026 the network had processed something like 165 million cumulative transactions worth $50 million, but zoom into a single 30-day window in July 2026 and it was 75 million transactions for just $24 million, most of it fractional-cent bot activity rather than anything resembling a merchant sale. One [tracker puts](https://www.coindesk.com/markets/2026/03/11/coinbase-backed-ai-payments-protocol-wants-to-fix-micropayment-but-demand-is-just-not-there-yet) genuine, non-gamified volume at around $28,000 a day." - q: "What happens if an AI agent makes an authorized but bad purchase?" a: "No framework covers it yet. Card-network fraud rules and mandate signatures handle spend the agent was never allowed to make. Neither one addresses a purchase that was fully authorized, correctly signed, and still wrong: the wrong dates, the wrong quantity, a rounding error nobody caught. EMVCo has stood up a task force on agentic payments and FDATA published a governance white paper on the exact gap in July 2026. Neither has an answer yet." - q: "Can a stablecoin payment made by an AI agent be reversed?" a: "No. Card networks can freeze or unwind a transaction while a dispute plays out, because a bank sits in the middle of the rail. Stablecoin settlement has no equivalent intermediary: once a transaction confirms on-chain, it stands. That finality is a non-issue for small, well-defined purchases like an API call or a slice of compute. It matters a great deal once real judgment is involved, which means the review has to happen before the agent submits the transaction, not after." - q: "What should a company building agent payments do now?" a: "Split the agent's negotiation step from the actual settlement call, put spend limits in the API layer instead of a system prompt, and pair every tool call with its settlement receipt so idempotency keys and webhook confirmations become the audit trail finance can actually use. That holds regardless of which protocol ends up dominant." - q: "What is MCP's role in agent payments?" a: "MCP is already how an agent discovers and calls tools, so payment does not need a separate channel. It can register as one more tool inside that interface, exposed and negotiated the same way any other capability is, which gives spend limits and receipt logging one obvious place to live instead of a side system someone has to remember to check." --- Three protocols now compete to answer the same question for AI agents that spend money: AP2 (Google, co-governed with the FIDO Alliance), ACP (OpenAI and Stripe), and x402 (Coinbase, under a Linux Foundation project). Each one confirms an agent had permission to make a purchase. None of them reconcile what actually got spent once the transaction clears, and because stablecoin settlement cannot be undone, that gap turns into an operational problem the moment real money is involved. ## What AP2, ACP, and x402 actually do | Protocol | Backed by | What it checks | Settlement rail | |---|---|---|---| | AP2 (Agent Payments Protocol) | Google, [FIDO Alliance](https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/), Mastercard | A chain of signed mandates (Intent, Cart, Payment) proving what a human approved | Card or stablecoin, protocol-agnostic | | ACP (Agentic Commerce Protocol) | [OpenAI, Stripe](https://github.com/agentic-commerce-protocol) | A negotiated cart handed off to a payment token | Card, processed by Stripe | | x402 | Coinbase, [Linux Foundation, Visa, Mastercard, Ripple](https://www.coindesk.com/tech/2026/07/15/visa-mastercard-and-ripple-join-the-standard-letting-ai-agents-pay-in-stablecoins) | Nothing beyond payment itself, no signed approval step | Stablecoin, per HTTP request | AP2's mandates are verifiable credentials Google donated to the FIDO Alliance in April 2026 to make governance vendor-neutral; Mastercard folded in its own Verifiable Intent framework the same month. ACP stays narrow by design, aimed at checkout rather than general agent spend. x402 skips signed approval entirely in favor of speed, and now runs under a [Linux Foundation project backed by Visa, Mastercard, and Ripple](https://www.coindesk.com/tech/2026/07/15/visa-mastercard-and-ripple-join-the-standard-letting-ai-agents-pay-in-stablecoins). Visa's Trusted Agent Protocol and Mastercard's Agent Pay run parallel agent-token schemes on the card rails, and both networks [say they intend to converge](https://www.digitalcommerce360.com/2026/04/02/visa-mastercard-in-agentic-commerce/) toward supporting whichever protocols win adoption. Four mechanisms, one shared checkpoint: authorization. None of them tell you whether thousands of agent transactions still line up with a budget after the fact, flag the ones that broke policy, or produce a record an auditor would accept. Reconciliation is a different job none of the three set out to do, and a finance team ends up building it themselves: matching every agent transaction to a policy, catching what slipped through, and keeping a record that survives an audit. That work looks a lot like what a [stablecoin API](/resources/more/what-is-a-stablecoin-api) already handles for wallets, conversion, and compliance in one integration, just applied to agent spend instead of human-initiated transfers. EMVCo [formed an agentic-payments task force](https://www.emvco.com/news/emvco-working-on-how-global-specifications-can-support-agentic-payments/) in late 2025 to look at the gap, and [FDATA's July 2026 white paper](https://fdata.global/fdata-releases-white-paper-on-agentic-fintech-and-write-access-calling-for-a-principles-based-framework-for-the-next-generation-of-open-finance/) argues the hard problem stopped being authorization some time ago. ## Is the agent-payment volume real yet? x402's headline numbers [look like a working market](https://www.coindesk.com/business/2026/08/23/crypto-s-next-billion-users-might-be-ai-agents-and-they-re-paying-with-stablecoins): about 165 million cumulative transactions and $50 million by April 2026. Narrow the window and the picture changes. Across the 30 days ending July 2026, the network processed roughly 75 million transactions but only [$24 million in real value](https://www.coindesk.com/tech/2026/07/15/visa-mastercard-and-ripple-join-the-standard-letting-ai-agents-pay-in-stablecoins), most of it sub-dollar bot traffic. One [tracker's estimate](https://www.coindesk.com/markets/2026/03/11/coinbase-backed-ai-payments-protocol-wants-to-fix-micropayment-but-demand-is-just-not-there-yet) of non-gamified activity lands at around $28,000 a day, and a separate [calculation](https://en.cryptonomist.ch/2026/08/25/agentic-stablecoin-payments-record/) puts agent-to-agent stablecoin volume at roughly 0.0001 percent of total annual stablecoin volume, a figure worth treating as directional since nobody agrees yet on what counts as an "agent" transaction. That is thin ground to build a back office around a single protocol. Gartner expects [more than 40 percent of agentic-AI projects to be canceled by the end of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), citing cost, unclear value, and missing risk controls. ## What ChatGPT Instant Checkout showed about authorization alone OpenAI launched [ChatGPT Instant Checkout](https://www.cnbc.com/2025/09/29/chatgpt-instant-checkout-etsy-shopify.html) alongside ACP in September 2025, starting with Etsy and then Shopify merchants including Glossier and SKIMS. By [March 2026 it was effectively shelved](https://www.cnbc.com/2026/03/24/openai-revamps-shopping-experience-in-chatgpt-after-instant-checkout.html): fewer than fifteen of Shopify's millions of merchants ever went live, and checkout moved back to the merchant's own site. The mandate signing never broke; stale inventory between the agent's view of a catalog and actual merchant stock, plus sales tax across jurisdictions, is what killed it. A signed mandate confirms an agent was cleared to buy something. It says nothing about whether that thing is in stock, priced correctly, or taxed right, a different failure mode from the reconciliation gap but the same root cause: these protocols check authorization and stop there. ## The authorized-but-wrong purchase has no playbook Fraud already has a playbook. Amex's [Agent Purchase Protection](https://www.worldpay.com/en/insights/articles/agentic-commerce-liability-is-still-being-written) shifts liability to Amex when a registered agent's purchase turns out fraudulent, Mastercard's Agent Pay tokens fall under existing card dispute rules, and Visa still calls its own liability terms early and evolving. None of that covers a purchase that was authorized and simply wrong: an agent books the wrong dates, or orders five hundred units instead of fifty because of a rounding error in an agent-to-agent negotiation. The signature checks out, nobody committed fraud, and the human is left holding a purchase that executed exactly as instructed. Both EMVCo's task force and FDATA's paper flag this as an open question, and neither has published a fix. A card purchase like that can still be charged back, since the rail is reversible. Stablecoin settlement removes that safety net: once the transaction confirms on-chain, it is done. Most of what agents buy today, an API call, a unit of compute, needs a dispute window about as much as a vending machine does. But it means the call on whether a purchase should happen has to be correct before settlement, since there is no fixing it after. ## What to build now, regardless of which protocol wins Four practices hold up no matter which of AP2, ACP, or x402 ends up dominant in a given [cross-border agent-payment integration](https://www.blindpay.com/global-payments): - **Separate negotiation from settlement.** Let the agent reason and assemble a cart with whichever protocol it prefers, then route the payment through a narrow, auditable API surface that does not care which negotiation produced it. - **Put spend policy in the API, not the prompt.** A system prompt capping spend is a suggestion an agent can lose track of three tool calls later. A server-side limit on amount, currency, counterparty, or category does not have that failure mode. - **Pair every tool call with its settlement receipt.** An idempotency key on the request and a webhook confirmation, both tied to the call that triggered them, let a finance team open one row per transaction and see what started it, what closed it, and whether it passed policy. Without that link, an agent firing the same purchase twice after a timeout looks identical to two legitimate ones, and nobody notices until the statement arrives. - **Put payment where the agent already looks for tools.** MCP's [July 2026 spec update](https://blog.modelcontextprotocol.io/posts/2026-07-28/) added a formal extensions framework, so a payment capability can be exposed as one more discoverable tool instead of a bolt-on. The same discipline, decoupled settlement, server-side policy, a receipt trail, is also what a solid [stablecoin payments](/resources/more/stablecoin-payments-guide) setup needs for human-initiated transfers, which is why agent and human flows can share one infrastructure instead of separate stacks. ## Where BlindPay fits BlindPay's MCP server and Agent Skills expose payments as tools an agent calls directly: quotes, payouts, [virtual accounts](https://www.blindpay.com/virtual-accounts), and webhooks, with idempotency and [reconciliation](https://www.blindpay.com/compliance) built underneath instead of left for someone to bolt on later. Cross-border transfers that need wire delivery settle as SWIFT (POBO/COBO), with UETR tracking and MT103 confirmations, and corridors like [USDC to BRL](https://www.blindpay.com/usdc-to-brl) settle the same whether a human or an agent initiated the payment. The [getting started docs](https://www.blindpay.com/docs/getting-started/overview) cover the API surface. [Talk to the team](https://www.blindpay.com/contact) if you are building the reconciliation layer for agent payments and want it wired to settlement instead of stapled on after.