Google Unveils AP2 — An Open Protocol to Make AI-Agent Payments Verifiable
Why agent-led payments need a new protocol
Autonomous shopping agents can do everything from comparing prices to completing purchases. But when an agent buys a $499 plan instead of a $49 tier, merchants, issuers, and users all face uncertainty: was the user really authorizing that purchase, did the agent act within the user’s intent, and who bears responsibility if something goes wrong? Those unresolved questions block agent-led checkout on today’s payment rails.
What AP2 is and what it solves
Google’s Agent Payments Protocol (AP2) is an open, vendor-neutral specification that adds cryptographic, auditable proof of user intent to agent-initiated payments. AP2 defines a common language so that any compliant agent can transact with any compliant merchant and payment processor. It builds on existing protocols (Agent2Agent, A2A, and Model Context Protocol, MCP) to formalize data, signatures, and message flows across the intent → cart → payment pipeline.
Verifiable Credentials and mandate types
AP2 uses Verifiable Credentials (VCs) to carry tamper-evident evidence through a transaction. The spec standardizes three mandate types:
- Intent Mandate (human-not-present): a user-signed document that specifies constraints under which an agent may act (brands, categories, price caps, timing).
- Cart Mandate (human-present): a merchant-signed cart bound to the user’s explicit approval, creating non-repudiable proof of what the user saw and approved.
- Payment Mandate: metadata for networks and issuers indicating the agent modality (human-present vs human-not-present) and other risk-relevant context.
Together these credentials create an auditable trail linking user authorization to the final charge request.
Roles, boundaries, and privacy
AP2 prescribes role separation to minimize data exposure:
- User delegates a task to an agent.
- Shopping Agent negotiates with merchants and gathers approvals.
- Credentials Provider (wallet) holds payment methods and issues method-specific artifacts.
- Merchant Endpoint provides catalogs and signs carts.
- Merchant Payment Processor builds the network authorization object.
- Network & Issuer evaluate and authorize the payment.
Sensitive data such as PANs and tokens stays with the Credentials Provider and does not need to flow through general-purpose agent surfaces. Mandates are signed by verifiable identities and can include risk signals without leaking full credentials.
Human-present vs human-not-present flows
AP2 describes clear, testable flows:
Human-present: a merchant signs the final cart; the user approves it in a trusted UI and generates a signed Cart Mandate. The processor submits the network authorization with the Payment Mandate and any step-up (e.g., 3DS) happens on the trusted surface.
Human-not-present: a user pre-authorizes an Intent Mandate (for example, ‘buy if price drops below $100’); the agent later converts it into a Cart Mandate when conditions are met, or the merchant can require re-confirmation.
These flows help assign accountability and reduce inference-based disputes.
Integration with A2A and MCP, and payment-method scope
AP2 is an extension of A2A for inter-agent messaging and interoperates with MCP for tool access. AP2 focuses on the payments layer—standardizing mandate objects, signatures, and accountability signals—while allowing A2A/MCP to handle discovery and tool invocation.
The protocol is payment-method agnostic. Initial efforts target pull-based instruments like credit and debit cards, with roadmaps for push transfers (UPI, PIX) and digital assets. For web3, Google and partners published an A2A x402 extension to operationalize agent-initiated crypto payments aligned with AP2 mandates.
Developer experience and reference code
Google published an Apache-2.0 repository with reference docs, Python types, and runnable samples. Samples cover human-present card flows, an x402 variant, and Android digital payment credentials, showing how to issue and verify mandates and move from agent negotiation to network authorization. Core protocol objects are available under src/ap2/types for integration. AP2 is framework-agnostic — any agent stack that can generate and verify mandates can adopt the protocol.
Disputes, determinism, and edge cases
AP2 emphasizes determinism over model inference: merchants receive cryptographic evidence of what the user approved (cart) or pre-authorized (intent), rather than a model-generated summary. The credential chain acts as evidentiary material for networks and issuers; accountability is derived from which mandate was signed and by whom. Issuers or merchants can require step-up authentication, which must be completed on trusted surfaces and linked back to the mandate trail. When multiple agents participate in a flow, A2A coordinates tasks and AP2 ensures each cart is merchant-signed and user-authorized before submission.
Ecosystem and next steps
Google reports collaboration with more than 60 organizations across networks, issuers, gateways, and vendors (for example, American Express, Mastercard, PayPal, Coinbase, Adyen). The goal is to avoid fragmented one-off integrations by aligning on common mandate semantics and accountability signals. The AP2 team plans to evolve the spec openly, add more reference implementations, deepen integrations across networks and web3, and align VC formats and identity primitives with standards bodies. Developers can start by running the samples in the GitHub repo and validating mandate flows against their stacks.
Practical takeaway
AP2 provides a cryptographically grounded evidence trail that connects user authorization to merchant-signed carts and network requests without locking developers into a single stack or payment method. For agent-driven commerce to scale, this kind of verifiable accountability is essential.
Repository and resources: