In short
Agent Payments Protocol (AP2) is an open protocol that allows AI agents to pay securely and traceably on behalf of a person. Google presented it on 16 September 2025 together with more than 60 partners from the payments and retail industries.
At the core of the protocol are so-called mandates: cryptographically signed, tamper-proof digital proofs that record what the user wanted, what the agent put in the basket and what is being used to pay.
AP2 sees itself as an extension of the Agent2Agent protocol (A2A) and the Model Context Protocol (MCP). It does not define a payment method of its own but describes how shopping agent, merchant, wallet provider and payment processor exchange proof. The source code, the specification and reference implementations are available on GitHub under the Apache 2.0 licence. This entry explains which problem AP2 solves, how the mandates work, which roles are involved and what this means for shops.
Which problem AP2 solves
Existing payment systems assume that a person clicks "Buy now". As soon as an agent takes over this click, three things are missing. In its announcement, Google names them as authorisation, authenticity and accountability. Authorisation: how does the agent prove that the user permitted exactly this purchase? Authenticity: how does the merchant know that the request reflects the user's true intent? Accountability: who is liable if a transaction was wrong or fraudulent?
Without a shared answer to these questions, every merchant, every payment service provider and every bank would have to invent its own rules for agents. The result would be isolated solutions that do not trust each other. AP2 instead proposes a payment-method-agnostic framework with which users, merchants and payment providers can transact with each other without each side having to see through the other side's AI. At its core, this is the idea of agentic commerce: the agent acts, the person remains responsible.
Why this is relevant for shops
For an online shop, the question is not whether agents will shop, but how to distinguish their orders from fraud. An agent that orders with stolen card details initially looks in the logs like an agent acting on behalf of a satisfied regular customer. AP2 gives the merchant a signed receipt that ties the order to a specific user decision. This reduces the risk of chargebacks and makes disputes verifiable.
The mandates: intent, cart and payment
The central concept of AP2 is mandates. Google describes them as tamper-proof, cryptographically signed digital contracts that serve as verifiable proof of a user's instructions. Technically, they are verifiable digital credentials, i.e. signed data objects whose authenticity every party involved can check. According to the specification, the user's signature is created via a hardware-backed key on their device with in-session authentication, for example via passkey or biometrics.
| Mandate | What it records | Who signs | When it is used |
|---|---|---|---|
| Intent mandate | Payer and payee, permitted payment methods, shopping parameters such as price limits and conditions, the agent's understanding of the task in natural language, a period of validity (TTL) | User | Above all for delegated purchases where the person is not present later |
| Cart mandate | The exact items, quantity, price, currency, delivery destination, tokenised payment method, risk data, return conditions | First the merchant (confirms availability), then the user (authorises the purchase) | For every purchase, as an unchangeable receipt for "what you see is what you pay" |
| Payment mandate | Signals that an agent was involved, the transaction modality (person present or not) and additional data for networks and issuers | Passed on to the payment network and the card-issuing bank | When the payment is authorised, so that banks recognise agentic transactions |
Intent mandate: the task
The intent mandate is the signed version of what the user wants. It contains not only product wishes but also guardrails: which payment methods are permitted, how much may be spent and how long the task is valid. The field in which the agent records its interpretation of the task in natural language is important. The user therefore signs not only their words but also what the agent has made of them. Misunderstandings thus become visible early, not only after delivery.
Cart mandate: the basket
The cart mandate is created after the agent has put together a specific basket. It is signed in two stages. First the merchant signs, guaranteeing that it can deliver the items at this price. Then the user signs, or in delegated scenarios the agent within the scope of the intent mandate. The result is an unchangeable record of items and price. Neither agent nor merchant can adjust it afterwards without breaking the signature.
Payment mandate: the signal to the bank
The payment mandate is not aimed at the merchant but at the payment system behind it: networks such as Mastercard or Visa and the card-issuing banks. It communicates that an agent was involved in the transaction and whether the person was present at the moment of payment. Banks can feed this information into their risk assessment. Until now, agent transactions have been invisible to issuers; with the payment mandate they get a type of their own that can be recognised.
A note on terminology: the project site ap2-protocol.org now also describes a "checkout mandate" with an open and a closed phase that combines intent and cart into one object. The basic idea remains the same: a signed intention before the purchase, a signed basket at the time of purchase and proof of payment for the network.
Roles in the protocol
AP2 is deliberately role-based. Each party only sees the data it needs for its task. The specification defines six roles.
- User: the person who delegates a shopping task to their agent.
- Shopping agent: the AI interface the user talks to directly. It understands the need, searches for products and obtains the signed authorisation. More on this class of agent in the entry AI agents.
- Credentials provider: a specialised entity that manages payment data securely and executes the payment, for example a digital wallet. The shopping agent never sees the card number.
- Merchant endpoint: a web interface, an MCP endpoint or the merchant's own agent that expects a payment.
- Merchant payment processor: the merchant's payment processor, which builds the authorisation message for the payment network. In practice this is usually the shop's payment service provider.
- Network and issuer: the payment network and the bank that issued the payment card to the user.
This separation is the reason why AP2 is considered data-minimising. The merchant gets the cart mandate but no raw card data. The credentials provider gets the payment instruction but not the user's entire chat history. The network gets the payment mandate with risk signals but no product details.
Human present and human not present
AP2 distinguishes between two scenarios whose flows differ markedly.
Human present
Google's example from the announcement: you ask an agent to find new white running shoes. The request ends up in an intent mandate. The agent searches, puts together a basket and shows it to you. Your approval signs the cart mandate. Only then does money flow. The person therefore sees the final basket and actively confirms it, similar to paying with a wallet on a smartphone today.
Human not present
Second example: "Buy the concert tickets as soon as advance sales start." Here you sign a detailed intent mandate in advance with a price limit, a time window and further conditions. As soon as the conditions are met, the agent may create a cart mandate itself and complete the purchase. The specification provides that the merchant can require confirmation from the person if it is unsure whether the basket fulfils the task. Delegation is therefore possible, but not unlimited.
Payment methods and the x402 extension
AP2 is designed to be payment-method-agnostic. The specification's roadmap starts in version 0.1 with pull methods, i.e. credit and debit cards, and is to add push methods such as bank transfers and e-wallets in version 1.x. As examples of later extensions, the project site names real-time transfers such as UPI and PIX as well as digital currencies.
Alongside the announcement, Google published the A2A x402 extension together with Coinbase, the Ethereum Foundation, MetaMask and other organisations. It transfers the AP2 constructs to crypto payments and stablecoins and is described by Google as a production-ready solution for agent-based crypto payments. The name refers to the HTTP status code 402 "Payment Required", which has been reserved for decades but never used in a standardised way.
Partners and licence
In its announcement, Google names more than 60 organisations, including Adyen, American Express, Ant International, Coinbase, Etsy, Forter, Intuit, JCB, Mastercard, Mysten Labs, PayPal, Revolut, Salesforce, ServiceNow, UnionPay International and Worldpay. The mix is telling: card networks, payment processors, marketplaces, fraud prevention and Web3 providers sit at the same table. For a protocol whose benefit depends on network effects, this is the most important prerequisite.
The protocol is published under the Apache License 2.0 on GitHub. That is where you will find the specification, flow diagrams, FAQs, a Python SDK with Pydantic models and JSON schemas, as well as example scenarios, for instance for card payments with the user present. According to the project site, further standardisation is taking place in working groups of the FIDO Alliance, which is also behind passkeys.
AP2 in the protocol stack: A2A, MCP and UCP
AP2 is not a competitor to A2A or MCP but builds on them. A2A governs how agents talk to each other, MCP how an agent connects tools and data sources. AP2 adds to both the question of how an agent pays in a binding way. The specification describes itself as a non-proprietary, open extension for existing and future A2A and MCP protocols.
The interplay with the Universal Commerce Protocol (UCP) is particularly interesting. UCP describes the entire shopping process between agent and merchant, from product search to checkout. For the payment step, UCP explicitly refers to AP2: the project site ucp.dev mentions built-in support for AP2, A2A and MCP and describes secure payments via AP2 payment mandates and verifiable credentials as a security pattern. Anyone planning UCP for their shop therefore almost inevitably ends up with AP2 when it comes to payment.
| Protocol | Responsible for | Relationship to AP2 |
|---|---|---|
| A2A (Agent2Agent) | Communication between agents | AP2 is an extension of A2A |
| MCP (Model Context Protocol) | Connecting tools and data to a model | AP2 can be used as an MCP extension; a merchant endpoint can be an MCP endpoint |
| UCP (Universal Commerce Protocol) | Shopping process between agent and merchant | UCP uses AP2 mandates for payment |
| A2A x402 | Crypto and stablecoin payments | Extension of the AP2 constructs for Web3 |
Real-world example: AP2 in Gemini Spark
For a long time AP2 was a specification project without an end-customer product. That changed at Google I/O on 19 May 2026. In a post on the new Universal Cart, Google announced that it would bring AP2 into its own products in the coming months, starting with Gemini Spark.
The usage described corresponds exactly to the intent mandate idea: the user sets strict guardrails for agentic payments, namely which brands and products the agent may buy and how much it may spend. Google speaks of tamper-proof digital mandates and privacy-friendly technology that creates a transparent, verifiable link between user, merchant and payment processor. The agent thus demonstrably always acts on the user's behalf.
For merchants this means: agents with AP2 mandates will not just remain a protocol draft but will really appear at checkout via Google's interfaces. In the same post, Google describes the expansion of UCP from the USA to Canada and Australia and later to the UK. No timetable for the DACH region was given there.
What AP2 means for Shopware shops
Today you do not have to rebuild anything in a Shopware shop to support AP2. There is no official Shopware module yet, and most payment providers are only just implementing their roles as credentials provider or merchant payment processor. Three things are nevertheless worthwhile now.
- Ask your payment service provider: Adyen, PayPal, Worldpay and Mastercard are among the initial partners. Anyone using one of these providers will probably get AP2 support via an update of the existing payment plugin, not via a project of their own.
- Maintain structured product data: a cart mandate needs unambiguous items, prices, currency and delivery conditions. Gaps in product data are noticed by agents immediately because, unlike people, they do not guess.
- Keep checkout logic API-ready: according to the specification, a merchant endpoint can be an MCP endpoint. Shops whose basket and checkout functions can be reached cleanly via the Store API have a head start here.
The protocol is young; version number 0.1 speaks for itself. Concepts may still change, as the renaming towards the checkout mandate shows. But the direction is clear: agents need proof of what they are allowed to pay for, and AP2 is currently the only proposal with this breadth of payment partners.
Frequently asked questions
Is AP2 a payment method of its own?
No. AP2 replaces neither card payments nor PayPal nor bank transfers. It describes how proof of a user decision is attached to the existing methods. The payment itself still runs via network, issuer and payment processor.
Can an agent with AP2 spend money without my knowledge?
Only within what you have signed beforehand. When the user is present, you confirm the final basket yourself. For delegated purchases, the intent mandate sets price limits, conditions and a period of validity. The merchant can also demand confirmation if it is unsure.
What is the difference between AP2 and UCP?
UCP covers the entire purchase between agent and merchant, from search to order. AP2 concentrates on the payment step and the signed mandates. For secure payments, UCP explicitly refers to AP2.
Does AP2 support crypto and stablecoins?
Yes, via the A2A x402 extension that Google published together with Coinbase, the Ethereum Foundation and MetaMask. The core of AP2 starts with card payments; bank transfers and wallets are planned for later versions.
When will AP2 arrive in real products?
On 19 May 2026, Google announced that it would introduce AP2 first in Gemini Spark in the coming months. Support on the merchant side depends on the respective payment provider.