Google AP2: The AI Agent Payments Protocol Explained
Google's AP2 is an open protocol that lets AI agents make payments on behalf of users, securely, with cryptographic proof of intent. Here's how it works.
Key takeaways
- AP2 is a trust layer. It verifies that an AI agent has explicit user authorization before a transaction happens.
- The Mandate system is the core mechanism. Intent, Cart, and Payment Mandates form a cryptographically signed chain that proves what the user authorized, what was selected, and what was charged.
- AP2 is protocol-agnostic by design. It works alongside A2A (agent communication) and MCP (tool access) without duplicating their roles.
- Payment-method neutrality is a deliberate choice. AP2 supports cards, bank transfers, stablecoins, and crypto via the x402 extension.
- Accountability gaps remain unresolved. AP2 creates audit trails but does not yet define who is liable when an agent executes a wrong or fraudulent transaction.
Google's Agent Payments Protocol (AP2) is the first serious open standard for AI agents to make purchases on behalf of humans, combining cryptographic authorization with full payment-method flexibility across cards, bank transfers, and stablecoins.
Before AP2, there was no reliable way for a merchant, a card network, or a bank to tell the difference between a human clicking "buy" and an AI agent doing it on someone else's behalf. AP2 was built to close that gap, and the structure it introduces will likely shape how autonomous commerce works for years ahead.
What Is Google's Agent Payments Protocol (AP2)?
| Quick answer: AP2 is an open protocol that enables AI agents to initiate and complete payments on behalf of users, with cryptographic proof that the user actually authorized each transaction. |
Announced on September 16, 2025, AP2 was developed by Google alongside a coalition of over 60 payments and technology organizations. Launch partners included Mastercard, PayPal, American Express, Coinbase, Adyen, Salesforce, Shopify, Etsy, and Worldpay, a breadth that positioned AP2 as a cross-industry standard rather than a single-vendor product.
The protocol operates as an extension of two existing open protocols:
- A2A (Agent2Agent): Google's protocol for agent-to-agent communication
- MCP (Model Context Protocol): Anthropic's standard for tool and data access
AP2 sits between those layers and the payment networks, adding the authorization logic that neither A2A nor MCP was designed to handle.
A note on scope: AP2 does not move money. It establishes whether a transaction is authorized and creates the evidence trail for every step. The actual payment (whether by card, bank transfer, or stablecoin) still happens through existing rails. This distinction matters because it means AP2 can support any payment method without replacing any of them.
Why AP2? The Problem It Solves
| Quick answer: The core problem is that every payment system ever built assumed a human was the one clicking "buy." AI agents break that assumption, and no existing infrastructure had a way to handle it. |
When an AI agent purchases on your behalf using stored credentials, today's payment networks cannot tell whether you authorized that specific transaction or whether the agent acted outside your instructions. Three questions have no good answer in the current system:
- Authorization: How does a merchant verify the agent was actually permitted to make this purchase?
- Scope: How does anyone confirm the agent didn't exceed the user's original instructions?
- Accountability: If something goes wrong, who is responsible? The user, the developer, the merchant, or the platform?
Without a shared protocol, each platform would build its own solution. The result would be a fragmented ecosystem; expensive for merchants, confusing for users, and unmanageable for financial institutions trying to assess and monitor risk.
AP2 proposes a common language that any compliant agent, merchant, or payment provider can use, so the trust infrastructure doesn't have to be rebuilt from scratch every time.
How AP2 Works: The Mandate System
| Quick answer: AP2 builds trust through a system of cryptographically signed digital contracts called Mandates, each one creating a tamper-proof record of what the user authorized at every stage of a transaction. |
What Is a Mandate?
A Mandate is a structured digital object, signed using ECDSA (a standard cryptographic signature algorithm), and formatted as a W3C Verifiable Credential. It cannot be altered after signing. It can be verified by any party in the transaction chain (the merchant, the payment network, the card issuer) without relying on a central authority.
Think of it as a permission slip that is mathematically impossible to forge or retroactively change.
Author's note: The mandate system shifts where accountability lands when something goes wrong. In current agent workflows built on stored credentials, a disputed transaction leaves the user with little to show. There is no structured record of what they originally instructed, what the agent selected, or whether the final charge matched the approved cart. A signed mandate chain changes that. Each step produces a verifiable artifact that any party in the chain can inspect. For users, that means a concrete basis for dispute. For merchants and issuers, it means a shared evidence trail rather than conflicting claims. The value is more about having a clear record when they happen.
The Three Types of Mandates
Mandate | When it's created | What it records |
| Intent Mandate | User gives the agent an instruction | The user's original goal, scope, and constraints (e.g., "find running shoes under $120") |
| Cart Mandate | User approves the agent's selection | The exact items, quantities, and prices to be purchased, locked and signed |
| Payment Mandate | Used in human-not-present flows | A pre-authorized permission for the agent to transact within defined limits, shared with networks and issuers |
Each Mandate is signed by Verifiable Credentials (VCs), cryptographic objects that confirm the identity and authorization of each party in the chain.
The Transaction Flow
A standard AP2 transaction moves through this sequence:
User instruction
↓
Intent Mandate (signed by user)
↓
Agent searches, selects, presents options
↓
Cart Mandate (signed by user on approval)
↓
Payment executes via chosen rail (card/bank /stablecoin)
↓
Cryptographic audit trail (non-repudiable record of all steps)
In human-not-present scenarios, where a user has pre-authorized an agent to act autonomously within set parameters, the Payment Mandate replaces the need for step-by-step approvals, while still maintaining verifiable bounds on what the agent can do.
AP2 vs. A2A vs. MCP: How They Fit Together
AP2, A2A, and MCP are complementary protocols. Each owns a distinct layer of an agentic stack, and none of them duplicates the others.
A useful way to think about the split:
Protocol | Who developed it | What it handles |
| MCP | Anthropic | Tool discovery and data access: how an agent finds and uses external resources |
| A2A | Agent-to-agent communication: how agents talk to each other across platforms | |
| AP2 | Google + 60+ partners | Payment authorization: cryptographic proof that a user authorized a specific transaction |
AP2 does not replace A2A or MCP. It inserts an authorization layer between them and the payment networks. A complete agentic commerce stack uses all three:
- MCP to access product catalogs and merchant data
- A2A to coordinate between a user's agent and a merchant's agent
- AP2 to carry the signed authorization when money needs to move
A real-world example: The PayPal + Google Cloud Conversational Commerce Agent, launched October 27, 2025, runs exactly this stack. Google ADK for agent logic, MCP for merchant data, A2A for inter-agent messaging, and AP2 mandates for payment authorization.
AP2 and Crypto Payments: The x402 Extension
| In short: AP2 is payment-method agnostic by design. It works with credit cards, bank transfers, and real-time payments. The x402 extension adds native support for crypto and stablecoin rails on top of that foundation. |
The x402 extension was developed in collaboration with Coinbase, the Ethereum Foundation, ConsenSys, and MetaMask. It extends AP2's core mandate structure to handle:
- Stablecoin transfers (USDC and others)
- On-chain settlement with cryptographic receipts
- Programmable refunds and micro-settlements
- Machine-to-machine payments at sub-cent increments
For Web3 builders, x402 makes AP2 directly relevant. It is a production-ready path for agents to transact on-chain under verifiable authorization, without each project needing to build its own trust infrastructure.
It is worth noting that x402 is an extension, not a requirement. Merchants and developers who work exclusively with traditional payment methods can adopt AP2 without touching crypto at all.
AP2 Use Cases: From Shopping to Enterprise Procurement
| In short: AP2's mandate architecture is flexible enough to cover three distinct transaction models: human-present purchases, delegated autonomous buying, and machine-to-machine payments. |
- Consumer shopping (human present): A user asks their agent to find white running shoes under $100. The agent captures an Intent Mandate, searches across merchants, and presents options. The user approves a cart, signing a Cart Mandate. Payment executes. The user never visited a website.
- Delegated purchasing (human not present): A user sets a standing instruction: "Buy concert tickets for any show I've starred in my calendar, up to $200 each." The agent monitors availability and executes purchases autonomously within those parameters, each transaction backed by a pre-signed Payment Mandate.
- Coordinated multi-vendor booking: A user sets a $700 budget for a weekend trip. The agent negotiates with both an airline agent and a hotel agent, finds a combination within budget, and executes both bookings simultaneously with cryptographically signed confirmations.
- Enterprise procurement: A procurement agent automatically scales software licenses based on real-time usage, or purchases partner-built solutions via a marketplace, without requiring a human approver for every transaction, while maintaining a full audit trail for compliance.
- Machine-to-machine (M2M) payments: AI services can pay for API calls, inference compute, or data access in real time, at sub-cent granularity, using x402 stablecoin rails, enabling a functioning market for agent-to-agent service transactions.
Limitations and Open Questions
| In short: AP2 solves the authorization problem well. It does not yet solve accountability, compliance alignment, or adversarial risk, and those gaps matter for real-world adoption. |
1. Liability is unresolved
AP2 creates a clear audit trail showing what was authorized and what happened. But it does not define who is responsible when an agent executes an incorrect or fraudulent transaction. Is it the user who set the mandate? The developer who built the agent? The merchant? The protocol itself? This question remains open and will likely require industry rules, and possibly regulation, to settle.
2. Regulatory alignment is pending
AP2 improves traceability, but it must still be reconciled with PCI-DSS requirements, data residency laws, and anti-money laundering obligations. Without that alignment, adoption in financial services and other regulated sectors could be slow regardless of technical merit.
3. Adversarial risks exist
Malicious or compromised agents could exploit AP2's automation to push unwanted transactions or manipulate mandates in ways that appear compliant. The protocol's cryptographic guarantees protect against tampering after signing; they do not protect against a bad-faith actor who controls the signing process.
4. Fragmentation risk remains
Visa has its own Trusted Agentic Payment initiative (TAP), and Mastercard has its Agent Pay Acceptance Framework. These are designed to be interoperable with AP2, but the ecosystem is not yet unified. Multiple competing approaches could limit the "common language" benefit AP2 was built to deliver.
Who Needs to Pay Attention to AP2?
| In short: AP2 is relevant to anyone building on, selling through, or regulating systems where AI agents handle money, which is a much broader group than it might initially seem. |
- Developers: Building payment features into AI agents or agentic workflows; AP2 provides the authorization layer you would otherwise need to design yourself.
- Merchants and e-commerce platforms: Preparing for a future where a significant share of purchases are initiated by agents rather than humans directly.
- Payment processors and card networks: Integrating AP2 support to remain relevant as agentic commerce scales.
- Enterprise IT and procurement teams: Evaluating autonomous purchasing workflows that need audit trails for compliance.
- Web3 and crypto builders: For whom the x402 extension opens a path to mainstream agentic commerce without needing to build trust infrastructure from scratch.
- Regulators and compliance professionals: Who will need to define liability, dispute resolution, and fraud monitoring frameworks for transactions where no human was present at the point of purchase.
Sources and Further Reading
- Google Cloud Blog – "Announcing Agent Payments Protocol (AP2)" https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
- AP2 Protocol – Official Documentation https://ap2-protocol.org/
- GitHub – google-agentic-commerce/AP2 (Official Specification & Reference Implementations) https://github.com/google-agentic-commerce/AP2
- Google Developer Forums – "Agent Payments Protocol (AP2): An Open and Secure Standard for Agentic Payments" https://discuss.google.dev/t/new-agent-payments-protocol-ap2-an-open-and-secure-standard-for-agentic-payments/265614
- W3C – "Verifiable Credentials Data Model" https://www.w3.org/TR/vc-data-model/
FAQs About Google AP2 Protocol
Yes. The protocol supports coordinated transactions across multiple merchants in a single flow, for example, booking a flight and a hotel simultaneously under one user-authorized budget. Each merchant interaction generates its own signed records, but they can be coordinated by a single agent acting under one overarching mandate.
