Key Takeaways
- AP2 is an open authorization protocol co-developed by Google and 60+ partners for secure AI agent payments
- Three types of cryptographically signed Mandates (Cart, Intent, Payment) ensure authorization, authenticity, and accountability in agent transactions
- AP2 is payment-agnostic by design and integrates with existing agent infrastructure as an extension of A2A and MCP
The Three Questions AP2 (Agent Payments Protocol) Answers
In September 2025, Google announced AP2 (Agent Payments Protocol) via the Google Cloud Blog. Over 60 companies — including Mastercard, PayPal, American Express, Adyen, and Coinbase — signed on as partners.
So why does agent-driven commerce need its own payment protocol? Existing payment infrastructure assumes a human is present at checkout. 3D Secure authentication and SMS verification codes ultimately rely on a person pressing a button. When AI agents autonomously execute purchases, this model breaks down entirely.
AP2 directly confronts three questions that agentic commerce cannot avoid. First, Authorization: how do you prove a user gave an agent specific authority to make a particular purchase? Second, Authenticity: how can a merchant confirm that an agent's request accurately reflects the user's true intent? Third, Accountability: when a fraudulent or erroneous transaction occurs, who bears responsibility?
To address these questions, AP2 builds a deterministic trust model around Verifiable Digital Credentials (VDCs) — cryptographically signed digital certificates. Rather than inference-based trust, it relies on cryptographically verifiable evidence.
How Mandates Work — The Technical Core of AP2
The most critical concept for understanding AP2 is the Mandate. A Mandate is a tamper-proof, cryptographically signed digital contract that records a user's instructions in a verifiable form. AP2 defines three types, each serving a distinct purpose.
| Mandate Type | Purpose | Signer | Use Case |
|---|---|---|---|
| Cart Mandate | Final approval of a specific cart | User's device key | Real-time purchases (human-present) |
| Intent Mandate | Pre-authorized purchase with conditions | User's device key | Delegated purchases (human-not-present) |
| Payment Mandate | AI agent transaction signal to payment network | User's device key | Issuer/network risk assessment |
Cart Mandate — Authorizing Real-Time Purchases
Imagine asking an agent to find white running shoes. The agent locates candidates and assembles a cart. At this point, the merchant cryptographically signs the cart contents (items, price, shipping destination), and the user's device approves and adds its own signature. This is the Cart Mandate.
A Cart Mandate includes line items, total amount, currency, shipping terms, and refund policy, all signed by the user's hardware-backed key. It follows the W3C Payment Request API structure, ensuring compatibility with existing web payment infrastructure. This Mandate type is used in human-present scenarios where users provide real-time approval.
Intent Mandate — Pre-Authorizing Delegated Purchases
Consider a different request: "If Beyonce announces a New York show, buy me two tickets under $200 each." The tickets might go on sale while the user is asleep — waiting for real-time approval is not an option.
This is where the Intent Mandate comes in. It pre-defines parameters such as product categories, price caps, expiration timestamps (TTL), and decision criteria, all signed by the user. Within these bounds, the agent can autonomously generate Cart Mandates and complete purchases. The Intent Mandate also includes a "prompt playback" that reproduces the agent's understanding of the user's instructions, enabling after-the-fact verification of what the agent believed it was authorized to do.
The greatest risk in agentic payments is agent runaway. The widely reported case of an OpenAI shopping agent paying $31 for a dozen eggs illustrates this clearly. With an Intent Mandate's price caps and expiration timestamps in place, such incidents are structurally prevented.
Payment Mandate — Signaling the Payment Network
The third type, the Payment Mandate, serves a different role from Cart and Intent Mandates. It signals payment networks and issuers that "this transaction was initiated by an AI agent." It includes a modality flag indicating whether the transaction is human-present or human-not-present, along with evidence links referencing the full Cart/Intent Mandates for dispute resolution.
Issuers and networks use this information for risk assessment. Being able to distinguish between traditional CNP (Card Not Present) transactions and agent-initiated transactions enables both improved fraud detection accuracy and higher approval rates for legitimate agent transactions.
The Full Payment Flow — Seven Steps
How does an actual payment flow work? Here is the human-present flow defined in AP2's technical specification.
The user asks a shopping agent to make a purchase, and the agent obtains an Intent Mandate signature (step 1). The agent discovers merchant endpoints and negotiates a cart (step 2). The merchant finalizes cart contents and signs the Cart Mandate, indicating a fulfillment commitment (step 3).
From here, the payment-specific flow begins. The credentials provider (the entity managing payment methods) supplies tokenized payment options (step 4). The user's device signs both the Cart Mandate and Payment Mandate on a trusted surface (step 5). The agent submits the Mandates, and the credentials provider and merchant process the payment (step 6). Finally, the transaction packet — including Payment Mandate signals — reaches the network/issuer for authorization (step 7).
The critical detail: the agent never accesses raw payment information. Card numbers and CVVs exist only as tokenized credentials. The agent has "execution rights" but no "viewing rights" over payment data.
Positioning Among Other Agent Payment Protocols
AP2 is an "authorization framework," not a payment execution layer. This distinction is key to understanding its relationship with competing protocols.
| Protocol | Developer | Layer | Payment Types | Primary Use Case |
|---|---|---|---|---|
| AP2 | Google + 60+ partners | Authorization framework | Cards, bank transfers, stablecoins | Auditable agent payments |
| ACP | OpenAI + Stripe | Checkout integration | Fiat (cards, bank transfers) | Shopping agent purchases |
| MPP | Stripe + Tempo | Session-based streaming | Stablecoins + fiat | Real-time micropayments |
| x402 | Coinbase | Settlement/execution | Stablecoins only | M2M micropayments |
Stripe's MPP (Machine Payments Protocol), announced in March 2026, specializes in session-based streaming payments. Agents pre-authorize spending limits and continuously stream stablecoins and fiat in real time — well suited for ongoing micropayments like API call billing and data feed charges. Meanwhile, Coinbase's x402 revives HTTP's 402 status code to enable instant stablecoin payments at the protocol level.
Are these competitors? As Crossmint's comparative analysis notes, production systems will likely combine elements of all four protocols. AP2 provides the authorization layer, x402 and MPP handle execution, and UCP standardizes the commerce flow from product discovery to cart assembly. Because they operate at different layers, they coexist as complements rather than competitors.
Ecosystem Momentum — The Revolut Case
Protocol specifications alone do not move real commerce. One reason AP2 commands attention is that concrete implementation partners began moving within four months of its announcement.
In January 2026, Revolut Pay announced AP2 compatibility for the UK and EEA. Revolut contributed directly to the AP2 open protocol, adapting its flows for account-to-account payments. This demonstrates that AP2's Mandate structure works not only with cards but also with direct bank account debits.
American Express's Luke Gebb stated that "with the rise of AI-driven commerce, trust and accountability are more important than ever." The 60+ partner count is not just about numbers. What matters is that the ecosystem spans nearly every layer of the payments stack: card networks (Mastercard, American Express, JCB, UnionPay), payment processors (Adyen, Worldpay), commerce platforms (Salesforce, Shopify, Etsy), and crypto (Coinbase, MetaMask, Ethereum Foundation).
What E-Commerce Merchants Should Know Now
AP2 is not yet available for direct consumer use. The GitHub repository has released v0.1.0 with Python and Android sample implementations, but commercial production deployment lies ahead.
That said, it is not too early for e-commerce merchants to begin preparing. As Everest Group's analysis points out, AP2 integration involves challenges including legacy ERP and procurement system connectivity, PCI-DSS and data residency compliance, and building liability frameworks for agent transaction errors.
The most practical first step is confirming whether your Payment Service Provider (PSP) has an AP2 roadmap. Major PSPs including Adyen, Worldpay, and Revolut are already participating as partners, and as PSP-side AP2 support matures, merchant-side integration burden will decrease significantly. We recommend understanding the full protocol landscape including MCP, A2A, and UCP and building a phased adoption plan accordingly.
Summary
AP2 is a protocol aimed at standardizing authorization for the era when AI agents execute payments. Its payment-agnostic design and ability to function as an extension of A2A and MCP position it as a potentially essential piece of agentic commerce infrastructure. Commercial implementation is still ahead, but the direction signaled by an ecosystem of 60+ partners is clear.
