Agent Payments Protocol (AP2) is Google’s open standard for agent-initiated payments. It uses digitally signed Verifiable Credentials called Mandates. Each transaction carries three Mandates — Intent, Cart, and Payment. Together they prove the user authorized the agent’s action. Importantly, AP2 works with any payment rail: cards, stablecoins, or real-time bank rails. Google first published the spec on September 16, 2025 with sixty payments and tech partners. Then on April 28, 2026, Google donated AP2 to the FIDO Alliance. As a result, it became the opening contribution to FIDO’s new Payments Technical Working Group. Notably, the reference code lives at github.com/google-agentic-commerce/AP2, and the spec at ap2-protocol.org. In short, for builders evaluating agent commerce in 2026, AP2 is the standard most likely to win.
What is AP2 (Agent Payments Protocol)?
AP2 (Agent Payments Protocol) is an open spec. In essence, it lets an AI agent run a payment for a human user with cryptographic proof at every step. Today’s web checkouts assume a human is clicking “buy.” However, AP2 targets a different world. By contrast, in that world an agent picks the product, builds the cart, and sends the payment. Meanwhile, the merchant, the rail, and the regulator all need proof. First, they need to know the user actually approved that action. Second, they need to confirm the agent stayed within the user’s intent.
Google first published the Agent Payments Protocol on September 16, 2025. Specifically, the launch included more than sixty payments and tech partners. Then on April 28, 2026, Google donated the Agent Payments Protocol to the FIDO Alliance. It became the opening contribution to FIDO’s newly formed Payments Technical Working Group, which Mastercard and Visa co-chair. That donation matters. Specifically, it moved the Agent Payments Protocol out of a single vendor’s repo. As a result, AP2 now lives in a multi-vendor governance venue with a thirty-year reputation for shipping durable interop standards.
📌 Quick definition. AP2 uses Verifiable Credentials. Every agent-initiated payment carries three signed Mandates. They prove the user’s intent, the agent’s proposed cart, and the final payment authorization. In short, the protocol is open-source under Apache 2.0, works with any payment rail, and as of 2026, the FIDO Alliance governs it.
How the Agent Payments Protocol Mandates work
The Agent Payments Protocol’s core idea is the Mandate. In essence, a Mandate is a signed Verifiable Credential. The relevant party signs it. As a result, it captures one specific approval. Each AP2 transaction carries three Mandates in order: Intent, Cart, and Payment. Together they form an auditable chain. The chain proves the user authorized the action. Furthermore, it proves the agent stayed within scope. Finally, it confirms the rail charged the right amount.
The Intent Mandate
First, the user signs the Agent Payments Protocol’s Intent Mandate. In short, it captures the instruction the user gave the agent. For example: “book a hotel in Tokyo, under $400 per night, June 5 through 8.” By design, the Intent Mandate can be broad or narrow. For example, it could limit scope to a specific item with a price cap. Next, it travels with the agent through the transaction. As a result, downstream parties can verify the agent’s actions fall within the original authorization. Crucially, the Intent Mandate is the only step that needs a fresh user signature. After that, the agent executes the rest of the transaction autonomously within the captured scope.
The Cart Mandate
Next, the agent signs the Cart Mandate. Specifically, it captures what the agent wants to buy: SKU, price, quantity, delivery details. Notably, the agent generates this Mandate before committing to the transaction. Importantly, the Cart Mandate must match the Intent Mandate. For instance, the agent cannot book a $500-per-night hotel if the user authorized $400. In short, the Cart Mandate gives the merchant a signed guarantee. It proves the agent commits to specific terms.
The Payment Mandate
Finally, the agent signs the Payment Mandate. (In some flows, the user re-signs it instead.) Then the Payment Mandate is the approval the agent sends to the payment rail. The rail can be a card network, a stablecoin contract, or a real-time bank rail. Importantly, the Payment Mandate references the Cart Mandate it pays against. As a result, the rail can confirm the underlying agent action was actually intended before charging. However, if the cart drifts between agent-commit and rail-charge — say a price change or item swap — the Payment Mandate breaks the chain and the transaction halts.
“AI agents are quickly becoming part of how people get things done online. To scale this safely, people need to trust that these actions are secure, authorized and truly reflect their intent.”
Andrew Shikiar, Executive Director and CEO, FIDO Alliance — April 28, 2026
Who is adopting AP2?
The AP2 launch coalition in September 2025 spanned every major segment of the payments stack. First, card networks: Mastercard, Visa, and American Express. Next, PayPal joined alongside Coinbase and Stripe for the alternative-rails angle. Additionally, identity providers Okta, 1Password, and Dashlane signed on for the credentials infrastructure piece. Issuing banks and processors — Discover, Worldpay, Adyen, Klarna — also contributed for the settlement layer. With sixty-plus named partners on day one, AP2’s launch was unusually deep for a brand-new protocol. In short, the underlying parties had coordinated privately for months before the public announcement.
Then in April 2026, the donation to FIDO formalized governance. Mastercard and Visa co-chair the Payments Technical Working Group. Furthermore, founding contributors include Amazon, American Express, PayPal, Okta, 1Password, Dashlane, LastPass, OneSpan, Prove Identity, and Thales. In other words, the mix of payments rails and identity providers mirrors the original AP2 coalition. Google’s own announcement framed the donation as moving AP2 “into a neutral, multi-stakeholder venue.” That’s code for: payments protocols only succeed when the rails control the governance.
Agent Payments Protocol vs other agent-commerce standards
The Agent Payments Protocol is not the only proposal in this space. By contrast, Mastercard’s Verifiable Intent (March 2026) sits at a slightly different layer. Specifically, it defines cryptographic rules for non-payment intent: access, action, delegation scope. Importantly, it interoperates with AP2 for the payment leg. Meanwhile, the Linux Foundation’s Agent2Agent (A2A) protocol sits above both, with 150+ contributing organizations. A2A defines how agents coordinate across organizational boundaries. Finally, the IETF’s Web Bot Auth working group, chartered in early 2026, standardizes HTTP Message Signatures (RFC 9421) at the transport layer. Notably, Visa’s Trusted Agent Protocol and Mastercard’s Agent Pay already use it at the HTTP request level. In short, the four stacks are complementary, not competing.
Web Bot Auth diagram showing cryptographic HTTP Message Signatures for agent identity at the transport layer” class=”wp-image-3599″/>| Protocol | Layer | Governance | Status (2026) |
|---|---|---|---|
| AP2 | Payment authorization | FIDO Alliance (donated April 2026) | v1 spec; reference implementation live |
| Verifiable Intent | User-delegation credentials | Open spec (Mastercard + Google) | v0.1 draft, Apache 2.0 |
| A2A (Agent2Agent) | Agent-to-agent coordination | Linux Foundation | v1; 150+ contributing orgs |
| Web Bot Auth | HTTP-layer agent identity | IETF (chartered 2026) | Draft; Visa and Mastercard already use it in pilots |
⚠️ What is still missing. Three load-bearing questions remain open in the Agent Payments Protocol v1. First, how does the Intent Mandate handle agent-encountered substitutions? For example, the user said “Marriott under $400,” but the agent finds Hyatt at $390 — same intent, different brand. Next, how do delegation chains compose when one orchestrator agent dispatches to sub-agents? Specifically, can it do so without requiring fresh user signatures at every handoff? Finally, how does AP2’s credentials-layer authorization interoperate with the IETF’s transport-layer Web Bot Auth at HTTP? Expect drafts in the next 12 months.
What this means for builders
First, if you build agent commerce in 2026, the Agent Payments Protocol is most likely to be the durable standard. The Google + FIDO governance combination, the 60+ launch coalition, and the depth of card-network and identity-provider commitment all point one way. In short, the Agent Payments Protocol will likely become the equivalent of what OAuth 2.0 became for delegated approval — the assumed default that everything else integrates against.
Here are the practical implications, broken down by team. First, if you build an agent runtime, design your approval layer around signed Mandates. Assume AP2 compatibility is table stakes by mid-2027. Next, if you build a payment-facing product that agents will interact with, accept AP2 Cart Mandates from external agents as a valid checkout path alongside human checkout. As a result, the merchants that move fastest here will win agent-driven traffic — much like mobile-first merchants won mobile traffic in 2014-2017. Finally, if you operate a marketplace or commerce platform, your platform-level identity layer should integrate Web Bot Auth (HTTP-layer). That way, AP2 transactions can be verified at the network edge before they reach your application logic.
The reference implementation at github.com/google-agentic-commerce/AP2 includes example flows for cards, stablecoins, and ACH. Start there. Meanwhile, the spec at ap2-protocol.org is dense but readable. In short, budget two hours for a first pass.
Common misconceptions about the Agent Payments Protocol
AP2 looks like a payments product to people who haven’t read the spec. It isn’t. Three confusions worth clearing up before you decide whether to build against it.
- AP2 is not a payment processor. It does not move money. Stripe, Visa, and Mastercard still do that. AP2 is a verifiable mandate format that wraps the authorization between the user, the agent, and whoever charges the card.
- AP2 is not Google-only. Google authored the first spec but the working group includes Visa, Mastercard, American Express, and PayPal. The intent from day one was for AP2 to ride on top of existing payments rails.
- AP2 does not replace OAuth. OAuth grants an agent API access. AP2 grants an agent payment authority. The two layer on top of each other in any real deployment.
Frequently asked questions
Google first published AP2 on September 16, 2025. The launch coalition included more than sixty payments and technology firms. Among them: Mastercard, Visa, American Express, PayPal, Coinbase, Stripe, Okta, 1Password, Adyen, Klarna, and Discover. Then on April 28, 2026, Google donated the protocol to the FIDO Alliance. It became the opening contribution to FIDO’s Payments Technical Working Group.
Yes. The specification at ap2-protocol.org is open. Furthermore, the reference implementation at github.com/google-agentic-commerce/AP2 uses an Apache 2.0 license. As of April 2026, the FIDO Alliance governs the protocol.
OAuth 2.0 delegates authorization tokens that grant access to resources. The client uses a long-lived bearer token for many subsequent requests. By contrast, AP2 issues short-lived, signed Mandates that authorize one specific transaction. OAuth is about “who can access.” AP2 is about “what action did the user authorize.” However, the two are complementary. An agent typically uses OAuth to identify itself to APIs. Then it uses AP2 to authorize the specific payment action.
AP2 works with any payment rail by design. The reference implementation includes flows for card networks (Visa, Mastercard, Amex), stablecoins (USDC and PYUSD examples), and real-time bank rails (FedNow, SEPA Instant). To add a new rail, developers implement Payment Mandate verification at the rail’s settlement layer.
No. AP2 handles payment authorization. By contrast, Verifiable Intent is broader. It covers non-payment agent actions: access, delegation scope, action constraints. However, the two interoperate. Both protocols were co-developed by Google and now belong to the FIDO Alliance.
Primary sources
- Google Cloud — Announcing the Agent Payments Protocol (AP2), September 16, 2025
- AP2 Protocol Specification — ap2-protocol.org
- AP2 Reference Implementation — GitHub
- FIDO Alliance announcement — April 28, 2026
- Google blog — Donating AP2 to the FIDO Alliance
- Verifiable Intent specification — verifiableintent.dev
- Cloudflare — Web Bot Auth proposal, May 15, 2025
- IETF Web Bot Auth working group charter
Last updated: May 19, 2026. This piece is part of Alatirok’s Commerce beat. Related: Identity & Provenance, Agent Infrastructure.
