--- title: "What is AP2? Google's Agent Payments Protocol" description: "AP2 (Agent Payments Protocol) is Google's trust and authorization layer for agent-led payments, built on A2A. How mandates work, the a2a-x402 crypto rail, and the one thing a site can actually publish that a scanner can check." last_updated: 2026-06-12 canonical_url: https://agent-ready.dev/what-is-ap2 --- # What is AP2? > Google's trust and authorization layer for agent-led payments — a signed, verifiable chain of user intent, built on A2A. ## What is AP2? AP2 (**Agent Payments Protocol**) is Google's open protocol for **agent-led payments**. Crucially, it is *not* a settlement rail competing with cards or stablecoins. It is a **trust and authorization layer** that answers one question: when an AI agent buys something on a user's behalf, how does the merchant prove a human actually authorized that specific purchase? AP2 is payment-agnostic across cards, bank transfers, stablecoins, and crypto, and launched in September 2025 with 60+ partners including Mastercard, American Express, PayPal, Adyen, Coinbase, and the Ethereum Foundation. It is open-source under Apache-2.0 at [google-agentic-commerce/AP2](https://github.com/google-agentic-commerce/AP2) (currently v0.2.0), with reference implementations in Python, Go, and Android. ## Mandates: the chain of intent AP2's core primitive is the **Mandate** — a cryptographically signed **verifiable credential** that records what the user agreed to. They chain together: - **Intent Mandate** — a standing instruction ("buy these when they drop below $100"). - **Cart Mandate** — locks the exact items and final price into a non-repudiable record the user authorizes. - **Payment Mandate** — authorizes the actual transfer to the chosen instrument. In the reference SDK each is an `SD-JWT`, so every party can prove what was agreed without trusting an intermediary. This is what makes an agent purchase *non-repudiable*. ## How AP2 rides on A2A (and the x402 crypto rail) AP2 defines no transport of its own. It is an **extension** layered on [A2A (Agent-to-Agent)](https://agent-ready.dev/mcp-vs-a2a-vs-agents-json) and MCP: a participant advertises support by listing the AP2 extension URI in its A2A Agent Card under `capabilities.extensions`, and mandates are exchanged inside the live A2A conversation. Crypto settlement is handled by a sibling extension, **a2a-x402** — AP2's bridge to the [x402 HTTP 402](https://agent-ready.dev/x402-checker) scheme, co-developed with Coinbase, the Ethereum Foundation, and MetaMask. When supported, its URI (`https://github.com/google-a2a/a2a-x402/v0.1`) appears as a second entry in the same `extensions` array. For how AP2 sits next to ACP, UCP, and x402, see [ACP vs UCP vs AP2 vs x402](https://agent-ready.dev/acp-vs-ucp-vs-ap2-vs-x402). ## What can a website actually publish? AP2 has exactly **one static, publisher-discoverable surface**: the A2A Agent Card at `/.well-known/agent-card.json`, where the AP2 extension URI is declared under `capabilities.extensions`. A scanner can fetch that card and confirm AP2 is advertised. What it *cannot* check statically is mandate validation itself. The Intent, Cart, and Payment mandates are runtime SD-JWTs exchanged inside an A2A conversation — there is no GET-able mandate schema and no well-known file to fetch. So AP2 detection is checkable from outside; mandate conformance is a developer and runtime concern, not a site scan. ## How Agent Ready checks it (C20) Agent Ready's protocol check **C20 — AP2 payment protocol support** reads the A2A Agent Card already fetched for C4/C5 and confirms the canonical AP2 extension URI (`github.com/google-agentic-commerce/ap2/v1`) is declared in `capabilities.extensions`. When the a2a-x402 crypto rail is also declared, C20 surfaces it and cross-links the x402 checks (C10/C11). It is a discover-then-validate check — sites that don't advertise AP2 simply don't see it, so an ordinary site is never penalised for lacking it. C20 does not grade mandate credentials: there is no static artifact to validate. To see where your site stands across every agent signal, run a full [agent-readability scan](https://agent-ready.dev/agent-readability-score). ## Frequently asked questions ### What is AP2? AP2 (Agent Payments Protocol) is an open, Apache-2.0 protocol from Google for agent-led payments. It is not a settlement rail — it is a trust and authorization layer that captures a verifiable chain of user intent so a merchant can prove a purchase was actually authorized by a human. Its core primitive is the Mandate: a cryptographically signed verifiable credential. AP2 is payment-agnostic across cards, bank transfers, stablecoins, and crypto, and launched with 60+ partners including Mastercard, American Express, PayPal, Adyen, Coinbase, and the Ethereum Foundation. ### What is a Mandate (Intent, Cart, Payment)? A Mandate is the signed verifiable credential at the heart of AP2. The chain runs: an Intent Mandate captures a standing instruction ("buy these running shoes when they drop below $100"); a Cart Mandate locks the exact items and final price into a non-repudiable record the user authorizes; and a Payment Mandate authorizes the actual transfer. Each is a verifiable credential — in the reference SDK, an SD-JWT — so every party can prove what was agreed without a trusted intermediary. ### How does AP2 relate to A2A and MCP? AP2 does not define its own transport. It is an extension layered on top of A2A (Agent-to-Agent) and MCP: a participant advertises AP2 support by listing the AP2 extension URI in its A2A Agent Card's capabilities.extensions array, and the mandates are then exchanged inside the live A2A conversation. So AP2 reuses the same agent-to-agent plumbing A2A already provides rather than inventing a new one. ### What is the a2a-x402 extension? a2a-x402 is AP2's crypto-payment path — the bridge between AP2 and the x402 HTTP 402 settlement scheme, co-developed with Coinbase, the Ethereum Foundation, and MetaMask. When a participant supports it, the a2a-x402 extension URI (https://github.com/google-a2a/a2a-x402/v0.1) appears as a second entry alongside the AP2 URI in the same Agent Card capabilities.extensions array. It is how an AP2 flow settles over stablecoins/crypto rather than card networks. ### Can a website publish an AP2 endpoint a scanner can check? Partly. AP2 has exactly one static, publisher-discoverable surface: the A2A Agent Card at /.well-known/agent-card.json, where the AP2 extension URI is declared under capabilities.extensions. A scanner can fetch that card and confirm AP2 is advertised. What it cannot check statically is mandate validation itself — Intent/Cart/Payment mandates are runtime SD-JWTs exchanged inside an A2A conversation, with no GET-able schema or well-known file. So detection is checkable; mandate conformance is a developer/runtime concern. ### Does Agent Ready check for AP2? Yes — at the advertisement level. Protocol check C20 (AP2 payment protocol support) reads the A2A Agent Card already fetched for C4/C5 and confirms the canonical AP2 extension URI (https://github.com/google-agentic-commerce/ap2/v1) is declared in capabilities.extensions. When the a2a-x402 crypto rail is also declared, C20 surfaces it and cross-links the x402 checks (C10/C11). It is a discover-then-validate check: sites that don't advertise AP2 simply don't see it. C20 does not validate mandate credentials — there is no static artifact to grade. --- Read the full guide on the web: Score your site for agents: ## Sitemap See the full [sitemap](https://agent-ready.dev/sitemap.md) for all pages on agent-ready.dev.