AP2 (Agent Payments Protocol) is Google's open standard for letting an AI agent pay on a person's behalf while proving the person authorised it. Before an agent spends, the human signs a tamper-proof digital contract — a Mandate — recording exactly what was approved. A merchant or bank can then verify, cryptographically, that the payment reflects real human intent, not an agent acting alone. Google announced AP2 in September 2025 with more than 60 payment and commerce partners, and built it to work across cards, bank transfers, and stablecoins.
This piece explains what AP2 is, the problem it solves, how its three Mandates work, and where it sits relative to the Agentic Commerce Protocol and x402. Volatile specifics — partners, adoption, rail mix — are dated and attributed; the durable idea is a signed proof of human authorisation that travels with an agent's payment.
What problem does AP2 solve?
AP2 solves the trust gap that opens the moment an agent, not a person, initiates a payment. Card networks, banks, and merchants have decades of machinery built around a human clicking "buy." When a shopper agent pays instead, three questions have no built-in answer, and Google frames AP2 around exactly these three:
- Authorisation — did the user actually authorise this specific purchase, or is the agent acting beyond what it was told?
- Authenticity — can the merchant trust that the agent's request reflects the user's genuine intent, not a misunderstanding or a hallucination?
- Accountability — if a transaction is wrong or fraudulent, who is responsible, and what evidence settles the dispute?
Without a shared answer, every party has to either block agent payments or accept unpriced risk. AP2's response is to attach cryptographic proof of authorisation to the payment itself, so the answer travels with the transaction.
How do AP2's three Mandates work?
AP2 works through three signed digital contracts called Mandates, each carried as a W3C Verifiable Credential — a tamper-proof, cryptographically signed record. Together they build a non-repudiable audit trail from the user's instruction to the final charge.
| Mandate | What it captures | Signed by |
|---|---|---|
| Intent Mandate | The rules of engagement — price limits, timing, and conditions — that let an agent act when the user is away | The user, up front |
| Cart Mandate | The exact items, prices, and details of a specific order, locked as an unchangeable record | The user (or auto-generated under a valid Intent Mandate) |
| Payment Mandate | A signal to the network and bank that an AI agent initiated the transaction, for risk visibility | The agent, linked to the Cart |
Source: Google Cloud AP2 announcement and protocol documentation, September 2025. The Mandates chain together so that what the user authorised, what the agent selected, and what was charged all reconcile — and any mismatch is visible.
What is the difference between a human-present and a delegated payment?
The Mandate you start with depends on whether the person is there when the purchase happens.
- Human-present (real-time). The agent assembles a cart, the merchant cryptographically signs it, and the user gives final approval — producing a Cart Mandate the moment they say yes. This is the "buy these now" case, with the person in the loop.
- Human-not-present (delegated). The user signs an Intent Mandate in advance with explicit parameters ("buy the tickets the instant they drop, under $400"). When the conditions are met, the agent auto-generates a Cart Mandate under that authority — no further approval needed, because the boundary was pre-signed.
AP2's insight is that "the user approved this" should be a signed artefact that travels with the payment — not a claim the agent makes about itself.
Both paths end in the same place: a verifiable record tying the charge back to something the human actually signed. The delegated path is what makes genuinely autonomous agentic commerce safe to underwrite, because the agent's freedom is bounded by a contract the user set.
How does AP2 relate to A2A, MCP, and x402?
AP2 does not stand alone; it extends protocols agents already use. It builds on the Agent2Agent (A2A) protocol and Anthropic's Model Context Protocol (MCP), adding the payments-authorisation layer those standards lack. Where MCP connects an agent to tools and data and A2A lets agents coordinate, AP2 governs the moment money moves.
For settlement, AP2 is rail-agnostic. It handles cards and bank transfers directly, and it reaches stablecoins and crypto through the A2A x402 extension — the same x402 payment-request standard Google developed for this with Coinbase, the Ethereum Foundation, and MetaMask. In stack terms: AP2 proves the authorisation, x402 can carry the payment request for the crypto path, and a card network or blockchain does the actual settling.
Where does AP2 sit next to ACP and the payment rails?
At the authorisation layer, distinct from checkout orchestration and from the rails. It helps to separate the stack an agent purchase moves through:
| Layer | Example | Job |
|---|---|---|
| Discovery / being chosen | Answer-engine optimisation | Whether an agent surfaces and picks your product at all |
| Checkout orchestration | ACP (OpenAI + Stripe) | Completing an order inside an assistant like ChatGPT |
| Payment authorisation | AP2 (Google) | Proving a human authorised what the agent pays for |
| Payment request | x402 | The HTTP handshake that asks for, and confirms, payment |
| Settlement rail | Cards or stablecoins | Actually moving the money |
These are complementary layers, not competitors. A single agent purchase could be discovered through an answer engine, orchestrated through a checkout standard, authorised through AP2, and settled on a card or a stablecoin. As of mid-2026 none of these standards has converged into a single winner, and a brand does not need to bet on one — the transaction layer is being built to be plural. For a side-by-side of the three standards, see ACP vs AP2 vs x402.
What does AP2 mean if you sell online?
Mostly, it is infrastructure you will accept rather than build by hand — but it lowers a real barrier. By giving banks and merchants a verifiable answer to "did the human authorise this?", AP2 makes them more willing to let agents transact at all, which enlarges the pool of purchases an agent can complete on your behalf. That is upside for any brand ready to be bought by machines, and it rides on the same checkout-readiness groundwork agentic commerce already asks for.
But AP2 settles how an agent pays and proves it was allowed to — not whether it picks you. That decision happens a layer up, at discovery, and it turns on whether an answer engine surfaces and recommends your product in the first place. That is exactly what Buffy Intel measures, snapshot over snapshot. Questions: [email protected].