Agent Payments Protocol (AP2) Explained: Mandates, FIDO and How It Fits A2A and MCP

The Agent Payments Protocol (AP2) is an open protocol that lets an AI agent prove a user really approved a purchase. It does this with "mandates," cryptographically signed records of what the user agreed to buy and how they agreed to pay. Merchants and payment providers can check those records before money moves.

Google announced AP2 in September 2025. In April 2026 it released AP2 v0.2 and donated the protocol to the FIDO Alliance, the industry group behind passkeys. This guide explains how AP2 works and what it means for stores and agent builders, checked on 6 November 2026.

Why agent payments need a new layer

Card payments assume a person is at the keyboard. When an agent buys on someone's behalf, every party has new questions. Did the user really ask for this? Is this the exact item and price they approved? Who is liable if the agent gets it wrong?

Google's AP2 announcement, dated 16 September 2025, describes mandates as "tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions." That is the core idea. AP2 does not move money. It produces evidence that a payment was authorized.

Who runs AP2

Origin

Google created AP2. The AP2 site is copyright Google and Apache 2.0 licensed, and the AP2 GitHub repository sits under the google-agentic-commerce organization. The 2025 announcement said Google was "collaborating with a diverse group of more than 60 organizations," naming Adyen, American Express, Coinbase, Etsy, Mastercard, PayPal, Salesforce, Worldpay and others.

The move to FIDO

On 28 April 2026, Google's blog post said: "we're donating the Agent Payments Protocol (AP2) to the FIDO Alliance." The same post announced AP2 v0.2 on GitHub. The repository's v0.2.0 release is dated 28 April 2026.

The FIDO Alliance announcement of the same date said FIDO would develop standards for agentic interactions and commerce. It named two groups: an "Agentic Authentication Technical Working Group" and a "Payments Technical Working Group," the latter chaired by members from "Mastercard and Visa." It also said "Mastercard has contributed its Verifiable Intent framework, co-developed with Google," designed to work alongside AP2.

The AP2 FAQ now says: "The core specification work will continue in FIDO."

How AP2 works

The roles

The AP2 v0.2 specification names five roles:

• Shopping Agent: finds products, builds the checkout and runs the purchase.
• Credential Provider: supplies payment credentials, such as a wallet.
• Merchant: provides and completes the checkout.
• Merchant Payment Processor: processes the payment.
• Trusted Surface: a non-agentic screen where the user gives informed consent.

Mandates in v0.2

The spec says: "AP2 defines two Mandate types: Checkout Mandate and Payment Mandate."

• The Checkout Mandate records what is being bought: the items and purchase details, shared with the merchant.
• The Payment Mandate authorizes payment against a specific instrument for that checkout.

Each can be open (constraints the user approves in advance, such as a budget) or closed (the final signed checkout or payment).

Note that the 2025 announcement described an "Intent Mandate" and a "Cart Mandate." The v0.2 spec uses Checkout and Payment Mandates instead. If you read older articles, check which version they describe.

Human present vs human not present

• Human present: "The User directly sees the closed Checkout and approves it and its payment explicitly."
• Human not present: the user approves constraints up front. The shopping agent later signs the closed mandates with its own key, and verifiers check them against the user's open mandates.

Google's April post gives an example of the second mode: an agent buying limited-run tickets the moment they go on sale, within limits the user set.

How AP2 relates to A2A, MCP and UCP

A2A. The AP2 site says AP2 is "available as an extension for the open-source Agent2Agent (A2A) protocol." Its samples run over A2A. See what the A2A protocol is.

MCP. The 2025 announcement said AP2 "can be used as an extension of the Agent2Agent (A2A) protocol and Model Context Protocol (MCP)." The FAQ says, "We are working on an SDK and a MCP server right now, in collaboration with payment service providers." As of 6 November 2026, we did not find a released AP2 MCP server.

UCP. The UCP and AP2 docs say "UCP is fully compatible with Agent Payments Protocol (AP2)." In that flow, the platform creates a CheckoutMandate holding a hash of the checkout and a PaymentMandate as a signed credential, while the business signs the checkout state. See the UCP explainer.

AP2 and x402

x402 is a different thing. The x402 repository describes it as "an open standard for internet native payments" that uses the HTTP 402 "Payment Required" status. A server replies 402 with payment terms, the client sends a signed payment, and a facilitator settles it.

The AP2 FAQ says the a2a-x402 project is "an implementation of A2A in conjunction with the x402 standard" and that AP2 will align with it "over time." Google's 2025 announcement called the A2A x402 extension "a production-ready solution for agent-based crypto payments," built with Coinbase, the Ethereum Foundation, MetaMask and others. The AP2 site's samples include human-present and human-not-present x402 scenarios.

In short: AP2 proves the user authorized the purchase. x402 is one way to actually pay, mostly with stablecoins. Our guide to MCP payments, x402 and Stripe covers pay-per-call tools.

Status: what is real today

• Version: v0.2, released 28 April 2026. The spec page is titled "Agentic Payment Protocol (v0.2)."
• Governance: moving into FIDO working groups.
• Code: the GitHub README says the samples use Google's Agent Development Kit and Gemini, though the protocol "doesn't require the use of either," and "A PyPI package will be published at a later time."
• Production use: the FAQ says the samples "mock actual payment service providers." We found no primary source listing live AP2 deployments by merchants.

Treat AP2 as an emerging standard. It is worth understanding, but not something most merchants implement yet.

What it means for you

Store owners: you do not need to build AP2 now. Watch whether your payment provider and platform add AP2 or FIDO-based agent payment support. Keep your fraud, refund and chargeback policies ready for agent-placed orders.

Payment providers and wallets: AP2 and FIDO's Payments Technical Working Group are where agent payment rules are being written. It is worth following that work.

Agent builders: if your agent buys things, plan for signed user approval. Use human-present flows first. Add human-not-present flows only with tight, user-set limits.

Next step

eSEOspace's AI agent development service helps plan agents that touch payments, with human approval built in, and our MCP development service builds the tools those agents call. We quote every project separately. Compare AP2 with the other standards in our AI agent protocols comparison or on the agent protocols hub.

Frequently asked questions