What Are AP2 Mandates? The Beginner’s Guide to Verifiable AI Payments

When an AI agent spends a user's money, a quiet question hides behind every transaction: who can prove the user actually authorized this purchase?

The Agent Payments Protocol (AP2) is Google's answer. Its core primitive — the Mandate — is a cryptographically signed credential that encodes exactly what a user agreed to. This guide walks through what Mandates are, the three types, how the flow works, and when they matter for the agent commerce stack you are building.

What is an AP2 Mandate?

An AP2 Mandate is a signed, verifiable digital credential that captures a user's payment authorization in a tamper-proof object. The agent carries it through the transaction. Any party — merchant, payment network, auditor — can verify cryptographically that the user consented to a specific action under specific constraints.

Think of it as the difference between "the agent paid with a saved card" and "here is a signed record proving the user approved this exact purchase, for this exact amount, with this exact agent, at this exact time."

AP2 was announced in early 2026 and is backed by 60+ partners including Mastercard, American Express, PayPal, Adyen, Coinbase, MetaMask, Revolut, and Worldpay. The spec lives at ap2-protocol.org.

Why Mandates exist

Today, when an agent makes a purchase, the authorization trail typically looks like this:

1. Agent holds an API key or a funded wallet
2. Agent calls a merchant and presents credentials
3. Merchant charges the credentials
4. Nobody has a cryptographic record linking the user's actual intent to the specific charge

For a $2 API call, that is fine. For a $500 corporate gift, a recurring subscription, or a procurement order at scale, the lack of verifiable consent becomes an enterprise, compliance, and chargeback problem. "The agent did it" is not a satisfying answer in an audit.

Mandates fix this by turning user consent into a first-class, verifiable object.

The three types of Mandates

AP2 defines three Mandate types, each for a different trust model.

Intent Mandate

A pre-authorization. The user signs once that a specific agent may spend within a scope.

• Spending limit (e.g., $100/week)
• Category constraints (e.g., "groceries only")
• Time window (e.g., "valid for 30 days")
• Agent identity

Example: "My shopping agent can spend up to $500 on office supplies for the next quarter." The agent acts inside the scope without re-prompting.

Cart Mandate

Approval for a specific transaction. The user reviews and signs the exact cart.

• Items and quantities
• Exact prices
• Merchant identity
• User signature with timestamp

Example: The agent presents a $47.89 cart of three items. The user signs. The merchant now has cryptographic proof the user approved those exact items.

Payment Mandate

Sent to the payment network alongside the charge. References the Intent and Cart Mandates so the network can verify the full authorization chain and apply fraud scoring tailored to agent-initiated transactions.

How the Mandate flow works

Two modes.

Human-present: Agent assembles a cart → user signs Cart Mandate in real time → agent submits to merchant with Payment Mandate → merchant verifies signatures and processes.

Human-not-present (delegated): User signs Intent Mandate upfront → time passes → agent assembles a cart within the Intent's scope → submits Cart + Payment Mandates → merchant verifies the Intent is still valid and the cart fits its scope.

The cryptographic chain lets any party verify: a real human signed the Intent, the Cart is within scope, the agent is the one authorized, and the payment matches.

Where AP2 fits (and where it stops)

AP2 is an authorization layer. It does not move money, and it does not place orders. Those are separate problems:

• ACP (Stripe + OpenAI) handles checkout at participating merchants
• MPP / x402 handle HTTP 402–based machine payments
• Execution infrastructure places orders at retailers that don't support any protocol

In practice, AP2 composes naturally with the rest of the stack. A signed Payment Mandate can ride alongside an ACP checkout call, an MPP 402 exchange, a traditional Stripe charge, or an execution-layer API call.

For physical goods commerce at major retailers — Amazon, Walmart, Target, Best Buy — AP2 authorization pairs cleanly with an execution layer like Zinc API, which handles programmatic ordering across 50+ retailers through a single API. The agent carries the Mandate; the execution layer places the real order. The full audit trail — signed intent, specific cart, placed order, carrier tracking — stays verifiable end to end.

When should you use Mandates?

Use AP2 if:

• You need verifiable audit trails for enterprise or regulatory compliance
• Your agents span multiple merchants and payment rails
• You want cryptographic proof for chargeback defense
• You build multi-agent systems where authorization must flow through agent-to-agent hops

Skip AP2 if:

• Your agents operate inside a single payment ecosystem with built-in controls
• Use cases are low-stakes and don't require audit trails
• You cannot commit to managing signed credentials in your runtime yet

A common path: start simpler (API keys, pre-funded wallets, PSP-level controls), and add AP2 when compliance or scale demands it.

Bottom line

AP2 Mandates turn "did the user authorize this?" from a he-said/she-said into a cryptographic question with a verifiable answer. There are three types — Intent, Cart, Payment — each for a different trust moment.

For serious agentic commerce, authorization is only one layer. Pair AP2 with a checkout protocol for merchant transactions, a machine payment protocol for services, and an execution API for retailers that don't speak any of these standards. The layers compose; none of them replaces the others.