AP2 Protocol Explained: Google's Agent Payments Protocol

AP2 (the Agent Payments Protocol) is an open protocol that lets an AI agent pay on your behalf while proving, cryptographically, that you authorized the purchase. Announced by Google in September 2025 and donated to the FIDO Alliance in April 2026, it introduces mandates — signed, verifiable credentials that capture exactly what an agent is allowed to buy and under what limits — so a merchant or bank can trust an agent's payment without trusting the agent itself. This guide explains how AP2 actually works: the mandate model (as restructured in v0.2), the five roles, the transaction flow, how stablecoins plug in via x402, and how AP2 relates to ACP and Google's UCP.

New to the space? Start with the parent guide: What is Agentic Commerce?

Why AP2 exists: the trust gap

Every existing payment system assumes a human is clicking "buy" on a trusted screen. Autonomous agents break that assumption, and AP2's spec is explicit about the questions that follow:

• Authorization & auditability — proving a user gave this agent authority to make this purchase, with a record after the fact.
• Authenticity of intent — letting a merchant be sure the agent's request reflects what the user actually wanted.
• Agent error protection — safeguards against a hallucinating or misinterpreting model buying the wrong thing.
• Accountability — determining who is responsible when a transaction is fraudulent or wrong.

AP2's founding principle is "verifiable intent, not inferred action": a payment must anchor to deterministic, non-repudiable proof of intent from all parties — never to the probabilistic output of a language model. That one sentence is the whole design philosophy. An agent's reasoning is never the authorization; a signed mandate is.

Architecturally, AP2 is a payment/authorization layer that rides on top of agent messaging protocols — it extends Google's Agent2Agent (A2A) and the Model Context Protocol (MCP), rather than replacing them. A2A and MCP move the messages; AP2 proves the money is allowed to move.

Mandates: the core primitive

A mandate is a Verifiable Digital Credential — implemented as a selective-disclosure JWT (SD-JWT), signed with ECDSA — that encodes a delegation of purchasing authority. Mandates are the thing AP2 actually adds to the world.

Here's the catch most articles get wrong. The original September 2025 model (v0.1) had an Intent Mandate and a Cart Mandate, and nearly every explainer still describes AP2 that way. The v0.2 spec (April 2026) restructured it. If you're building against AP2 today, this is the current model:

Checkout Mandate — what is being bought

Authorizes completion of a checkout; shared with the merchant. Two variants:

• Open (mandate.checkout.open.1) — created and signed by the agent, holding constraints on what's acceptable rather than a fixed order: allowed_merchants (name + website) and line_items (acceptable items, quantities). This is the delegation form — "you may buy these kinds of things, from these merchants."
• Closed (mandate.checkout.1) — binds to one specific merchant-signed order (checkout_jwt) via a hash (checkout_hash). This is the finalized, this-exact-transaction form.

Roughly: an open Checkout Mandate is the spiritual successor of the old Intent Mandate; a closed one, of the old Cart Mandate.

Payment Mandate — how it is paid

Authorizes payment; shared with the credential provider, the network and the merchant's payment processor. Also open/closed, also SD-JWTs. Its constraint fields are where AP2 gets concrete, and they will look familiar to anyone who's thought about agent spend controls:

Read that table again: budget, amount range, allowed payees, recurrence, expiry. The industry's answer to "how do you let an agent spend safely" is converging on exactly these primitives — the same ones a governance layer sits on top of.

Cryptographically, a closed mandate is bound to its open mandate by an sd_hash, and to the merchant's order by checkout_hash. In a human-present flow the closed mandates are signed by the user's key; in a human-not-present flow, by the agent's key operating inside the limits the user signed earlier. That signature distinction — not a flag in a field — is how AP2 encodes "was a human there?"

The five roles

AP2's spec defines five core roles. Keeping them straight is the fastest way to understand any AP2 diagram:

1. Shopping Agent (SA) — discovers products, assembles the checkout, executes the purchase.
2. Credential Provider (CP) — holds the user's payment credentials; verifies the agent's authorization and issues a payment token.
3. Merchant (M) — provides and completes the checkout; signs the order.
4. Merchant Payment Processor (MPP) — processes the payment; verifies the payment mandate.
5. Trusted Surface (TS) — a UI surface trusted to capture informed user consent and hold the user's signing key. Critically, it must be non-agentic — the human's consent can't be captured by the same agent that wants to spend the money.

