AP2 (Agent Payments Protocol) — Definition
AP2 is an open protocol that gives an AI agent a signed, verifiable permission slip from a human before it can spend that human’s money. Google announced it on 16 September 2025 with more than sixty payment and technology partners, including Mastercard, PayPal, American Express, Adyen, Coinbase and Worldpay. It is not a payment rail. It is an authorization layer that travels with a transaction, so the merchant and the payment network can check that a real person actually approved this purchase — and not merely that the agent holds a credential.
Cryptographic proof of authority for agent purchases: the shopper signs what they want, the agent cannot exceed it, and every party downstream can verify that.
Mandates
The core object is a mandate: a signed statement carried as a W3C Verifiable Credential. The published flow separates what the user asked for from what the agent assembled from what is finally charged.
| Mandate | Signed by | Carries |
|---|---|---|
| Intent | The shopper, in their client | Scope and constraints: the item, the ceiling price, delivery, validity period |
| Cart | The merchant or merchant-side agent | A specific SKU, price, tax, shipping and total, bound to the Intent |
| Payment | The paying leg | Amount, funding instrument reference, and a hash of the matched Intent and Cart |
Later documentation describes a Checkout Mandate and a Payment Mandate, each with an open and a closed state, rather than three separately named mandates. The mechanism is the same — constraints signed first, a concrete cart bound to them second — but if you are quoting field names, read them off the specification version you are implementing, not off an article.
Versions and governance
- v0.1 (2025) — roles and the chain of signed mandates, focused on human-present flows where the shopper approves in session.
- v0.2 (April 2026) — human-not-present flows for autonomous purchases, plus replay-attack defences.
- May 2026 — AP2 was contributed to the FIDO Alliance, alongside Mastercard’s Verifiable Intent work, moving governance away from a single vendor.
Where AP2 sits next to UCP, ACP and MCP
| Layer | Question it answers | Protocol |
|---|---|---|
| Discovery and transaction | What does this business sell, and how do I buy it? | UCP, ACP |
| Transport | How does the agent call the store? | REST, MCP, A2A |
| Payment authorization | Did a human really approve this, and for how much? | AP2 |
Google describes UCP as compatible with AP2 for agentic payments. ACP takes a different route to the same problem, with its own delegated-payment and payment-handler design. They are layers, not rivals — a purchase can be discovered over UCP, carried over MCP and authorized under AP2.
What a merchant actually has to build
AP2 lives between the agent, the card network and the payment provider. For most stores the honest answer is that your PSP and the networks implement it, and your job is upstream: pick a merchant-of-record path (UCP or ACP), publish accurate product data, and return totals that are correct to the cent so a Cart Mandate can be bound to them.
That last point is where agentic purchases actually fail on Magento. A mandate binds a specific total. If your cart recalculates tax or shipping after the agent has read the total, the signed cart and the charged amount no longer match and the transaction has to be rebuilt. Deterministic totals matter more than protocol support.
The risk nobody has closed
Security analysis of AP2 makes a point worth repeating to merchants: the mandates are signed, but the context that produced them is not. Catalogue data, tool results and agent-to-agent messages sit outside the signature. An attacker does not need to forge a mandate — manipulating what the agent reads can produce a validly signed mandate for the wrong thing.
For a store, the practical reading is that your catalogue output is now part of a payment security surface. Wrong prices, stale availability and injected text in product descriptions are no longer only a merchandising problem.
Questions
- What is AP2?
- The Agent Payments Protocol, an open standard announced by Google in September 2025, in which an AI agent carries cryptographically signed mandates proving a human authorized a specific purchase under specific limits. It is an authorization layer rather than a payment rail.
- Does a Magento store have to implement AP2?
- Generally no. AP2 is implemented by payment networks and providers. A merchant’s part is choosing a commerce protocol path such as UCP or ACP, publishing accurate product data, and returning deterministic totals that a signed cart can be bound to.
- Is AP2 a competitor to UCP or ACP?
- No. UCP and ACP define how an agent discovers and transacts with a business; AP2 defines how the payment leg is authorized. Google describes UCP as compatible with AP2.
- Who governs AP2 now?
- It was contributed to the FIDO Alliance in May 2026, together with Mastercard’s Verifiable Intent work, which moves it from single-vendor stewardship toward industry governance.
- Does AP2 stop an agent buying the wrong thing?
- Only within the signed limits. Published security analysis notes that the context feeding the agent — catalogue data, tool results, messages between agents — sits outside the signature, so a manipulated context can still produce a validly signed mandate for an unintended purchase.