AP2: the protocol that authorizes an agent to pay.

A short definition

AP2 (Agent Payments Protocol) is an open protocol that standardizes how a payment triggered by an agent is authorized. Instead of sharing a card number, the agent presents a cryptographically signed proof of authorization. AP2 is the "authorization" building block of the agentic payment layer. Established

The two mandate types in version 0.2

AP2 v0.2 defines two signed proof types bound to the same checkout:

1. Checkout Mandate: proof for the merchant that the agent is authorized to purchase the assembled checkout.
2. Payment Mandate: proof for payment actors that the agent is authorized to pay for that checkout.

Both mandate types can be open, carrying constraints approved in advance, or closed, bound to a specific transaction. AP2 uses them in human-present and autonomous modes. Established

Contribution to the FIDO Alliance

The FIDO Alliance says Google contributed AP2, alongside Mastercard's Verifiable Intent, to its work on a shared trust layer. This describes a contribution to standards work. It does not establish general adoption or production deployment. Emerging

AP2 in the agentic stack

AP2 does not work alone. It combines with the other protocols in the stack:

• UCP and ACP: commerce operations (catalog, cart, checkout). See UCP vs ACP.
• A2A: agent-to-agent communication (stewarded by the Linux Foundation).
• MCP: agents' access to tools and data.
• x402: an HTTP payment protocol used in some AP2 samples; AP2 itself remains payment-instrument agnostic.

UCP is explicitly designed to be compatible with AP2: a merchant preparing its offer for agents builds shared groundwork, whatever the authorization protocol. Established

Two authorization modes

AP2 v0.2 defines a direct mode, where the user approves a closed checkout, and an autonomous mode, where user-signed open mandates constrain what the agent may later approve. Verifiers receive closed Checkout and Payment Mandates in both modes. Established

The specification also keeps catalog APIs, checkout updates, and role-to-role commerce APIs outside its scope. AP2 supplies a security layer; the commerce protocol supplies the journey.

Source: AP2 specification v0.2, checked August 27, 2026.

What it changes for a merchant

For a merchant, AP2 is mainly a trust-and-compliance guarantee: authorization is proven and traceable, and the merchant remains the seller of record. The specification further notes that the Checkout capability adds no PCI DSS compliance obligation for card payments. Established The work to do is the same as for agentic commerce: a machine-readable offer and clear governance. The audit methodology helps assess that state.

One practical point that tends to get missed: the checkout session exposes a status that drives the agent, moving through incomplete, requires_escalation, ready_for_complete, complete_in_progress, completed and canceled. The requires_escalation state is the standardized hand-off to a human. A merchant enforcing an age check, a supporting document, or manual approval above a threshold does not have to step outside the protocol to do it. Established

Frequently asked questions