Agent Payments Protocol (AP2)
Last reviewed
May 16, 2026
Sources
12 citations
Review status
Source-backed
Revision
v1 · 3,571 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Last reviewed
May 16, 2026
Sources
12 citations
Review status
Source-backed
Revision
v1 · 3,571 words
Add missing citations, update stale details, or suggest a clearer explanation.
The Agent Payments Protocol (AP2) is an open specification that lets autonomous AI agents initiate, authorize, and settle payments on behalf of human users. It was announced by Google on September 16, 2025 alongside more than 60 launch partners, including most of the world's largest card networks, processors, and merchant platforms. The protocol introduces a system of cryptographically signed digital contracts called mandates that bind a payment to the user's original instructions, the items in the agent's shopping cart, and the chosen payment method, creating a tamper-evident trail of who authorized what.
AP2 is designed as a complement to two earlier protocols that emerged from the agentic AI ecosystem in 2024 and 2025: the Model Context Protocol (MCP), which standardizes how agents fetch data and tools, and the A2A Protocol (Agent2Agent), which standardizes how agents talk to each other. While MCP and A2A address discovery and communication, AP2 fills the gap they leave open: how a merchant or payments processor knows that a charging request from an agent really reflects what the user wanted, especially when the user is not there to click "approve" at the moment of purchase.
On April 28, 2026, Google transferred ownership of AP2 to the FIDO Alliance, the same standards body that maintains FIDO2 and WebAuthn. The donation, made alongside Mastercard's contribution of a related framework called Verifiable Intent, put AP2 inside a newly formed Payments Technical Working Group co-chaired by Mastercard and Visa, and an Agentic Authentication Technical Working Group co-chaired by CVS Health, Google, and OpenAI. Version 0.2 of the specification, which added support for "human not present" delegated transactions, was published on GitHub on the same day.
By mid-2025, several large technology companies were shipping consumer-facing agents that could browse the web and complete tasks on a user's behalf. OpenAI had launched Operator in early 2025, Anthropic had introduced computer use, Amazon had begun rolling out a feature called Buy for Me, and Perplexity had wired checkout flows into its Comet browser through a partnership with Firmly.ai. The technical pattern shared by all of these was roughly the same: an agent would log into the user's existing accounts, fill in the same fields a human would fill in, and click the same buttons a human would click.
This approach worked for demos but raised hard questions for payments. Card networks and merchants have spent two decades building fraud systems that assume a single physical human is sitting in front of a browser, sometimes confirming with a second factor on a phone. An agent driving a browser session looks almost identical to a fraudster running a script. There is no built-in way for a merchant to ask "did the cardholder actually agree to this purchase?" beyond the same risk signals it already collects, and no way for a card network to distinguish between a legitimate delegation and a compromised credential.
Google framed the problem in its launch post as three missing guarantees. Merchants and processors need authorization, meaning evidence that the user actually granted the agent power to spend in this situation. They need authenticity, meaning evidence that the specific request reflects the user's intent rather than a hallucinated or manipulated action. And they need accountability, meaning a clear answer to the question of who is on the hook if the transaction turns out to be wrong. None of these are well served by existing protocols.
AP2 was the third in a sequence of agent-related open protocols Google released in 2024 and 2025. The first was the A2A Protocol, announced in April 2025, which standardized how independent agents discover one another and exchange structured tasks. The second was Google's adoption of MCP, originally a project from Anthropic, as the canonical way for its agents to call external tools. AP2 layered on top, focused narrowly on the payment step rather than on agent communication in general.
The pattern was deliberate. By owning the early specifications for how agents discover, talk, and pay, Google staked out a position similar to the one it had taken in mobile with Android: rather than ship a closed stack, publish an open one with enough partners attached that it becomes the path of least resistance. Google's payments group, led by Stavan Parikh, and the Business Applications Platform team led by Rao Surapaneni were both credited on the AP2 launch post.
At the center of AP2 are three digital objects that the protocol calls mandates. Each one is a structured document signed with a cryptographic key tied to either the user, the merchant, or a payment provider. Together they record the lifecycle of a transaction from the user's initial request to the final settlement.
The Intent Mandate captures what the user asked the agent to do. In a real-time session this might be "find me white running shoes under one hundred and twenty dollars." In a delegated session it is more detailed, since the user will not be present to confirm later, and might read "buy two front-row tickets to this concert the moment they go on sale, up to four hundred dollars per ticket." The mandate is signed at the point of request and includes constraints such as price ceilings, time windows, and any other conditions the user wants to attach.
The Cart Mandate captures the specific items, prices, and merchant identity that the agent assembled to fulfill the intent. If the user is present, the agent shows the cart and the user signs it to approve. If the user is not present, the agent generates the cart mandate automatically once the intent's preconditions are met, and the signature on the intent mandate carries forward as proof of authorization. The cart mandate locks in the exact contents of the order; once signed, neither the agent nor the merchant can change line items or prices without a new signature.
The Payment Mandate ties the cart to a specific payment method and provider. It carries the cryptographic evidence that the chosen funding source, whether a card token, a bank account, or a stablecoin wallet, was authorized for this particular cart. The mandate also carries metadata that lets the payment provider apply its own fraud and risk checks, including how the user authenticated, what device the agent was running on, and how the chain of consent links back to the original intent.
A full AP2 transaction follows roughly the same shape regardless of payment method. The user gives an instruction to an agent. The agent constructs an intent mandate, presents it to the user, and collects a signature. The agent then negotiates with merchant agents over A2A or with merchant APIs over MCP to assemble a cart. Once a cart is ready, the agent produces a cart mandate. The user signs it if present; otherwise the intent mandate's preconditions are checked against the cart contents.
The agent then forwards the signed cart, the intent mandate, and a chosen payment method to the appropriate payment provider, which constructs and signs the payment mandate. The provider executes the underlying transaction, whether that is a card authorization, a bank transfer, or a stablecoin transfer. The full bundle of signed mandates is returned to the merchant and stored as an audit record. If a dispute arises later, any party can use the mandates to prove what was authorized.
AP2 distinguishes between two operating modes. In human present mode, the user is interacting with the agent during the transaction. They see the cart, they sign it, and the flow looks similar to a normal checkout from the merchant's perspective, except that the cart mandate replaces the usual click-to-confirm. In human not present mode, the user has signed an intent mandate ahead of time and the agent acts later when its preconditions are met. The ticket-purchase scenario is the standard example, but the same model applies to restocking household supplies, buying a flight when a price drops, or paying for compute when an agent runs out of credit.
The protocol is designed to be neutral about how the actual funds move. The same mandate structure can wrap a card-network transaction, a real-time bank transfer, an account-to-account payment, or a stablecoin transfer. For cryptocurrency, AP2 ships with an extension called x402 developed jointly with Coinbase, the Ethereum Foundation, and MetaMask. The x402 extension piggybacks on the long-unused HTTP 402 Payment Required status code, letting an agent that hits a paywalled API respond with an on-chain payment and a signed mandate in one round trip. Coinbase first launched x402 in May 2025 as a standalone HTTP payments protocol; the AP2 integration was finalized in time for the September announcement.
AP2 leans heavily on the W3C Verifiable Credentials data model rather than inventing a new credential format. A verifiable credential is a tamper-evident assertion signed by an issuer about a subject, designed to be verified independently by any party that trusts the issuer's key. The format has been used in identity wallets, academic transcripts, and supply-chain certifications since the W3C standardized it in 2019.
In AP2 every mandate is structured as a verifiable credential. The user's wallet, agent runtime, or pass key acts as the issuer for the intent and cart mandates. A payment provider acts as the issuer for the payment mandate. Each credential carries claims about the subject of the transaction (the user, the agent, the cart, the funding source) and is signed with a key that other parties can verify against a known public key.
The choice has practical consequences. Because verifiable credentials are independently verifiable, a merchant does not have to call back to Google or to the agent platform to confirm that a mandate is genuine; it can verify the signature locally against the issuer's published key. Because they are tamper-evident, any modification to the cart contents or payment method after signing invalidates the signature. Because they are interoperable, the same mandate format works whether the user signed with a hardware security key, a passkey on a phone, or a wallet running on another platform. AP2 also references FIDO authenticators directly for the signing step, which is part of why FIDO Alliance was a natural home for the protocol after the donation.
Google announced AP2 with what it described as more than 60 partner organizations. The list spanned card networks, processors, merchant platforms, cryptocurrency infrastructure providers, and consulting firms. Most major card and wallet brands were on the launch list with the notable exception of Visa, which joined later as a co-chair of the FIDO Payments Technical Working Group in April 2026.
| Partner | Category |
|---|---|
| Mastercard | Card network |
| American Express | Card network |
| JCB | Card network |
| UnionPay International | Card network |
| PayPal | Wallet, processor |
| Coinbase | Crypto exchange, x402 co-author |
| Adyen | Payment processor |
| Worldpay | Payment processor |
| Checkout.com | Payment processor |
| Revolut | Bank, wallet |
| Ant International | Payment processor |
| DLocal | Cross-border processor |
| EBANX | Cross-border processor |
| Airwallex | Cross-border processor |
| Payoneer | Cross-border processor |
| Etsy | Marketplace |
| Shopee | Marketplace |
| Global Fashion Group | Retailer |
| Salesforce | Enterprise platform |
| ServiceNow | Enterprise platform |
| Adobe | Enterprise platform |
| Intuit | Financial software |
| Forter | Fraud and risk |
| Okta | Identity provider |
| 1Password | Identity, credentials |
| Ethereum Foundation | Blockchain infrastructure |
| MetaMask | Crypto wallet |
| Mysten Labs | Blockchain (Sui) |
| Lightspark | Bitcoin Lightning |
| BVNK | Stablecoin infrastructure |
| Crossmint | NFT and stablecoin payments |
| Eigen Labs | Restaking, agent infrastructure |
| Mesh | Crypto API |
| Accenture | Consulting |
| Deloitte | Consulting |
| PwC | Consulting |
| Dell | Enterprise infrastructure |
| Confluent | Streaming data |
| Gravitee | API management |
| Gr4vy | Payment orchestration |
| Nexi | European processor |
| BHN | Gift card and rewards |
| Fiuu | Southeast Asia processor |
| JusPay | Indian processor |
| KCP | Korean processor |
| ManusAI | AI agents |
The absence of Visa at launch drew attention because almost every other major network was on the list, including American Express, JCB, and UnionPay. Holger Mueller, an analyst at Constellation Research, raised the related question of whether Microsoft would back the protocol; the Constellation analysis at the time treated this as the main competitive variable for adoption. Visa would later join not at the protocol level but through FIDO Alliance, where it co-chairs the working group reviewing AP2 and Mastercard's Verifiable Intent contributions.
On April 28, 2026, Google announced that it was donating AP2 to the FIDO Alliance to serve as the basis for an open, industry-developed standard. The donation coincided with Mastercard contributing its own framework, called Verifiable Intent, which had been designed to interoperate with AP2 and to add a tamper-proof log of user-authorized agent actions on top of it.
Stavan Parikh, the Google payments VP who led the original AP2 launch, said in the announcement that "transitioning ownership to the FIDO Alliance ensures AP2 remains platform-agnostic and community-led, while accelerating adoption of secure agentic payments." Pablo Fourez, Mastercard's chief digital officer, framed the joint contribution around "open, interoperable foundations so agent-driven commerce can scale with trust, accountability and privacy built in." Andrew Shikiar, executive director of the FIDO Alliance, said scaling agentic commerce safely required users to "trust that these actions are secure, authorized and truly reflect their intent."
FIDO formed two working groups to absorb the contributions. The Agentic Authentication Technical Working Group, chaired by CVS Health, Google, and OpenAI with vice chairs from Amazon, Google, and Okta, focuses on phishing-resistant delegation: how users grant agents authority in a way that survives social engineering. The Payments Technical Working Group, chaired by Mastercard and Visa, is the home for the AP2 and Verifiable Intent specifications themselves. Other board-level participants in the effort included 1Password, American Express, Dashlane, Egis Technology, LastPass, OneSpan, PayPal, Prove Identity, Thales, and Visa.
Version 0.2 of AP2, released on the same day as the FIDO donation, added explicit support for the "human not present" delegated transaction flow described above. The v0.2 specification and reference implementations were published on GitHub at github.com/google-agentic-commerce/AP2 under the Apache 2.0 license, with a Python SDK using Pydantic models, plus reference scenarios in Python, Go, Kotlin, and a sample Android app.
As of April 2026, three named AP2 deployments are public. PayPal announced a wallet integration with the Google Cloud Conversational Commerce Agent on October 27, 2025, in which PayPal acts as the credential provider, a merchant deploys an agent built on Google's Vertex AI, the user shops conversationally, and AP2 mandates carry between the merchant agent and the PayPal Agent. Mastercard's Agent Pay pilot is integrated with the same PayPal flow as an early proof of concept for the network-level pieces. The Coinbase x402 extension is in production as a separate AP2 deployment focused on stablecoin and machine-to-machine payments.
The public pilots are early-stage and have not produced public transaction volumes. The wider protocol is still young, with the v0.2 specification only six months out at the time of writing. Most of the launch partners have committed to integrate AP2 at the platform level rather than at the consumer-facing flow level, which means the most visible deployments to date have been demos and conference walk-throughs rather than running checkouts at scale.
The x402 extension has seen the most uptake outside of the official AP2 channels. Coinbase, working with Cloudflare, set up an x402 Foundation that now includes Google and Visa, and the protocol has been used for paywalled API access and per-call agent payments at a handful of crypto-native services. Stellar shipped support for x402 on its network as part of the same wave.
AP2 is best understood as one layer of a three-layer agent infrastructure stack that Anthropic and Google jointly shaped during 2024 and 2025. MCP, the lowest layer in this informal hierarchy, handles how agents fetch data and call tools; A2A, the middle layer, handles how agents discover and delegate work to other agents; AP2, the top layer, handles how agents settle the payments those workflows produce.
The three protocols are not formally bundled, and each can be used independently. An agent that uses MCP to query a flight database does not have to use AP2 to pay for the ticket; it could simply use a stored card and complete a normal browser checkout. An agent that uses A2A to coordinate a travel booking across a flight agent, a hotel agent, and a rental-car agent does not have to use AP2 either. The protocols are layered conceptually but not technically; the only required integration point is that AP2 cart mandates can reference items returned by A2A merchant agents, and AP2 intent mandates can ride alongside MCP tool calls.
In practice the three are showing up together in the same demos. Google's launch material for AP2 walks through a coordinated booking scenario in which a user's primary agent uses A2A to talk to a flight booking agent and a hotel booking agent, MCP to query loyalty programs, and AP2 to issue a single set of cart and payment mandates that bundle the two purchases into one verifiable transaction.
Reaction to AP2 split roughly along three lines. Analysts focused on agentic commerce treated the launch as a meaningful milestone. Michael Ni at Constellation Research said "with AP2, Google shifts the center of gravity from last-touch clicks to agent-driven commerce," framing the protocol as a structural change to how online buying intent gets monetized. Esteban Kolsky, also at Constellation, said Google was "doing a good job positioning itself as the option for serious AI work" with its combination of Gemini, infrastructure, and governance pieces. Everest Group described AP2 as potentially foundational "comparable to how APIs revolutionized application integration."
Payments analysts were more cautious. Everest Group flagged four open questions that the protocol does not yet answer: how AP2 integrates with entrenched ERP systems on the merchant side, how liability is allocated when an agent makes a mistake, how PCI-DSS and financial crime monitoring map onto a flow where the cardholder is not directly present, and how merchants should detect adversarial agents that craft technically valid mandates from manipulated user intent. The PaymentsJournal coverage of the FIDO donation framed the working-group structure as a partial answer to these concerns: by moving AP2 into a body with Visa, Mastercard, and major identity providers all at the table, the governance gap could be closed faster than if Google had kept the specification in-house.
Crypto-side reception was largely positive, anchored on the x402 extension. Coverage in the cryptocurrency press treated the AP2-x402 combination as the first credible bridge between agent-driven commerce and stablecoin rails, and the x402 Foundation now includes Google, Visa, Coinbase, and Cloudflare. A March 2026 BlockEden analysis described the field as an active "agent payment protocol war" between AP2, Visa's earlier TAP framework, Coinbase x402 (which has since been absorbed), and PayPal's own agent commerce work; the FIDO donation a month later reframed at least the AP2 and Mastercard pieces as collaborative rather than competitive.
The most common skeptical take in trade press coverage focused on adoption inertia. Existing checkout flows work well enough for the human-present case, and merchants have little immediate reason to add a verifiable credentials layer to their systems just to accommodate an agent population that is still a tiny fraction of traffic. The counter-argument from AP2 proponents is that the merchants who adopt early will be the ones that show up when agents do start driving meaningful volume, and that the fraud and chargeback math will eventually force the issue for everyone else.