AP2 Explained: The Agent Payments Protocol

The Agent Payments Protocol (AP2) tackles the hardest question in agentic commerce: when a piece of software buys something for you, how does a merchant or bank know you actually authorized that specific purchase, and who is liable if it goes wrong? AP2 is the payment-authorization and trust layer, not a checkout or discovery protocol.

Who is behind it, and the move to FIDO

AP2 was announced by Google on 16 September 2025, presented as the work of a diverse group of “more than 60 organizations” and licensed under Apache 2.0. Named partners in the announcement included Mastercard, American Express, PayPal, Coinbase, Adyen, Worldpay, Salesforce, Intuit, JCB, and UnionPay International, among others. Two notable absences: Visa and Stripe, both of which have pursued their own approaches.

The governance has since shifted. In April 2026, Google donated AP2 to the FIDO Alliance, where the specification now advances through industry working groups, including a Payments group chaired by Mastercard and Visa and a new Agentic Authentication group. Google still maintains the reference implementation and SDKs, but the normative standard is moving into a neutral body. So calling AP2 “a Google protocol” today is imprecise: it originated at Google and is now under FIDO stewardship.

The mandate model

The core idea is a mandate: a cryptographically signed, tamper-evident verifiable credential that captures authorization in a way a merchant or network can verify and later use as dispute evidence. The exact model has evolved, and it is worth knowing both versions because secondary write-ups often quote the old one as if it were current.

The original (v0.1) model used three mandates. An Intent Mandate captured the user’s high-level instructions and constraints, such as a category, a price ceiling, and timing, and was used especially for purchases made when the user is not present. A Cart Mandate captured the finalized cart, the exact items and amount, signed by the user for purchases made when they are present. A Payment Mandate was shared with the network and issuer to signal that an agent was involved and whether a human was present.

The current (v0.2) model reorganizes this into verifiable digital credentials with two primary types, each having an open and a closed stage. A Checkout Mandate covers pre-cart constraints (open) and authorization of a finalized cart (closed). A Payment Mandate covers instrument and budget constraints (open) and authorization of a specific amount bound to a finalized checkout (closed). If you describe the older “Intent, Cart, Payment” framing, label it as the launch model.

Across both versions the mechanism is the same: signatures use hardware-backed device keys with in-session authentication, and the chain from intent through cart to payment forms a non-repudiable audit trail used for authorization, authenticity, and resolving disputes. For the credential structure, the SD-JWT signing and verification, and a worked SDK example, see AP2 mandates in practice.

How it relates to the other standards

AP2 is built as an extension of A2A, the agent-to-agent protocol, and is positioned to work with MCP as well. For the commerce side of a transaction, Google pairs AP2 with its Universal Commerce Protocol (UCP): AP2’s own FAQ describes UCP as orchestrating the broader purchase lifecycle while AP2 is the specialized layer that authorizes and signs the payment. For how AP2 compares with the card networks’ own agent-payment programs, see AP2 vs network tokens.

For crypto and machine-to-machine payments, Google built the A2A x402 extension with Coinbase, the Ethereum Foundation, and MetaMask, aligning AP2 with the x402 stablecoin approach. Regarding ACP, the OpenAI and Stripe checkout standard, no primary AP2 source mentions it directly; the popular “AP2 versus ACP” framing comes from commentary rather than the standards bodies themselves.

Status and honest limitations

As of mid-2026, AP2 is best understood as pre-production. Primary sources describe reference implementations, SDKs, and sample scenarios that mock real payment providers, not documented live, real-money deployments. With the standard now mid-flight into FIDO, the normative spec is early-stage and actively in committee.

The primary materials are also candid about open problems. Trust bootstrapping is unsolved: in the short term, knowing which agents and credential providers to trust relies on manually curated allow-lists rather than a scalable real-time framework. The liability guidance Google published is explicitly a helpful guide, not a binding contract, so actual liability still depends on each network’s rules. And payment-type coverage is partial: cards are supported, stablecoins are handled through the x402 extension, but real-time bank transfers and recurring payments are on the roadmap rather than shipped.

What it means for you

If you are a merchant or a payments team, AP2 is the leading candidate for the authorization-and-trust layer, and its move to FIDO makes it more likely to become a genuine cross-industry standard rather than one vendor’s framework. If you are a builder, treat AP2 as the proof-of-authorization layer that sits underneath a checkout protocol, and watch the FIDO working groups for where the spec actually lands. Either way, do not assume it is in production yet.

FAQ

Is AP2 still a Google protocol? It originated at Google in September 2025, but Google donated it to the FIDO Alliance in April 2026, where the spec is now developed. Calling it simply a Google protocol is out of date.

What is a mandate? A cryptographically signed verifiable credential that records authorization. The model moved from Intent, Cart, and Payment mandates to a Checkout Mandate and a Payment Mandate, each with open and closed stages.

Does AP2 compete with ACP? They sit at different layers, authorization versus checkout. The standards bodies do not frame them as rivals, though Visa and Stripe are absent from AP2’s partners.