AP2: the receipt that says a human said yes
x402 solves how an agent pays. AP2 solves the harder question underneath it: when software spends your money, what evidence exists that you actually agreed — and to what, exactly, and up to how much.
The problem it exists for
Give an agent a payment method and you have created a buyer that never sleeps, can't be asked what it was thinking, and leaves no trail a dispute process can read. If a charge is contested later, "the agent did it" is not an answer anyone can act on.
AP2 — the Agent Payments Protocol, developed by Google and now being standardised through the FIDO Alliance's agentic authentication and payments working groups — attaches a cryptographic chain of custody to the whole transaction. It's an extension to Agent2Agent (A2A) and the Universal Commerce Protocol, not a replacement for either.
Mandates
The core object is a mandate: a tamper-evident, cryptographically signed credential — a Verifiable Digital Credential — capturing what was authorised. There are two kinds, and each has an open and a closed stage.
Checkout Mandate — shared with the merchant
- Open — the objective and its constraints, before any specific cart exists. "Book a flight under $400, aisle seat."
- Closed — authorisation for the actual, finalised purchase once the cart is real.
Payment Mandate — shared with credential providers, networks and processors
- Open — the payment envelope. Budget ceiling, acceptable methods.
- Closed — authorisation of one specific amount, tied to a finalised checkout.
The merchant learns what you agreed to buy. The payment network learns what you agreed to spend. Neither needs the other's half, and both hold signed proof of their own — so the audit trail survives even though no single party sees everything.
Why it's non-repudiable
Because each mandate is signed, nobody in the chain can later claim a different version of events. The result is what the spec calls a non-repudiable cryptographic audit trail running from the human's original intent through to the settled payment. Every role in the transaction is accountable to a signature, not to a log entry someone could have edited.
What it means for a botvatar
A signed botvatar and an AP2 mandate are the same idea pointed at two different questions. The card proves which agent is acting. The mandate proves what it was allowed to do. Together they answer the two things anyone reviewing an autonomous purchase actually wants to know.
Botvatar's planned role here is to accept mandates on the buying side: when an agent purchases a card on your behalf, the mandate travels with the request, and the resulting identity card can be tied back to a human authorisation rather than appearing out of nowhere.
Not live. Botvatar does not accept AP2 mandates today. This page describes the protocol as specified and the direction we intend to take, not shipped behaviour.
AP2's mandate types were previously described as Intent and Cart mandates. Current documentation uses Checkout Mandate and Payment Mandate, each with open and closed stages. Older write-ups you find will use the earlier names. Also worth separating: A2P is unrelated telecom jargon for application-to-person messaging.
Sources