Picture the first chargeback of the agentic era. Your shopping agent buys a pair of running shoes overnight, but they arrive a size too small, and you dispute the charge. The card network opens the case and finds nothing it recognizes: no human at a browser, no device fingerprint captured at checkout, no session where a person clicked "Pay." Just an API call from software acting on your behalf. Who authorized it? Did the software buy what you actually asked for? And if it didn't, who eats the loss?
That gap is the real problem the Agent Payments Protocol (AP2) sets out to close. Google announced it on September 16, 2025, alongside more than 60 organizations — Mastercard, American Express, PayPal, Adyen, Worldpay, Coinbase, and the Ethereum Foundation among them. It's easy to read the headline as "a way for agents to pay." It's more precise to read it as an accountability protocol that happens to settle money. The payment is the easy part; the hard part is proving intent.
The question card networks can't answer
Existing payment rails assume a human is present. Fraud models lean on signals that stop existing the moment an agent takes over: a physical device, a checkout session, behavioral biometrics. When an autonomous agent transacts, three questions have no cryptographic answer:
- Authorization — did the user actually grant this agent authority to make this purchase?
- Authenticity — does the agent's request faithfully reflect what the user asked for?
- Accountability — if the transaction is wrong or fraudulent, who is responsible?
You can't patch these at the API-key layer. An API key proves a piece of software is allowed to call an endpoint. It says nothing about whether the human behind it agreed to spend $180 on grey running shoes. AP2 sits a layer above that, capturing and verifying intent as a first-class, signed artifact.
Mandates: turning intent into a signed object
The core primitive is the Mandate — a tamper-proof, cryptographically signed digital contract carried as a W3C Verifiable Credential. Instead of trusting an agent's word, every party in the flow gets a signed record they can independently verify. AP2 breaks a purchase into three of them:
- Intent Mandate — what the user wants, and the constraints around it. "Buy white or grey running shoes, size 10, under $150, deliver to my saved address."
- Cart Mandate — what the agent actually assembled, signed by the merchant side. It binds a specific SKU, price, tax, shipping, and total to the intent. This is the "what you see is what you pay for" guarantee.
- Payment Mandate — a separate signal to the payment network and the issuing bank that an AI agent was involved, giving them the visibility they need to price risk.
That third one is the quiet clever bit. The Intent and Cart Mandates are about user authorization; the Payment Mandate exists purely so the network and the bank know an agent executed the transaction and can treat it accordingly. It's regulatory and risk visibility, not consent.
Structurally, an Intent Mandate is a plain Verifiable Credential. The shape is roughly this — illustrative, not the verbatim spec:
{
"@context": ["https://www.w3.org/ns/credentials/v2"],
"type": ["VerifiableCredential", "IntentMandate"],
"issuer": "did:example:user-abc",
"credentialSubject": {
"agent": "did:example:shopping-agent-42",
"constraints": {
"item": "running shoes",
"size": 10,
"color": ["white", "grey"],
"maxPrice": { "amount": 150, "currency": "USD" },
"expiresAt": "2025-10-08T00:00:00Z"
}
},
"proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022", "...": "..." }
}
The proof block is what makes it more than JSON. The user's key signs the mandate, so anyone downstream can verify it wasn't altered and can trace it back to the human who issued it. Chain the three together — Intent, then Cart, then Payment — and you get a non-repudiable audit trail. When that chargeback lands, there's now a signed answer to every question the dispute asks.
Where it fits with A2A and MCP
AP2 doesn't replace the protocols you may already be wiring up. It's an extension that builds on the Agent2Agent (A2A) Protocol and the Model Context Protocol (MCP). If MCP is how an agent reaches tools and data, and A2A is how agents talk to each other, AP2 is the payment-and-authorization layer that rides on top of both. It's deliberately payment-agnostic: cards, real-time bank transfers, and stablecoins are all in scope. For crypto specifically, Google worked with Coinbase, MetaMask, and the Ethereum Foundation on the A2A x402 extension, a separate track for agent-to-agent crypto settlement.
Two flows, one chain of evidence
The mandate model bends to cover both cases that matter:
Human present. You're in the loop. The agent presents a cart, the merchant signs it first as a guarantee, and you sign the Cart and Payment Mandates on your own device. You approve the exact terms in real time.
Human absent. This is where delegation gets real. You sign a detailed Intent Mandate up front — price ceiling, timing, conditions — and the agent monitors. "I want this jacket in green, and I'll pay up to 20% more for it." When the conditions are met, the agent generates the Cart Mandate itself and executes, with your earlier signature as the standing authorization.
Both paths converge on the same artifact: a signed Intent → Cart → Payment chain that any party can verify after the fact.
What to build now
The specification, documentation, and reference implementations are public at goo.gle/ap2, and the protocol is being developed openly through standards bodies rather than as a closed Google product. That's the signal worth acting on.
If you're building agents that will eventually move money, stop treating authorization as an API-key concern and start modeling intent as data today. Capture the user's constraints as a structured, signable object at the moment you receive them — price limits, expiry, allowed variants — even before you have a payment rail to attach it to. That single design choice is what makes an agent's spending auditable instead of a black box, and it's the part AP2 can't hand you. The protocol will settle the payment; proving your agent bought what the human actually asked for is the work that starts in your own code.
Sources: Announcing Agent Payments Protocol (AP2) — Google Cloud Blog, AP2 protocol specification (goo.gle/ap2), A2A x402 extension, Google's AP2: A new protocol for AI agent payments — Vellum