Home / Wiki / A / Agent Payments Protocol (AP2)

Agent Payments Protocol (AP2)

Financial InfrastructureUpdated 03 Nov 2026

The Agent Payments Protocol (AP2) is an open protocol, announced by Google on 16 September 2025, for letting AI agents start and complete payments on a user's behalf in a way that merchants, payment providers and banks can verify. Its core idea is that every agent-led purchase should carry signed, tamper-evident proof of what the user authorised, so that authorisation, authenticity and accountability can be checked after the fact.

AP2 is payment-agnostic: it was designed to work with credit and debit cards, real-time bank transfers and stablecoins. Google launched it with more than 60 organisations and published it under the Apache 2.0 licence, then donated it to the FIDO Alliance in April 2026. It is often set beside the Agentic Commerce Protocol (ACP) from OpenAI and Stripe, which focuses on the merchant checkout and scoped payment tokens rather than on signed records of intent.

01

The Agent Payments Protocol in plain terms

Think of a parcel that travels with a chain of signed slips. The first slip, signed by you, says what you want and how much you will spend. The second, signed when the basket is agreed, lists the exact items and price. The last tells the bank that a payment is coming and that it was arranged by an assistant, not by you at a keyboard. Anyone along the way can check the signatures and see that nothing was changed.

AP2 is the rulebook for those slips. It does not move the money itself; cards, bank transfers or digital tokens still do that. What it adds is a reliable paper trail, so that if an AI assistant buys the wrong thing, everyone can see whether it followed your instructions or went beyond them.

02

History

Google presented AP2 as an extension of its Agent2Agent (A2A) protocol for communication between AI agents, designed to work alongside the Model Context Protocol that connects agents to tools. Partners named at launch included Adyen, American Express, Ant International, Coinbase, Etsy, Forter, Intuit, JCB, Mastercard, PayPal, Revolut, Salesforce, ServiceNow, UnionPay International and Worldpay. At the same time Google released an A2A x402 extension for agent payments in crypto, developed with Coinbase, the Ethereum Foundation, MetaMask and others.

In January 2026 Google introduced the Universal Commerce Protocol with Shopify, Walmart and other retailers to cover the wider shopping journey; it can rely on AP2 for the payment step. On 28 April 2026 Google released version 0.2 on GitHub and announced that it was giving AP2 to the FIDO Alliance, the body behind passkeys, where work continues in technical working groups on agentic authentication and payments.

03

How it works

AP2 is built around agentic mandates: cryptographically signed records carried as verifiable digital credentials and secured with a digital signature. In version 0.1 there were three, chained together:

  1. Intent Mandate. The user's request and conditions, such as a price limit or deadline.
  2. Cart Mandate. The exact items and price, approved by the user or, under a prior instruction, generated by the agent.
  3. Payment Mandate. Information for the card network and card issuer showing that an agent was involved and whether the user was present.

Version 0.2 restructured these into a Checkout Mandate and a Payment Mandate, each with an open form that sets constraints and a closed form tied to one final checkout and amount. The protocol separates roles so that no single party sees everything: the user's shopping agent, the merchant, a credentials provider that holds payment details, the merchant's payment service provider, and the networks and issuers. Payment details can be passed as tokens, an application of tokenization, so the agent can complete a purchase without handling the raw card number.

04

Human-present and delegated purchases

AP2 supports two modes. In a human-present purchase the user watches the agent assemble a cart and approves it in real time, often with a passkey or other multi-factor authentication. In a human-not-present purchase the user signs instructions in advance, for example to buy tickets the moment they go on sale, and the agent acts later when the conditions are met. Version 0.2 expanded support for this second mode, which is harder for issuers to assess because nobody is present to confirm the payment.

05

Uses and limitations

  • Card payments. Mandates give issuers and merchants extra evidence for risk checks and for resolving chargebacks, though card network rules decide how much weight that evidence carries.
  • Bank and crypto payments. The design extends to real-time payment systems and, through x402, to stablecoin payments between agents and services.
  • Adoption. Partner announcements do not mean live volume. Google gave no usage figures with version 0.2, and many partners also back competing standards, so AP2 must coexist with ACP and others in agentic commerce.
  • Complexity. Verifiable credentials, key management and several separate roles make AP2 heavier to implement than a token-based checkout, which may slow adoption by smaller merchants.

Like other agent payment schemes, AP2 leaves legal questions to existing law, such as whether a purchase outside a mandate counts as unauthorised. Its approach of tying each payment to signed user intent reflects the same thinking behind programmable money: rules attached to the payment itself.

Last updated 03 Nov 2026