AP2, the Agent Payments Protocol, is an open standard Google announced on September 16, 2025 so AI agents can pay on your behalf with signed proof of what you approved. It works through “mandates”: tamper-evident digital records of your instructions and the exact checkout, which merchants, banks and card networks can check before any money moves and look back at if something goes wrong.
That is the short version. The rest of this guide explains what the mandates are, how the protocol changed in 2026, how it fits next to Google’s other checkout standard, and what it does and does not do for you as a shopper.
What AP2 is, and who is behind it
AP2 is a set of rules for messages, not an app or a wallet. When an AI agent shops for you, several parties have to trust each other: the agent, the merchant, whoever holds your card or bank details, and the payment network. Google’s launch post framed the problem as three questions nobody could answer well when a bot, not a person, clicks “buy”: authorization (did you give the agent this authority?), authenticity (does the request match what you actually wanted?) and accountability (who is responsible if the purchase is fraudulent or wrong?). Google Cloud described AP2 as an extension of its Agent2Agent (A2A) protocol and of the Model Context Protocol (MCP), and listed more than 60 launch partners, including Mastercard, American Express, PayPal, Adyen, Coinbase, Revolut and Etsy.
Ownership has since moved. On April 28, 2026, Google donated AP2 to the FIDO Alliance, saying the handover keeps AP2 “platform-agnostic and community-led.” The FIDO Alliance’s own announcement followed on April 29. The official documentation site now lists version 0.2, published under the Apache 2.0 license, with the core specification continuing inside FIDO working groups.
So when people search “google ap2,” they mean a protocol Google started and still builds on, but which is now meant to be run as a shared industry standard.
AP2 mandates, explained
A mandate is a digitally signed record. Think of it as a permission slip that cannot be edited after you sign it without the edit being detectable. AP2 uses a type of verifiable credential for this, and the documentation describes each mandate as “created by the Shopping Agent, rendered to the User by the Trusted Surface and verified by the Merchant.” The “trusted surface” is the screen where you confirm, such as a wallet or your phone’s payment prompt, rather than the chat window itself.
The original names: Intent Mandate and Cart Mandate
At launch, Google explained AP2 with two mandates (Google Cloud):
- Intent Mandate: your starting instruction, such as “find me new white running shoes,” plus any rules for a delegated task, such as a price limit or a deadline.
- Cart Mandate: created once the agent shows you a final basket. Your approval signs it, locking the exact items and price. Google’s phrase for the goal was “what you see is what you pay for.”
The sequence, intent to cart to payment, is meant to leave what Google called “a non-repudiable audit trail”: a record that is hard for anyone to deny later.
The current names: Checkout Mandate and Payment Mandate
Version 0.2 of the specification reorganizes this into two mandates, each with an “open” and a “closed” form (ap2-protocol.org):
| Mandate | Open form (before the final basket) | Closed form (the final transaction) |
|---|---|---|
| Checkout Mandate | Your constraints and goals: which merchants are allowed, which kinds of items may be in the basket | Authorization of one specific checkout, including a checkout object the merchant signs |
| Payment Mandate | Your payment limits: budget, allowed cards or methods, and how often the agent may reuse it | Authorization of one payment: payee, amount, payment instrument, and a link to the exact checkout |
In plain terms, the open forms play the role the Intent Mandate used to play, and the closed forms play the role of the Cart Mandate plus the payment itself. The closed Payment Mandate is checked by the credential provider, the card network and the merchant’s payment processor, and it carries a hash of the checkout it pays for, so a signed approval for one basket cannot quietly be reused for a different one.
The open Payment Mandate also has an “agent recurrence” setting that lets an agent reuse it with frequency limits (daily, monthly or yearly) and a cap on the number of uses (ap2-protocol.org). That is the protocol’s version of a standing order with guardrails.
Human present and human not present
AP2 covers two situations (Google Cloud):
- Human present. You ask, the agent finds options, you approve the final basket, and the payment runs against what you approved. This is the everyday “buy this for me” case.
- Human not present. You sign detailed conditions up front, the agent watches for them, and when they are met it completes the purchase without asking you again.
The second one is the headline feature of version 0.2. Google’s April 2026 post used the example of buying limited-run tickets the moment they are released (Google). The same post says Mastercard co-developed a related standard, Verifiable Intent, with Google. If you want to see how the card networks’ own agent programs work for cardholders, our guide to Visa Trusted Agent Protocol and Mastercard Agent Pay covers that side.
How AP2 fits with UCP, ACP and x402
“AP2 protocol” gets confused with Google’s other agent-commerce standard, the Universal Commerce Protocol (UCP), because both come from Google. The AP2 FAQ draws the line this way: UCP runs the broader purchase flow (finding the product, the checkout session, order updates), while AP2 is the payment authorization layer. The FAQ says to use UCP for checkout inside Google’s AI surfaces and AP2 for agent-to-agent payments or verifiable credentials outside Google’s surfaces.
The two also combine. The UCP documentation calls AP2 “the trust layer for agent-led transactions,” and when it is switched on in a UCP checkout, the merchant signs the checkout state and the platform issues a Checkout Mandate and a Payment Mandate so that “the price and terms don’t change mid-flow.”
| Standard | What it does | Where you meet it |
|---|---|---|
| AP2 | Signed proof of what the user authorized, for any payment method | Started by Google, now with the FIDO Alliance |
| UCP | The checkout flow between an agent and a merchant; can carry AP2 mandates | Google’s AI surfaces and partner merchants |
| ACP | The checkout flow for purchases made inside ChatGPT | OpenAI’s commerce platform |
| x402 | Pay-per-request payments in stablecoins over the web | Offered as an AP2 extension for crypto payments |
For the ChatGPT-versus-Google comparison, see ACP vs UCP. For who supports which standard right now, the agentic commerce protocols tracker is updated monthly.
Which payments AP2 supports
AP2 is designed to be payment-agnostic. At launch, Google said it covers credit and debit cards, real-time bank transfers and stablecoins, with an x402 extension for crypto payments built with Coinbase, the Ethereum Foundation and MetaMask (Google Cloud). The current documentation lists cards, x402 and digital payment credentials on Android, with e-wallets and push payments such as UPI and PIX on the roadmap. If x402 is new to you, our plain-language x402 guide explains it.
What AP2 means for you as a shopper
You do not install AP2 or sign up for it. If it reaches you, it will be inside a product you already use: an assistant, a wallet or a checkout. What you would notice is the “trusted surface,” a confirmation screen outside the chat that shows the exact basket and price before you approve.
The protocol’s design has three consequences worth knowing:
- Your approval becomes evidence. The FAQ says signed Checkout Mandates let payment networks compare what you authorized against a dispute claim. That can help you if an agent bought something outside your limits, and it can also be used against a claim that you never approved a purchase you did sign.
- Limits are enforced, not just suggested. The security section says constraint checks at the closed-mandate stage mean “worst-case financial impacts are strictly bounded.” A limit you set is supposed to hold even if the agent is misled.
- Less of your data travels. The FAQ describes payload encryption and selective disclosure so that agents do not need to see card numbers or other sensitive details.
AP2 does not decide who pays when something goes wrong. Your card or bank protections still come from the law and your issuer. What AP2 adds is a clearer record for that process. Our guide to an AI agent purchase gone wrong walks through refunds and chargebacks in practice.
What to watch out for
- It is still early. The version number is 0.2. The FAQ says the sample agents use mocked payment providers, and that an SDK and MCP server are still being built with payment companies. A launch partner list is not the same as live support.
- Prompt injection is assumed, not solved. The specification’s own threat model says “all LLMs and Agents MUST be considered potential attackers” and that “preventing prompt injection attacks is infeasible” (ap2-protocol.org). AP2’s answer is to cap the damage through signed limits, not to stop an agent being fooled into a poor choice within those limits. Our guide to AI browser agents and prompt injection shows how that trickery works.
- Broad pre-approvals carry more risk. A human-not-present mandate with a wide merchant list and a high budget gives an agent a lot of room. Narrow limits are the safer default.
- Security researchers see gaps in implementation. A Cloud Security Alliance analysis flagged mandate spoofing, agent hijacking and weak key management where hardware-backed signing is not used, and recommended strong customer authentication and hardware-backed keys.
- Names are in flux. Articles written in 2025 describe Intent and Cart Mandates; the current specification uses Checkout and Payment Mandates. Both describe the same idea.
If you run a business and are deciding whether to support AP2, a payments provider or adviser can tell you what your processor supports today; the specification alone will not.
How we checked this
We read Google’s launch and FIDO donation announcements, the AP2 specification pages and FAQ at ap2-protocol.org, the UCP documentation and an independent security analysis from the Cloud Security Alliance. Facts checked on September 25, 2026.
