AP2: Google's Agent Payments Protocol
AP2 is Google's Agent Payments Protocol, a standard that lets AI agents make purchases with cryptographic proof that you authorized them. The core innovation is the signed mandate.
The AP2 protocol (Agent Payments Protocol) is an open specification led by Google that lets AI agents make payments on a user's behalf while carrying cryptographic proof that the user actually authorized the purchase. The central mechanism is a signed mandate, a verifiable credential that records what a user agreed to buy, under what limits, so that a merchant or payment network can later prove the agent was not acting on its own.
That proof-of-authorization problem is the whole reason AP2 exists. When an agent clicks buy, everyone downstream (the merchant, the card network, the bank) needs to answer one question: did a human actually approve this, or did the model hallucinate a large order? AP2 answers it with signatures instead of trust.
Key takeaways
- AP2 is a payment-authorization standard for AI agents, announced by Google Cloud in September 2025, and developed with a group of payment and technology companies as an open specification.
- Its core primitive is the mandate: a tamper-evident, cryptographically signed record of user intent that travels with the transaction.
- AP2 separates two cases, a human present in real time (Intent Mandate plus Cart Mandate) and a human who pre-authorized a delegated purchase (Intent Mandate only), which changes who bears liability when something goes wrong.
- AP2 is payment-rail agnostic. It is designed to work over cards, bank transfers, and blockchain rails including stablecoins, with a dedicated crypto extension.
- It is meant to complement, not replace, agent-communication standards. It sits alongside protocols for how agents talk to each other and to tools.
The mandate is the whole idea
Strip AP2 down and one object does the heavy lifting: the mandate. Per Google's agentic commerce repositories, a mandate is a verifiable credential signed by the user (or the user's device) that encodes intent and constraints. AP2 defines two that chain together.
The Intent Mandate captures the request in the user's words: "buy running shoes under $150, size 10, only if in stock this week." The Cart Mandate captures the exact thing the agent is about to pay for: this SKU, this price, this merchant, this total. When a user is present, both get signed. When a user has delegated ahead of time ("buy the concert tickets the moment they drop"), the Intent Mandate alone authorizes the agent to construct and execute the cart within the stated limits.
The split draws a clean line for disputes. If the signed cart does not match what the merchant delivered, the merchant is exposed. If the agent bought something outside the signed intent, the agent operator is exposed. If the cart matches an intent the user signed, the charge is authorized. The signatures are the audit trail.
How a purchase flows through AP2
A delegated agent purchase runs roughly like this:
| Step | What happens | What is signed |
|---|---|---|
| 1. Instruction | User tells the agent what to buy and sets limits | Intent Mandate (by user) |
| 2. Discovery | Agent finds a merchant and builds a cart | Nothing yet |
| 3. Confirmation | Cart is presented (live) or matched against intent (delegated) | Cart Mandate (live) or validated against Intent Mandate |
| 4. Payment | Signed mandates are passed to the payment method | Payment credential / mandate reference |
| 5. Settlement | Card network, bank, or blockchain settles the transfer | On-rail record (e.g. onchain transaction) |
The point of carrying the mandate all the way to step 4 is non-repudiation. The payment method receives evidence of authorization, not just an API call it has to take on faith.
Where crypto and stablecoins come in
AP2 is rail-neutral by design, and Google shipped it with a crypto payments path. The A2A x402 extension connects AP2 to onchain settlement, building on the x402 payment standard for agent commerce. In practice this lets an agent settle a purchase with a stablecoin transfer while the AP2 mandate remains the proof that the user authorized it.
Stablecoins are a natural fit for agent payments because they settle in seconds, clear at any hour, and carry programmatic instructions the way agents expect. A mandate that says "pay up to $150" maps cleanly onto a stablecoin transfer with a hard cap.
A worked example
Say an agent is authorized by an Intent Mandate to spend up to $150 and settles in USDC on a low-fee chain. Here is what the reconciliation looks like at three price points the agent might land on.
| Cart total | Within $150 mandate? | Settled asset | Merchant receives |
|---|---|---|---|
| $119.00 | Yes, authorized | 119 USDC | ~119 USDC less network fee |
| $148.50 | Yes, authorized | 148.5 USDC | ~148.5 USDC less network fee |
| $162.00 | No, exceeds cap | Blocked | 0 |
Network fees vary by chain and congestion. The mechanism is the fixed part: the cap in the signed mandate is enforced before settlement, not after.
The reconciliation problem AP2 hands to whoever runs it
AP2 tells you a payment was authorized. It does not, on its own, tell you whether the money actually moved, to whom, and in what asset once settlement happens on a blockchain. Those are two different systems: the mandate lives in the agent stack, the transfer lives onchain.
To reconcile them, an operator has to line up the AP2 mandate reference against the settled onchain transaction and resolve both to the same fields: asset, issuer, sender, recipient, amount, USD value at time of transfer, and transaction type. That is harder than it sounds, because a USDC payment on one chain and a USDC payment on another are different raw records that have to normalize to the same stablecoin, the same issuer, and a comparable USD figure. Allium normalizes stablecoin transfers across chains into those standardized fields, which is what makes an AP2 mandate auditable against what settled onchain.
What AP2 is not
AP2 is not an agent-to-agent communication protocol and not a model framework. It handles the payment authorization step and assumes other standards handle how agents discover each other and exchange messages. It is also not a payment network. It rides on existing rails (cards, bank transfers, stablecoins) rather than replacing them.
Because AP2 is a young, fast-moving specification, treat the mandate structure and extensions as evolving. The public repositories are the source of record for the current schema.
Frequently asked questions
Who created the AP2 protocol?
AP2 (Agent Payments Protocol) was announced by Google, specifically through Google Cloud, in September 2025 as an open specification. It was developed alongside a group of payment networks, card providers, and technology companies, and its reference materials are published in Google's public agentic commerce repositories on GitHub.
What is a mandate in AP2?
A mandate is a cryptographically signed verifiable credential that records what a user authorized. AP2 defines an Intent Mandate (the user's request and spending limits) and a Cart Mandate (the exact items, price, and merchant). Together they provide tamper-evident proof that a purchase was authorized by a human rather than invented by an AI agent.
How is AP2 different from x402?
x402 is a standard for making payments over HTTP, often used for machine-to-machine and stablecoin settlement. AP2 is broader: it defines how user authorization (mandates) travels with an agent's payment across any rail. AP2 includes an extension that connects it to x402-style onchain settlement, so they are complementary rather than competing.
Does AP2 support stablecoin and crypto payments?
Yes. AP2 is designed to be payment-rail agnostic and ships with a crypto payments extension that links AP2 mandates to onchain settlement, including stablecoin transfers. The mandate remains the proof of authorization while the actual value moves as a blockchain transaction.
Who is liable if an AI agent buys the wrong thing under AP2?
AP2's signed mandates are designed to make liability determinable. If the delivered goods do not match the signed Cart Mandate, exposure falls on the merchant. If the agent bought something outside the signed Intent Mandate, exposure falls on the agent operator. If the cart matches the signed intent, the charge is treated as authorized. The signatures form the audit trail for disputes.
Is AP2 live and production-ready?
AP2 was released as an open specification with reference implementations rather than a finished consumer product. The schema and extensions are still evolving, so Google's public agentic commerce repositories are the authoritative source for the current mandate structure and supported payment paths.
