What is AP2? Google's Agent Payments Protocol explained
AP2 does not move money. It produces signed proof of what a user let an agent buy, so the merchant, the credential provider and the network can each check it before anything is charged.
In this essay
AP2, the Agent Payments Protocol, is an open protocol created by Google that secures payments made by AI agents. It does not move money itself. It defines signed "mandates", verifiable digital credentials that prove what a user authorized an agent to buy and pay, so the merchant, the credential provider and the payment network can each verify that authority before a payment goes through. AP2 works as an extension of the A2A and Universal Commerce (UCP) protocols and is designed to be agnostic about the payment method.
Google announced AP2 on September 16, 2025, and released version 0.2 in April 2026. Google Cloud: AP2 announcement, AP2 changelog on GitHub This page explains the current version; for how AP2 sits next to other agent protocols, see MCP, A2A, ACP, AP2 and UCP.
What problem does AP2 solve?
Card payments assume a person clicks "buy" on a trusted page. When an agent initiates the payment, the AP2 documentation asks what proves the user gave the agent authority for this purchase, how a merchant can be sure the request reflects the user's intent rather than an agent error, and who is accountable when a transaction is wrong. AP2: executive summary
AP2's answer is a design principle it calls "verifiable intent, not inferred action": the transaction is anchored to deterministic, non-repudiable proof of intent instead of to a language model's interpretation of a prompt.
How do AP2 mandates work?
AP2 v0.2 defines two mandate types, and each exists in two states. AP2: specification v0.2
| Mandate | Shared with | Open state | Closed state |
|---|---|---|---|
| Checkout Mandate | Merchant | The user's constraints and goals before a cart exists, such as allowed merchants and line-item requirements | Authorization for one finalized checkout, bound to the merchant-signed checkout |
| Payment Mandate | Credential provider, network, merchant payment processor | Payment constraints such as a budget, amount range, allowed payees or allowed instruments | Authorization for one amount against one instrument, bound to the same checkout |
The merchant signs the checkout it offers as a JWT. Both closed mandates are bound to the hash of that checkout JWT, linking "what is bought" to "how it is paid". After verification, the merchant returns a Checkout Receipt and the payment processor a signed Payment Receipt.
Two modes use the same objects:
- Human present: the user sees the closed checkout and approves the closed mandates directly.
- Human not present: the user approves open mandates in advance. The agent later signs closed mandates with its own key, and verifiers check them against the user-signed open ones.
Verifiers always receive closed mandates; only how their signature is trusted changes. The constraints an agent can be held to are listed in AP2: Payment Mandate and AP2: Checkout Mandate.
What does the AP2 mandate flow look like?
The human-not-present case is where the protocol does the most work.
On a trusted surface, the user signs constraints such as merchants, items and budget.
The agent assembles a cart and the merchant returns a signed checkout JWT.
The agent's key signs mandates bound to that checkout hash.
The credential provider returns an error, and the user can be brought back to approve.
The credential provider returns a payment credential for this checkout.
Checkout and Payment Receipts return to the agent as evidence.
Simplified from the AP2 v0.2 flow examples, which the specification describes as non-normative.
Two rules in the specification are worth knowing before you build. An agent must not present another open mandate without first receiving a rejection receipt for the previous one, which stops one approval from paying for several checkouts. And a merchant or credential provider can return an unresolved_constraint error to pull the user back into the loop. AP2: flow examples Both support the duplicate controls described in one durable purchase intention.
What happened to intent mandates and cart mandates?
They were the version 0.1 vocabulary. The original specification described a Cart Mandate signed by the user when present, an Intent Mandate for purchases made while the user was absent, and a Payment Mandate that gave the network and issuer visibility of the agent transaction. AP2 v0.1.0 specification on GitHub
| AP2 v0.1 (September 2025) | AP2 v0.2 (April 2026) |
|---|---|
| Intent Mandate: user-signed conditions for a purchase in their absence | Open Checkout and open Payment Mandates carrying typed constraints |
| Cart Mandate: user-signed final cart | Closed Checkout Mandate bound to a merchant-signed checkout JWT |
| Payment Mandate: agent and modality signals for network and issuer | Closed Payment Mandate verified by credential provider, network and processor |
The table is an editorial reading of the two versions, not an official migration guide. Many articles still use v0.1 terms, so confirm which version a partner implements; v0.2 requires verifiers to match each mandate's exact vct schema version.
How does AP2 use verifiable credentials?
AP2 specifies SD-JWTs, a selective-disclosure form of JSON Web Token, to secure both mandates. Selective disclosure lets an agent show a verifier only the constraints relevant to the closed mandate it is checking. Open mandates must carry the agent's public key in a cnf claim so that only that agent can use them, and the specification recommends setting expiry to the shortest time that lets the agent finish the task. AP2: specification v0.2
Two design choices matter for risk teams: the trusted surface that collects consent must be non-agentic, so no language model sits in the consent path, and all validation must happen in deterministic code. Permission to research versus permission to buy covers how to design the approval those credentials record.
Is AP2 tied to cards or crypto?
Neither. The specification says AP2 is agnostic to the payment instrument: new instruments are added by defining a payment instrument type. Its payment constraints already include allowed instruments (examples include card and UPI) and allowed payment initiation service providers. The AP2 site says the initial version supports "pull" methods such as credit and debit cards, with e-wallets, real-time bank transfers such as UPI and PIX, and digital currencies on the roadmap. AP2: home
For stablecoins, the AP2 FAQ points to an A2A and x402 implementation and says it will be aligned closely with AP2 over time; the repository includes x402 sample scenarios. AP2: FAQ What x402 is explains that protocol.
How does AP2 relate to A2A, MCP and UCP?
- A2A carries messages and tasks between agents. AP2 is available as an A2A extension for payments between shopping agents, merchants and credential providers.
- MCP connects an agent to tools and data. The v0.1 documentation summarized the split as "MCP: agents communicate with data", "A2A: agents communicate with other agents", "AP2: agents communicate about payments".
- UCP orchestrates the purchase lifecycle. The AP2 FAQ describes AP2 as the payment layer that authorizes and signs transactions within it, and v0.2 says it is designed to be compatible with UCP.
Who backs AP2?
Google created AP2 and publishes it under the Apache 2.0 license. The v0.1 partner page listed organizations including Mastercard, American Express, PayPal, Adyen, Worldpay, Coinbase, Revolut, JCB and UnionPay International. AP2 v0.1.0 partners page A listing is not evidence that a company has shipped AP2.
With v0.2, Google donated AP2 to the FIDO Alliance, and the FAQ says core specification work will continue there. Google: AP2 v0.2 and FIDO Alliance donation Mastercard says its Verifiable Intent standard is aligned with AP2. Mastercard: Verifiable Intent
FAQ
What is AP2 in simple terms?
A protocol that lets an AI agent prove, with signed credentials, what a user allowed it to buy before the merchant and payment providers accept the transaction.
What is an AP2 mandate?
A signed verifiable credential. AP2 v0.2 uses a Checkout Mandate for what is bought and a Payment Mandate for how it is paid, each open (constraints) or closed (one specific transaction).
Does AP2 still use intent mandates and cart mandates?
Not in v0.2. Those were v0.1 terms; open mandates now carry the user's conditions and closed mandates authorize the final checkout and payment.
Is AP2 a payment rail?
No. AP2 secures the authority for a payment. The money still moves over cards, bank transfers or other methods through the credential provider and payment processor.
Can AP2 mandates be used in chargebacks?
The specification says the mandates and receipts together give a non-repudiable picture of the transaction for disputes, but leaves dispute procedures, retention and retrieval out of scope.
Closing thought and further reading
AP2 does not move money. It produces signed proof of what a user let an agent buy, so the merchant, the credential provider and the network can each check it before anything is charged.
Ideas that continue the thread.
View all essays
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.