Google's Agent Payments Protocol (AP2): How v0.2 Works
Google's Agent Payments Protocol (AP2) is a specification for proving that a user authorised an agent's purchase. Version 0.2 uses signed Checkout and Payment Mandates, in open and closed forms, across five defined roles. Google donated AP2 to the FIDO Alliance in April 2026. Crypto settlement runs through a separate A2A x402 extension.
What AP2 is, and where it lives now
AP2, the Agent Payments Protocol, is Google's specification for proving that a user authorised an agent to buy something. Google Cloud announced it on September 16, 2025, describing it as an open protocol developed with more than 60 organisations across payments and technology, and usable as an extension of Agent2Agent (A2A) and the Model Context Protocol (MCP).
The governance changed on April 28, 2026. Google announced it was donating AP2 to the FIDO Alliance, the body behind passkeys, and published AP2 v0.2 on GitHub at the same time. The FIDO Alliance's own announcement says the move keeps AP2 platform-agnostic and open to broader industry participation, and the AP2 FAQ states that core specification work continues in FIDO. Biometric Update's coverage of the FIDO launch reports two venues: an Agentic Authentication Technical Working Group, and a Payments Technical Working Group chaired by members from Mastercard and Visa, where AP2 sits alongside Mastercard's Verifiable Intent contribution, which is designed to work with AP2.
The practical reading: v0.2 is the version to build against, the reference repository (google-agentic-commerce/AP2, Apache 2.0) is still where the code lives, and the specification is pre-1.0 inside a standards process. Expect breaking changes.
The five roles
The v0.2 specification splits a purchase across five roles, and the split is the design. Each party sees only what it needs.
Shopping Agent. Discovers products, assembles the checkout, and executes the purchase. Expected to be agentic.
Credential Provider. Holds the payment credential, verifies the agent is authorised to use it, and scopes what it releases.
Merchant. Provides and completes the checkout, and verifies the agent's authority to buy those items.
Merchant Payment Processor. Processes the payment and verifies the credential is authorised for that specific checkout.
Trusted Surface. A user interface that obtains informed consent before any user-signed mandate is created. The separation is the important constraint, whatever the spec's exact wording: the model that wants to buy should never be the thing that collects the user's signature.
Roles can be combined in one system or delegated, so a wallet provider might be both Credential Provider and Trusted Surface.
Mandates in v0.2
A mandate is a signed statement of what was authorised. v0.1 used three names: an Intent Mandate for instructions given in advance, a Cart Mandate for approval of a specific cart, and a payment step linking the instrument to that cart. v0.2 reorganises this into two mandate types, each with an open and a closed form.
Checkout Mandate. Proof for the Merchant that the agent may buy the assembled checkout. It is bound by hash to a merchant-signed Checkout JWT, so the merchant can confirm the approval refers to exactly the checkout it issued. The merchant returns a Checkout Receipt.
Payment Mandate. Proof for the Credential Provider, the network and the Merchant Payment Processor that the agent may pay for that checkout. It is bound to the same Checkout JWT hash, and the processor returns a signed Payment Receipt.
Open versus closed. An open mandate carries constraints: goals and limits for the checkout, budget and allowed instruments for the payment. A closed mandate carries authorisation for one finalised checkout and one amount.
Mandates are secured as SD-JWTs, which means selective disclosure: the holder reveals only the claims a given verifier needs. Schema versions are named in the vct claim with a numeric suffix, such as mandate.payment.1, and verifiers must match them exactly.
Human present and human not present
In direct mode, the user sees the closed checkout and payment on the Trusted Surface and signs closed mandates there. In autonomous mode, added in v0.2, the user signs open mandates in advance. Each open mandate must carry the agent's public key in a cnf claim, and an expiry is recommended. When conditions are met, the agent signs the closed mandates with that key. A verifier checks two links: the user's signature on the open mandate, and the agent key's signature on the closed one, plus that the closed terms fall inside the open constraints.
Payment-method agnostic, with a card-first reality
Google's launch post said AP2 supports cards, real-time bank transfers and stablecoins, and the v0.2 specification states it is agnostic to the instrument: new instruments are added by defining a unique type. That is a statement about the authorisation layer. AP2 does not move money; settlement still happens on a card network, bank rail or chain.
The current documentation is more specific about what exists today. The AP2 site says the initial version supports common pull payment methods such as credit and debit cards, and lists push payments and digital currencies on the roadmap. Read the two together: the mandate format is designed not to care, but the defined flows today are card-shaped.
Where x402 fits
Crypto support came through a separate piece: the A2A x402 extension, now at google-agentic-commerce/a2a-x402, which Google's 2025 announcement said was built with Coinbase, the Ethereum Foundation, MetaMask and others. It defines a three-message exchange between agents: payment-required from the merchant agent, payment-submitted with the client's signed payment, and payment-completed after the merchant verifies and settles onchain. Its specification folder is v0.1. The AP2 site lists Human Present x402 and Human Not Present x402 samples, and the FAQ describes A2A plus x402 as a first step that AP2 will align with over time. So x402 is the settlement path AP2 points at for stablecoins, not a mandate type inside the core spec.
What this means for an onchain agent
An AP2 open Payment Mandate and a session key with a spending cap look similar: both say this agent may spend up to a limit, until a time. They do different jobs.
A mandate is evidence. It travels with the transaction so a merchant, processor or dispute adjudicator can check what the user agreed to. The AP2 FAQ frames it as supporting evidence for networks to establish accountability and liability; it does not assign liability itself.
A session key is enforcement. Its limits are checked by the account contract before a transfer executes. A payment outside scope does not get disputed later; it fails at signing.
An agent paying x402 endpoints in USDC on Base needs the enforcement regardless. The mandate becomes worth carrying when the counterparty asks for proof of user authorisation, which is most likely with merchants coming from card acceptance.
What to watch: whether FIDO changes the mandate schema before 1.0, whether push payments and digital currencies get defined flows, and whether merchants actually start requiring mandates.
Frequently asked questions
- What is Google's Agent Payments Protocol?
- AP2 is a specification Google published in September 2025 for proving that a user authorised an agent's purchase. It uses signed mandates, a Checkout Mandate for the merchant and a Payment Mandate for payment parties, plus signed receipts. Google donated it to the FIDO Alliance in April 2026 and released v0.2 at the same time.
- What changed in AP2 v0.2?
- v0.2 reorganised the v0.1 Intent and Cart Mandates into Checkout and Payment Mandates, each with open and closed forms, secured as SD-JWTs. It added Human Not Present, or autonomous, payments: the user signs open mandates binding the agent's key, and the agent signs closed mandates within those constraints. It shipped alongside the FIDO donation.
- Does AP2 support stablecoins and x402?
- By design it is instrument agnostic, and Google's launch post named stablecoins. The current documentation says the initial version supports pull methods like cards, with digital currencies on the roadmap. Crypto runs through the separate A2A x402 extension, and the AP2 site includes x402 samples for human present and human not present flows.
- Who governs AP2 now?
- The FIDO Alliance. Google announced the donation on April 28, 2026, and the AP2 FAQ says core specification work continues there. Biometric Update reports that FIDO's Payments Technical Working Group, chaired by members from Mastercard and Visa, takes AP2 and Mastercard's Verifiable Intent as contributions. The reference code remains in the google-agentic-commerce GitHub organisation under Apache 2.0.
- Is an AP2 mandate the same as a spending limit?
- No. A mandate records what the user authorised so other parties can verify it and adjudicate disputes. A spending limit enforced by a session key stops an out-of-scope payment before it executes. An onchain agent needs enforcement in the key; a mandate adds portable evidence for counterparties that ask for it.