Agent Payments Protocol Explained for Retailers 2026

The Agent Payments Protocol (AP2) is an open standard for proving that a shopper authorised an AI agent’s purchase and payment. It records permission in signed mandates, so a retailer can compare the approved checkout with the order the agent submits. Payment approval and dispute decisions still depend on the parties processing that transaction.

What AP2 Does and Who Backs It

AP2 gives shopping agents, retailers and payment providers a shared way to verify purchase authority. Google published the protocol with payments and technology partners. Its launch announcement names Adyen, American Express, Mastercard, PayPal and Worldpay among the participants.

Airwallex also appears in Google’s partner statements. That gives Australian retailers a named payment-provider participant, but participation alone doesn’t establish support for every Australian merchant account or bank.

Google has donated AP2 to the FIDO Alliance, the industry organisation that develops authentication standards. The AP2 documentation describes it as an extension for Agent2Agent (A2A) and the Universal Commerce Protocol (UCP). It can also work alongside Model Context Protocol (MCP).

These protocols handle different parts of an agent purchase. A2A handles communication between agents. UCP handles commerce operations. AP2 supplies signed authorisation within that process. Read the A2A explainer for the messaging layer, or browse the commerce protocol guides to compare their roles.

How Intent and Cart Mandates Work

An intent mandate records the shopper’s permitted task, while a cart mandate records approval of a particular basket. These are the terms in Google’s launch explanation. The v0.2 specification now uses Checkout Mandates and Payment Mandates, each with an open or closed form.

An open mandate records constraints before the agent chooses a final checkout. A closed mandate authorises the specific transaction. The Checkout Mandate specification binds that approval to the merchant’s signed checkout details. A Payment Mandate records authority to pay for it using a permitted payment instrument.

For a hypothetical example, a shopper authorises one order of navy running shoes from a named retailer. They cap the total at AUD $200, including delivery. The agent finds an eligible pair and prepares the following hypothetical checkout proposal.

One pair of navy running shoes, size 9, from the approved retailer. Shoes cost AUD $170 and delivery costs AUD $10. Total payment is AUD $180. Permission applies to this single order using the approved card.

The open Checkout Mandate constrains the retailer and eligible item. The open Payment Mandate carries the spending limit. Once the agent finds a matching checkout, it signs closed mandates under that delegated authority. The merchant verifies the purchase authority, while the payment parties verify permission to pay.

A proposal totalling AUD $205 exceeds the cap. A different retailer also falls outside this permission, even if its price is lower. Those proposals fail the shopper’s conditions.

With the shopper present, the approval surface displays the final checkout and obtains approval directly. With the shopper absent, the agent must act within the signed open mandates. A general chat request to find shoes doesn’t itself provide that payment authority.

Why Mandates Matter for Disputes

Signed mandates give a merchant evidence of the checkout and payment the shopper authorised. They help answer whether the disputed purchase matched that permission. Checkout and Payment Receipts add evidence of how the transaction was processed.

For the hypothetical shoe order, the records let the merchant compare the authorised retailer and item with the submitted checkout. The payment evidence identifies the approved amount and payment instrument. The AP2 FAQ explains that a network adjudicator can use the mandate when assessing transaction accountability.

The specification leaves dispute procedures and evidence-retention requirements outside its scope. A valid signature doesn’t guarantee that a merchant wins a chargeback. Card-network dispute rules and the transaction’s circumstances still determine the result. Retailers must preserve retrievable transaction evidence through their agent and payment-provider arrangements.

What AP2 Means for Your Checkout

AP2 support requires a checkout and payment flow that creates, verifies and returns signed records. Adding an agent chat window alone doesn’t supply those functions.

The implementation guidance assigns the retailer a signed checkout, mandate verification and a signed Checkout Receipt. A retailer can delegate verification to a technology provider. Its processor handles payment verification and returns the Payment Receipt.

The shopping agent creates mandate content and obtains consent through a trusted approval interface. It then presents the appropriate mandates and payment credential, handles receipts and prevents duplicate spending. Verification must use deterministic code: the language model’s interpretation of permission cannot replace it.

AP2 is payment-agnostic. Its initial focus includes credit and debit cards, while the documentation lists real-time transfers such as India’s Unified Payments Interface (UPI) and Brazil’s Pix as expansion paths. The Payment Mandate specification includes a UPI instrument example. Crypto-payment examples use x402.

A listed payment type establishes protocol scope, not automatic acceptance by your gateway. An Australian bank-transfer checkout needs an implementation for its actual payment rail. The guide to agentic payments covers the payment-network context beyond AP2.

When assessing an AP2 checkout integration, establish who verifies each mandate and how you retrieve the receipts for an order. Keep those responsibilities alongside your normal order and payment records. The agentic checkout guide follows the wider purchase flow around this authorisation step.