Wiki · Pattern · Last reviewed June 25, 2026

Agent Payments Protocol (AP2)

Agent Payments Protocol, or AP2, is an open protocol for agent-led payments that uses signed mandate and receipt evidence to bind delegated commerce to user authorization.

Category: Pattern / Agentic Commerce Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AP2, Agent Payments Protocol, agentic commerce, mandates, agents, payments

Definition

Agent Payments Protocol, abbreviated AP2, is an open protocol for agent-mediated commerce. Google Cloud announced AP2 on September 16, 2025 as a shared protocol for payments initiated by AI agents, and the AP2 documentation frames it as interoperable agent commerce infrastructure for developers, merchants, and payment providers. AP2 does not make an agent a bank, wallet, merchant, or legal buyer. It gives payment participants structured evidence that a delegated transaction is authorized.

AP2 belongs to the same terrain as Agentic Commerce, Agent-Native Internet, and x402, but it asks a narrower question: when software acts near checkout, what proves what the user approved, what the cart contained, and what receipt remains afterward?

Mechanism

The current AP2 specification centers on mandates. It defines Checkout Mandates and Payment Mandates. A Checkout Mandate gives the merchant cryptographic proof that a shopping agent is authorized to purchase the assembled checkout. A Payment Mandate gives credential providers, networks, and payment processors proof that the agent is authorized to pay for that checkout. The spec binds mandates to a merchant-signed checkout object using hashes and requires receipts after acceptance or rejection.

AP2 distinguishes human-present and human-not-present modes. In direct mode, the user sees the closed checkout and approves payment explicitly. In autonomous mode, the user approves constraints over a future checkout and payment; the shopping agent later assembles a closed checkout and payment under those constraints. Google's launch post used real-time shopping and delegated tasks, such as buying later when price, timing, or availability conditions are met, to explain the difference.

In April 2026, Google said AP2 v0.2 added human-not-present payment support and that it was donating AP2 to the FIDO Alliance. FIDO said its standards work would address verifiable user instructions, agent authentication, and trusted delegation for commerce, with AP2 and Mastercard's Verifiable Intent as initial technical contributions.

Agent Context

AP2 matters because agents can collapse recommendation, search, cart construction, credential use, and checkout into one workflow. A traditional payment flow assumes a human is directly pressing buy on a trusted surface. An agentic flow may involve a shopping agent, merchant, payment processor, credential provider, trusted surface, and payment network.

The AP2 specification says the trusted surface must be non-agentic and that deterministic code must perform validation and processing for protocol roles. That is a governance signal. A mandate should be a record that other systems can verify without relying on the model's transcript.

Governance Use

For governance, AP2 should be treated as a receipt architecture. A governed deployment should preserve protocol version, mandate schema, checkout identifier, hashes, signers, credential references, payment method class, merchant identity, agent identity, trusted surface, approval time, expiration, constraints, receipt status, dispute path, and any budget or spending policy.

The same record discipline applies when AP2 is adapted into other agent protocols. The Agent Network Protocol 1.1 payment specification describes an ANP application-layer payment protocol based on Google's AP2 and adapted for decentralized agent-network scenarios. That kind of adaptation can be useful, but it also increases the need to label which protocol, identity system, and signature scheme actually governed a transaction.

Limits

AP2 does not decide whether a purchase is wise, neutral, affordable, accessible, lawful, or free of manipulation. A valid signature proves that a particular credential signed a particular record under a particular protocol. It does not prove that the recommendation was unbiased, that the user understood a subscription, that the merchant ranked fairly, or that the product matched the user's unstated needs.

The AP2 security documentation treats agents and LLMs as potential attackers and assumes prompt injection prevention is infeasible. It calls out manipulated checkout, manipulated payment, payment credential theft, manipulated discovery, double spend, and privacy leakage from mandate constraints. Those warnings should stay visible in any implementation. Agent payment records reduce ambiguity, but they do not replace fraud controls, procurement policy, consumer protection, accessibility review, tax records, sanctions screening, refund handling, or human escalation.

Review Record

Source Discipline

AP2 claims should separate protocol specification, sample code, standards-body stewardship, payment-network support, and real deployment. The AP2 docs can support claims about mandate structures and modes. Google and FIDO announcements can support claims about donation and standards work. A repository can support claims about code samples and licensing. None of those sources proves that every AP2 integration is safe, broadly adopted, or legally sufficient.

Spiralist Reading

Spiralism reads AP2 as the receipt layer for delegated desire. The agent may search, negotiate, assemble, and pay, but the moral center of the transaction is not the agent. It is the evidence chain that shows what a person or institution authorized, under which constraints, and how the resulting action can be inspected after the convenience has passed.

The danger is not that the machine becomes mystical. The danger is that checkout becomes so smooth that consent becomes invisible. AP2 is useful when it keeps the handoff legible: intent, cart, payment, receipt, dispute. It is dangerous when the mandate becomes another buried artifact that only the payment stack can read.

Sources

Return to Wiki