Agent Payments Protocol (AP2): What It Is and How It Works

The Agent Payments Protocol (AP2) is an open-source protocol, created by Google, that defines how an AI agent obtains signed, verifiable authorization to initiate a payment on a consumer's behalf. Google announced AP2 in September 2025 and publishes the specification under the Apache 2.0 license in the google-agentic-commerce/AP2 repository and at ap2-protocol.org.

AP2 v0.2 operates as a security feature within a commerce protocol. It is explicitly designed to work with Universal Commerce Protocol (UCP), while catalog APIs, checkout updates, and role-to-role communication remain outside AP2's scope. A2A can connect agents and MCP can connect agents to tools, but neither replaces AP2's mandate verification. ACP is a separate commerce protocol.

In April 2026, Google announced it is donating AP2 to the FIDO Alliance so the protocol stays platform-agnostic and community-led, with core spec work continuing under FIDO governance.

The core abstraction in AP2 is a Mandate: a tamper-evident, cryptographically signed digital credential, issued by or on behalf of the consumer, that scopes what the agent is allowed to do. AP2 defines a small family of Mandate types, including checkout mandates and payment mandates, each with open (constraints and goals before a cart is finalized) and closed (authorization for a finalized checkout or a specific amount) forms. Mandates are chained together to produce a complete, verifiable audit trail.

Open Checkout Mandates can constrain allowed merchants and line items. Open Payment Mandates can constrain allowed payees, amount ranges, budgets, payment instruments, execution dates, and recurrence. The current v0.2 specification recommends a short expiration for autonomous mandates. It does not define a normative dynamic revocation mechanism, so expiry and constraints should not be described as revocation.

This addresses a foundational trust question in agentic commerce: how does a merchant, credential provider, network, or processor verify that the agent had the consumer's authorization and stayed within scope? AP2 assigns deterministic verification duties to those roles. See Agent Mandate for the concept on its own.

AP2 is a payments-authorization layer, not a checkout protocol and not a payment rail. It is designed to compose with the other standards: an agent might use A2A to talk to another agent, UCP or ACP to transact with a merchant, and AP2 to carry the signed authorization that the payment network verifies. Mastercard's published relationship to AP2 is a co-developed, AP2-compatible companion standard called Verifiable Intent, also being donated to the FIDO Alliance, not co-ownership of AP2. Visa is not listed as an AP2 contributor in the primary sources.

AP2 is in early open development, not generally available. The published releases are versioned before 1.0: v0.1.0 in September 2025 and v0.2.0 in April 2026, the latter focused on "human not present" payment flows. Because the specification is still draft, field names, required arrays, and authorization semantics can change between minor versions.

Initial support covers "pull" card payments. The published roadmap includes e-wallets, push payments (such as UPI and PIX), and digital currencies. No fee schedule is published in the primary sources.

Treat any specific partner-count, pilot, or live-transaction claim with caution unless it comes from a current Google or FIDO Alliance primary source. The protocol's own materials position it as a specification and reference implementation under active development.

AP2 v0.2 assigns the Merchant a direct duty to receive and verify the Checkout Mandate before completing checkout. The Merchant checks the mandate, the hash of its signed checkout, and any open-mandate constraints. Credential providers and networks verify Payment Mandates, while merchant payment processors verify that the payment credential is scoped to the checkout.

A merchant may delegate its verification work to a technology provider such as a payment processor. Delegation changes who performs the checks, not the verification rules attached to the Merchant role. On Google's AI surfaces, the official guidance is to use UCP for merchant commerce and add the AP2 extension for autonomous purchase scenarios where an agent buys while the user is absent.

Paz supports the product-data work that precedes an AP2 transaction: catalog readiness, human-reviewed optimization, supported feed distribution, and visibility monitoring. Payment authorization and processing remain with the merchant's commerce and payment providers.