(The spec's overview also mentions the payment network and issuer as participants; they sit outside the five core roles.)

The Trusted Surface is the load-bearing trust anchor of the whole design — the one place a human actually signs. It's also, therefore, the thing you'd worry about most: compromise it, and the non-repudiation guarantees fall.

How an AP2 payment flows

Human-present (you're in the loop):

1. You shop with the Shopping Agent; it assembles a cart with the Merchant.
2. The Merchant returns a signed checkout (checkout_jwt) and asks for a mandate.
3. The agent pulls payment options from the Credential Provider and builds the mandate content.
4. The Trusted Surface authenticates you and, with your key, signs the closed Payment and Checkout Mandates.
5. The agent sends the Payment Mandate to the Credential Provider → gets a payment token.
6. Token + Checkout Mandate go to the Merchant → the MPP verifies everything and pays → signed receipts flow back.

Human-not-present (the agent transacts alone, later):

• Phase 1 (you're there): the agent builds open mandates for the session; the Trusted Surface authenticates you and you sign them — constrained, but not tied to any specific purchase. You leave.
• Phase 2 (you're gone): the agent finds a matching cart, checks it against the constraints you signed, then signs the closed mandates with its own key — binding each to the open mandate it's operating under. The Merchant verifies both the closed mandate and that the open-mandate constraints are satisfied before charging.

This two-phase structure is the important bit for anyone deploying autonomous agents: the human authorizes a bounded envelope once, and the agent operates inside it unattended. The budget and allow-lists aren't advisory — they're cryptographically part of what the merchant checks.

Payment-method agnostic: from cards to stablecoins

AP2 launched card-first, with wallets and real-time bank transfers on the roadmap. Crypto arrives through a separate extension: a2a-x402, which Google describes as a "production-ready solution for agent-based crypto payments," built with Coinbase, the Ethereum Foundation and MetaMask. It uses x402 — the HTTP-402 settlement protocol — as the rail, so an AP2 mandate can be settled in stablecoins as easily as on a card. The mandate layer (who's allowed to pay what) is deliberately decoupled from the settlement layer (how the money actually moves).

Governance: from Google to FIDO

AP2 is no longer Google's to steer. On April 28, 2026, alongside the v0.2 release, Google donated the protocol to the FIDO Alliance — the standards body behind passkeys — to keep it platform-agnostic and community-led. Mastercard contributed an AP2-compatible standard, Verifiable Intent, a tamper-proof log of user-authorized agent actions, into the same effort. The FIDO Payments working group that now stewards it is co-chaired by Mastercard and Visa — notable because Visa was absent from AP2's original launch lineup.

That launch lineup was already broad: 60+ organizations including Mastercard, American Express, PayPal, Adyen, Coinbase, Etsy, Intuit, Revolut, Salesforce and Worldpay. The conspicuous absentees in September 2025 were Visa, Stripe and Amazon — a reminder that a "standard" announced by one platform isn't neutral until its rivals actually join. Visa's arrival via the FIDO working group (and the x402 Foundation) in 2026 is a real signal that AP2 is consolidating into genuinely shared infrastructure.

AP2 vs ACP vs x402 vs UCP

The single most useful thing to internalize: these are mostly different layers, not direct competitors.

AP2 and x402 are explicitly complementary — x402 is one of AP2's settlement rails. AP2 also positions itself as a security feature within Google's Universal Commerce Protocol: UCP handles the commerce, AP2 handles the authorization inside it. The one pairing to be careful about is AP2 and ACP — they're often discussed together, but no formal interoperability between them has been announced; treat them as parallel efforts (authorization vs checkout) until someone ships a bridge.

Using AP2 today

AP2 ships a reference SDK, Python-first (code/sdk/python/ap2/), with Pydantic models, canonical JSON schemas, and sample scenarios (a human-present card flow, an Android scenario, an x402 crypto sample) plus a web client. The repo is Apache-2.0, sits around 3,100 stars, and spans Python, TypeScript, Kotlin and Go.

Two caveats worth stating plainly. First, it's pre-1.0 — the v0.1→v0.2 restructuring was a genuine breaking change, and fields can still move; pin your version. Second, the SDK reads as a reference/implementation kit, and the real-world footprint is still early: Google has talked about AP2 rolling into products like Universal Cart with user-set spending limits, but there are no published AP2 transaction volumes or adoption metrics as of mid-2026. Build against it to be ready; don't assume ubiquity yet.

Limitations and open questions

• Spec churn: any tutorial describing "Intent Mandate vs Cart Mandate" is describing v0.1. The current model is Checkout + Payment Mandates (open/closed).
• Trust concentration: the non-agentic Trusted Surface and the key material behind it are the design's single point of failure for non-repudiation.
• Adoption is unproven: broad partner lists and a shift to FIDO are encouraging, but published usage is essentially zero so far.
• Fragmentation: AP2, ACP, x402 and UCP each solve a slice; a real agent stack likely touches several, and the interop story between them is still being written.

What this means if your agents spend money

AP2 is the clearest sign yet of where the industry landed on agent spending: the answer is explicit, signed, bounded delegation — budgets, amount ranges, allowed payees and expiry, cryptographically enforced at the point of payment. That's the protocol's own vocabulary, and it's the same vocabulary you need whether or not your agents ever emit an AP2 mandate.

The gap AP2 doesn't close is the operational one: across a fleet of agents, spread over multiple providers and rails, who is watching the aggregate spend, catching the anomaly, and producing the audit trail your finance team can actually reconcile? That cross-provider governance layer is what AgentLedger builds — the budgets, approvals, kill switch and audit trails that sit on top of every agent wallet, whichever protocol moves the money. See it on synthetic data in the live demo.

For the wider protocol map and the latest moves, see What is Agentic Commerce? and our biweekly Agentic Commerce News roundup.

Frequently asked questions

What is AP2 in simple terms?

AP2 (Agent Payments Protocol) is an open standard that lets an AI agent make a payment for you while proving you authorized it. Instead of trusting the agent, a merchant or bank verifies a mandate — a signed credential spelling out what the agent may buy and up to what limit.

Is AP2 free and open source?

Yes. The specification and reference SDK are open source under the Apache-2.0 license, and the protocol is now governed by the neutral FIDO Alliance rather than a single company.

What's the difference between AP2 and x402?

Different layers. AP2 handles authorization — proving an agent is allowed to pay. x402 handles settlement — actually moving the money, over HTTP 402, typically in stablecoins. They work together: x402 is one of the rails an AP2 mandate can settle on, via the a2a-x402 extension.

What is a mandate in AP2?

A mandate is a signed, verifiable credential that delegates purchasing authority. AP2 v0.2 uses two: a Checkout Mandate (what may be bought) and a Payment Mandate (how it's paid, with constraints like budget, amount range, allowed payees and expiry). Each comes in an "open" (constrained delegation) and "closed" (specific transaction) form.

Is AP2 live in production?

The spec is real, versioned (v0.2) and open source, and major payment companies back it — but it's pre-1.0 and adoption is early, with no published transaction volumes yet. It's ready to build against; it isn't yet ubiquitous.