# AP2 explained: Google’s Agent Payments Protocol and its mandates

What the Agent Payments Protocol is for, how its Checkout and Payment Mandates work with the shopper present and absent, what changed in v0.2, and what a merchant has to do.

By Valerii Checha, 9 Nov 2026

AP2, the Agent Payments Protocol, is how an AI agent proves to a merchant and a payment network that a person really authorised this purchase. It does that with mandates: signed records of what the user approved. Version 0.2 has two, a Checkout Mandate that goes to the merchant and a Payment Mandate that goes to the payment side, each in an "open" form for limits set in advance and a "closed" form for one exact purchase. Google launched AP2 in September 2025 and donated it to the FIDO Alliance in April 2026.

This article goes through what AP2 is for, how its mandates work with the shopper present and absent, what changed between versions, and what a merchant has to do. The specification and Google's posts are quoted from their own pages, read on 4 November 2026. Storewalk is ours. For where AP2 sits next to Stripe's tokens, Visa and the rest, read [how an agent pays](https://storewalk.ai/blog/how-agents-pay); for AP2 against UCP, ACP and MCP, [the comparison](https://storewalk.ai/blog/ucp-vs-acp-vs-mcp-vs-ap2).

## What is AP2 for?

For the moment a payment no longer has a person clicking Buy. The AP2 site puts it this way: "Today's payment systems assume a human is directly clicking "buy" on a trusted website. When an autonomous agent initiates a payment, this core assumption is broken". It lists three questions that follow:

- "Authorization: How can we verify that a user gave an agent specific authority for a particular purchase?"
- "Authenticity: How can a merchant be sure an agent's request accurately reflects the user's true intent, without errors or AI "hallucinations"?"
- "Accountability: If a fraudulent or incorrect transaction occurs, who is accountable"

AP2 does not run the shop. The specification says "AP2 operates as a security feature within a Commerce Protocol", and that catalogue APIs, checkout updates and the like "are outside the scope of AP2". It is "designed explicitly to be compatible with the Universal Commerce Protocol (UCP)", and the site says it is "available as an extension for the open-source Agent2Agent (A2A) protocol and Universal Commerce Protocol". So AP2 is the paperwork stapled to a purchase that another protocol carries.

## What are AP2 mandates?

Signed statements of what the user approved, built as "verifiable digital credentials (VDCs)", which the site describes as "tamper-evident, cryptographically signed digital objects". The spec is short on this point: "AP2 defines two Mandate types: Checkout Mandate and Payment Mandate."

- The Checkout Mandate covers what is bought. "The Checkout Mandate is provided by the Shopping Agent and verified by the Merchant."
- The Payment Mandate covers how it is paid. "The Payment Mandate is provided by the Shopping Agent and verified by the Credential Provider, Network, and Merchant Payment Processor."

The two are tied to one checkout. The merchant "MUST provide a merchant-signed JWT containing the Checkout to the Shopping Agent", and both mandates are bound to that JWT by its hash, so, in our reading, a mandate for one basket will not verify against another.

Each comes in two stages. A closed mandate is for one finalised checkout. An open mandate carries the user's limits for an agent acting alone; for payment, the site's examples are "budget, allowed instruments". Pick a mandate to see what it holds and who checks it:

AP2’s mandates, open and closed, and the names version 0.1 used.

Checkout Mandate, closed (v0.2). What it captures: The site: a Checkout Mandate “Captures the reference to the specific items and purchase details negotiated between the agent and the merchant”; closed, it “Captures the user’s (or agent’s) authorization for a specific, finalized checkout.” Who sees and checks it: “The Checkout Mandate is provided by the Shopping Agent and verified by the Merchant.” It is bound to the merchant-signed Checkout JWT “using a cryptographic hash.” Who signs it: With the user present, by the user on a Trusted Surface. With the user not present, the agent “MAY now sign it using its Agent Key”.

Sources: [AP2 documentation](https://ap2-protocol.org/) and [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

Checkout Mandate, open (v0.2). What it captures: Open, it “Captures the user’s constraints and goals for the transaction before a specific cart is finalized for autonomous execution.” Who sees and checks it: Given to the merchant alongside the closed one when the user is not present: the agent “MUST provide both the user-signed open Mandate and the agent-signed closed Mandate”. Who signs it: By the user, through the Trusted Surface. It “MUST include the agent’s public key as a cnf claim”, and the spec recommends the shortest expiry that lets the agent finish.

Sources: [AP2 documentation](https://ap2-protocol.org/) and [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

Payment Mandate, closed (v0.2). What it captures: “Authorizes a payment against a specific payment instrument”; closed, it “Captures the authorization for a specific transaction amount bound to a finalized checkout.” Who sees and checks it: “The Payment Mandate is provided by the Shopping Agent and verified by the Credential Provider, Network, and Merchant Payment Processor.” Who signs it: With the user present, the agent passes the Checkout and Payment Mandate content “to a Trusted Surface for display to the user and signing.” With the user not present, it “assembles and approves a closed Checkout and Payment Mandate on their behalf using these open Mandates.”

Sources: [AP2 documentation](https://ap2-protocol.org/) and [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

Payment Mandate, open (v0.2). What it captures: “Captures the user’s constraints on payment (e.g., budget, allowed instruments) for autonomous execution.” Who sees and checks it: The Credential Provider and, if applicable, the network check that the closed Payment Mandate “matches all the Constraints”. Who signs it: By the user, ahead of time, through the Trusted Surface.

Sources: [AP2 documentation](https://ap2-protocol.org/) and [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

Intent and Cart Mandates (v0.1, Sep 2025). What it captures: Google’s launch post: a request “is captured in an initial Intent Mandate”, and “your approval signs a Cart Mandate”, “a secure, unchangeable record of the exact items and price”. Who sees and checks it: The launch post describes a chain “from intent, to cart, to payment” that “creates a non-repudiable audit trail”. Who signs it: These are the September 2025 names. Version 0.2 says “AP2 defines two Mandate types: Checkout Mandate and Payment Mandate”, each open or closed.

Sources: [Google Cloud: Announcing Agent Payments Protocol (AP2) (16 Sep 2025)](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) and [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

## Who takes part in an AP2 payment?

Five roles, by the spec. The Shopping Agent "is the primary agent performing product discovery, building the checkout, and executing the purchase." The Credential Provider "is the source of Payment Credentials for the purchase." The Merchant "is responsible for providing and completing the Checkout". The Merchant Payment Processor "is responsible for processing payments for purchases." And the Trusted Surface is "a UI surface that is trusted to get informed user consent for an Intent before creating a user-signed Mandate."

One company can play several: "it is possible for a single entity to play multiple (or even all) of the roles." The spec also says why the extra signatures exist at all: "when either role is agentic, then the Agent itself is a potential attacker." It is a rare spec that names its own main user as a suspect, and here that is the whole idea.

## How does it work with and without the shopper present?

AP2 has two modes. With the shopper present ("Human Present", or direct), "The User directly sees the closed Checkout and approves it and its payment explicitly." Without them ("Human Not Present", or autonomous), "The User sees and approves a set of constraints over what closed Checkout and Payment would meet their intent", and the agent then signs the closed mandates itself, within those limits.

The merchant always ends up with the same thing: "Verifiers of Mandates always receive a closed Payment and Checkout Mandate, regardless of the mode." The difference is whose key signed the closed one, and whether an open mandate comes with it as proof that the agent was allowed. Step through both flows:

AP2 v0.2 mandates, with the user present and not present.

Human present:

1. Merchant → Shopping Agent: Merchant-signed Checkout JWT. The merchant must give the shopping agent a merchant-signed JWT containing the checkout; Human Present starts once the agent has it. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
2. Shopping Agent → Trusted Surface: Mandate content to show and sign. The agent builds the Checkout and Payment Mandate content and passes it to a Trusted Surface for display to the user and signing. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
3. Shopping Agent → Credential Provider: Payment Mandate for verification. With the mandates signed, the agent forwards the Payment Mandate to the Credential Provider (and possibly the network). It is bound to the checkout by the hash of the Checkout JWT. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
4. Credential Provider → Shopping Agent: Payment credential. Upon successful verification the agent receives a payment credential. The spec has the Credential Provider (or, if applicable, the network) return it after receiving the Payment Mandate. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
5. Shopping Agent → Merchant: Credential + Checkout Mandate. The payment credential and the Checkout Mandate go to the merchant, which checks the checkout against the one it created. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
6. Merchant → Merchant Payment Processor: Initiate payment. For a merchant-initiated charge, the merchant initiates payment with its Merchant Payment Processor. If the payment method pushes funds, the merchant instead confirms the funds it received. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
7. Merchant → Shopping Agent: Checkout Receipt. Once it has accepted or rejected the Checkout Mandate, the merchant must return a Checkout Receipt. A Payment Receipt goes to the agent, the Credential Provider and, if applicable, the network. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

Human not present:

1. Shopping Agent → Trusted Surface: Open mandates to authorize. To act autonomously the agent creates open Checkout and Payment Mandate content, constraints the user approves, and has the Trusted Surface authorize it. Open mandates must carry the agent’s public key as a cnf claim. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
2. Shopping Agent → Credential Provider: Open + closed Payment Mandate. The agent must give verifiers both the user-signed open mandate and its closed one “as described in the Direct case”, which sends the Payment Mandate first. Its verifiers are the Credential Provider and, if applicable, the network and the Merchant Payment Processor. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).
3. Shopping Agent → Merchant: Open + closed Checkout Mandate, which the agent may sign itself. Then, as in the Direct case, the Checkout Mandate goes to the merchant. The agent may sign the closed mandate with its own key instead of getting approval on a Trusted Surface; verifiers always receive closed mandates. Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

The autonomous mode carries a safeguard against an agent spending the same permission twice: "Shopping Agents MUST NOT present any subsequent open Payment or Checkout Mandates without receiving a rejection receipt from the previous one."

## What changed between AP2 versions?

The names and the shape of the mandates. Google's launch post of 16 September 2025 described an "Intent Mandate", which captured the request, and a "Cart Mandate", which your approval signs as "a secure, unchangeable record of the exact items and price". The AP2 repository tagged v0.1.0 that day.

Version 0.2 arrived on 28 April 2026, the day Google announced it was "donating the Agent Payments Protocol (AP2) to the FIDO Alliance". The same post says v.0.2 "introduces critical updates for autonomous transactions, including "Human Not Present" payments". The current specification is titled "Agentic Payment Protocol (v0.2)" and uses the Checkout and Payment Mandates above, each open or closed. If you read an older explainer that talks about intent and cart mandates, it describes v0.1.

The FIDO move changes who steers it. Google says the transfer "ensures AP2 remains platform-agnostic and community-led", and the AP2 site says "Standardization of the specification will continue within the Agentic Authentication Technical and Payments Technical Working Groups in FIDO." The same post mentions Verifiable Intent, "a new, AP2-compatible standard co-developed with Mastercard and also being donated to FIDO".

## What does a merchant have to do for AP2?

Sign the checkout, check the mandate, and answer with a receipt. The spec's rules for the merchant role:

1. Provide a merchant-signed JWT of the checkout to the agent. The spec adds a detail for your developers: the Checkout JWT "MUST be signed using a digital signature scheme (e.g., ECDSA) and not a deterministic signature (e.g., Ed25519)."
2. "The Merchant MUST receive an appropriate Checkout Mandate from a Shopping Agent before completing the Checkout."
3. Verify it, match the hash to the checkout you signed, and, if open mandates came with it, check every constraint.
4. Return a Checkout Receipt either way. On failure, "the Merchant MUST return a Checkout Receipt JWT containing the appropriate error message."

Try the merchant's side with a few answers:

What an AP2 merchant must check before completing a checkout.

On the page, you answer whether the shopper is present, whether the mandate verifies, whether checkout_hash matches and whether the open mandate’s constraints are met, and read the steps and the outcome. The steps, in the spec’s words:

1. Verify the Checkout Mandate. “Process and verify the Checkout Mandate according to Verification and Processing Rules.”
2. Match the checkout hash. “Verify that the hash of the Checkout JWT sent for approval matches the value included for the checkout_hash claim.”
3. Check the open mandate’s constraints. “If open Checkout Mandates are included, verify that the closed Checkout conforms to all of the Constraints by evaluating each Constraint.”

- Shopper present, everything checks out: Every step passes, so you complete the checkout. Either way the spec says the merchant “MUST return a Checkout Receipt”.
- Shopper present, the hash does not match: fails at "match the checkout hash". “If any step fails, the Merchant MUST return a Checkout Receipt JWT containing the appropriate error message.”
- Shopper not present, the checkout breaks a constraint: fails at "check the open mandate’s constraints". “If any step fails, the Merchant MUST return a Checkout Receipt JWT containing the appropriate error message.”

The spec lets you hand this to a provider: “a Merchant could have their payment processor perform verifications on their behalf.”

Source: [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/).

You do not have to build it yourself. "Roles MAY always delegate their responsibilities to another party", and the spec's own example is "a Merchant could have their payment processor perform verifications on their behalf." In our reading, most stores will get AP2 through their payment provider or their platform's UCP integration rather than write it themselves. The payment side is narrower than it sounds, too. The site says "the initial version supports common "pull" payment methods like credit and debit cards", with push payments and digital currencies on the roadmap.

## Does AP2 help with disputes?

That is part of the design. The spec says "In the case of a dispute, the Checkout Mandate and Receipt, and Payment Mandate and Receipt can be brought together to provide a non-repudiable picture of the transaction." Then it draws the line: "Specific details of how this is used for dispute resolution, retention, and retrieval requirements are outside the scope of this specification." The evidence is defined; how a card network weighs it is not, as of v0.2.

## How does Storewalk treat AP2?

Our scan does not look for AP2 mandates: they travel with a purchase, and the scan does not buy anything. What it checks is the ground AP2 stands on. [TRX-003](https://storewalk.ai/checks/TRX-003) asks whether your payment provider documents a way to accept an agent's payment token, and the UCP checks, starting with [DISC-018](https://storewalk.ai/checks/DISC-018), read the profile that AP2 is designed to plug into. For the five walls between an agent and a sale, see [the hub article](https://storewalk.ai/blog/why-agents-cant-buy).

## Frequently asked questions

### What is the Agent Payments Protocol?

An open protocol for payments made by AI agents. Its site calls it "an open protocol for the emerging Agent Economy", and its spec says it "operates as a security feature within a Commerce Protocol" such as UCP.

### What are the AP2 mandate types?

Version 0.2 says "AP2 defines two Mandate types: Checkout Mandate and Payment Mandate." Each is open, carrying the user's limits, or closed, for one finalised checkout. Version 0.1 used the names Intent Mandate and Cart Mandate.

### Who owns AP2 now?

Google donated it to the FIDO Alliance on 28 April 2026. Standardisation continues in FIDO's Agentic Authentication and Payments technical working groups.

### What is "Human Not Present" in AP2?

The mode where the user approves limits in advance and the agent completes the purchase alone. The user "sees and approves a set of constraints", and the agent signs the closed mandates within them. Google's 2025 launch post already described delegated tasks of this kind; its April 2026 post says v0.2 "introduces critical updates" for them.

### Does my store need to implement AP2?

Not by hand, in most cases. The spec lets a merchant delegate verification to its payment processor. Check what your payment provider and platform support. Our [agent readiness scanner](https://storewalk.ai/) checks the parts of agent checkout your store already shows.

The sources below were last checked on the date shown.

## Sources

- [AP2 documentation](https://ap2-protocol.org/)
- [AP2 specification (v0.2)](https://ap2-protocol.org/ap2/specification/)
- [Google Cloud: Announcing Agent Payments Protocol (AP2) (16 Sep 2025)](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol)
- [Google: Google donates Agent Payments Protocol to FIDO Alliance (28 Apr 2026)](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/)
- [GitHub: google-agentic-commerce/AP2 releases](https://github.com/google-agentic-commerce/AP2/releases)

Last checked 4 Nov 2026