UCP and ACP are about discovery and checkout: how an agent finds a merchant and completes a purchase. AP2 is about something different: proving, cryptographically, that a real person authorized that specific purchase. A merchant can implement UCP or ACP without AP2, and AP2 is not something most merchants build themselves. If you were expecting a manifest file or an admin toggle the way UCP works, that is not what this guide covers, because that is not what AP2 is.
What AP2 actually is
Google announced the Agent Payments Protocol on September 16, 2025, per its own Cloud Blog post, as an open protocol developed with more than 60 payments and technology companies, including Adyen, American Express, Coinbase, Etsy, Mastercard, PayPal, Salesforce, and Worldpay. Google describes it as an extension of the Agent2Agent (A2A) protocol and the Model Context Protocol (MCP), establishing a payment-agnostic framework so agents, merchants, and payment providers can transact with confidence.
The problem AP2 is built to solve is specific: today's payment systems assume a human is directly clicking "buy." An AI agent initiating a payment on someone's behalf breaks that assumption, and raises three concrete questions Google's announcement names directly: proving a user gave an agent authority for a specific purchase (authorization), confirming an agent's request actually reflects what the user wanted (authenticity), and determining who is accountable if something goes wrong (accountability).
How it actually works: the mandate chain
AP2 answers those questions using Mandates: tamper-proof, cryptographically signed digital contracts, backed by W3C Verifiable Credentials, that form an auditable chain of evidence for a transaction. Per Google's announcement, that chain runs through three mandates:
Captures what the user actually asked for, such as "find me white running shoes, under $150." For a fully delegated task like "buy concert tickets the moment they go on sale," this mandate is signed upfront with explicit constraints, price limits and timing included.
Created once the agent presents specific items and the user approves them (or, in a delegated task, once the agent's own conditions are met). This locks in the exact items and price, so what was approved is what gets charged.
Links the user's payment method to the verified Cart Mandate, finalizing the leg between agent and payment network with a record of what was authorized and what is being charged.
Google's announcement frames this as covering two shopping patterns: real-time purchases, where a human is present to approve the cart, and delegated tasks, where a human sets conditions in advance and the agent acts without them present at the moment of purchase.
April 2026: AP2 moves to the FIDO Alliance
Per Google's own blog, on April 28, 2026, Google donated AP2 to the FIDO Alliance, the nonprofit standards body behind passkeys and FIDO2, to keep the protocol platform-agnostic and community-governed rather than Google-controlled. The FIDO Alliance's own announcement confirms this and describes forming an Agentic Authentication Technical Working Group and a Payments Technical Working Group to continue developing the standard, with Mastercard separately contributing a compatible "Verifiable Intent" framework.
Alongside the donation, Google shipped AP2 v0.2 on GitHub the same day, adding support for what it calls "Human Not Present" payments: agents executing a pre-authorized purchase, like securing limited-release tickets the moment they go on sale, without a person actively present for that specific transaction.
How AP2 relates to UCP and ACP
This is the part most coverage gets muddled. UCP and ACP are commerce protocols: they define how an agent discovers a merchant's catalog and completes a checkout. AP2 is a payments protocol: it defines how the resulting payment gets cryptographically authorized. They are not three competing ways to do the same thing, they operate at different layers, and per Google's own framing, AP2 was built to extend and interoperate with the discovery and checkout layer rather than to replace it.
| UCP | ACP | AP2 | |
|---|---|---|---|
| What it governs | Discovery: how an agent finds a merchant's catalog and services | Checkout: how an agent completes a purchase against a merchant | Payment authorization: proving a person authorized the specific charge |
| Led by | Google, with Shopify, Etsy, Wayfair, Target, and Walmart | Stripe, OpenAI, and Meta | Originally Google; now governed by the FIDO Alliance |
| Announced | January 11, 2026 | September 29, 2025 | September 16, 2025 |
| What a merchant does | Publishes a manifest at /.well-known/ucp | Implements a checkout endpoint against the ACP spec | Typically nothing directly; support comes through payment processors |
Because they solve different problems, a single purchase can in principle use more than one of these at once: an agent could discover a merchant through UCP, complete checkout through ACP, and have the payment itself authorized through an AP2 mandate. See our guides to UCP and ACP for how each of those actually works.
What this means for merchants
Unlike UCP, there is no merchant-facing manifest or admin toggle for AP2. AP2 mostly operates between agent platforms, payment processors, and card networks, below the layer a typical merchant interacts with directly. In practice, adopting AP2 usually means your existing payment processor, PayPal, Adyen, or another provider on the partner list, has built AP2 support into its own infrastructure, and a merchant already using that processor inherits it rather than implementing it themselves. Per PayPal's own developer blog, this is exactly how PayPal has framed its AP2 support: enabling "PayPal merchants and partners to accept agent-driven payments" through PayPal's existing rails, not a separate integration merchants build. See our PayPal and Adyen guides for how each has positioned its AP2 support specifically.
Checking for UCP specifically?
AP2 is about payment authorization, not manifest discovery. If your goal is UCP compliance, check whether your site actually publishes a valid manifest.
Frequently asked questions
No. UCP and ACP are commerce protocols that govern discovery and checkout. AP2 is a payments protocol that governs how the resulting payment is cryptographically authorized. They operate at different layers and are designed to interoperate rather than compete.
Usually not directly. Unlike UCP, there is no merchant-facing manifest or toggle for AP2. It typically comes through your existing payment processor, if PayPal, Adyen, or another provider on AP2's partner list supports it, a merchant already using that processor generally inherits the support rather than integrating it separately.
Tamper-proof, cryptographically signed digital contracts that form a chain of evidence for a transaction: an Intent Mandate capturing what the user wants, a Cart Mandate locking in the exact items and price once approved, and a Payment Mandate linking the payment method to that approved cart.
No. Google donated AP2 to the FIDO Alliance on April 28, 2026, to keep it platform-agnostic and community-governed. Google shipped AP2 v0.2 the same day, adding support for 'Human Not Present' payments.
Yes. Per Google's announcement, AP2 is payment-method agnostic and supports stablecoins and real-time bank transfers alongside cards, with Coinbase and MetaMask among the original partners supporting stablecoin payment rails.
Sources
- Google Cloud Blog, "Announcing Agent Payments Protocol (AP2)"
- Google Blog, "Google donates Agent Payments Protocol to FIDO Alliance"
- FIDO Alliance, "Google donates Agent Payments Protocol to FIDO Alliance"
- PayPal Developer Community Blog, "Agent Payments Protocol: Building Verifiable Trust for Agentic Commerce"
- AP2 Protocol, official specification