Agentic Payments: AP2, ACP & the Trust Stack
When an AI agent buys something, every assumption card rails were built on breaks: the "cardholder" is software, card-not-present risk models can't tell a delegated agent from a bot, and "I never authorised this" becomes unanswerable. This guide covers the protocol stack that restores those guarantees — ACP for checkout, AP2 for cryptographic proof of user authority, and the settlement rails underneath, including x402.
The trust problem agents create
Card payments encode decades of assumptions about a human being present: 3DS challenges a person, CVMs verify a person, and dispute rules assign liability based on what a person did or didn't approve. An autonomous shopping agent satisfies none of these. Three questions have to be answerable before issuers can approve agentic traffic at scale:
- Authority — did a real user actually delegate this purchase, with this scope, to this agent?
- Authenticity — is the cart the agent submits the cart the merchant actually offered, at the price offered?
- Accountability — when something goes wrong, is there non-repudiable evidence of who broke the contract: user, agent, or merchant?
Every protocol in this guide is an answer to one or more of these questions. None of them replaces the payment rail — cards still authorize over ISO 8583, stablecoins still settle on-chain. The agentic layers sit on top.
The protocol stack
The protocols are complementary layers, not competitors — one purchase can traverse all of them: MCP to find the merchant, ACP to run the checkout, AP2 to prove the human authorised it, and x402 or card authorization to move the money.
| Layer | Protocol | Who's behind it | What it does |
|---|---|---|---|
| Discovery & tasks | MCP / A2A | Anthropic / Google → Linux Foundation | How agents find tools and exchange tasks (shopping agent ↔ merchant agent). AP2 is defined as an extension of A2A/MCP. |
| Checkout | ACP | OpenAI + Stripe | The checkout handshake: cart negotiation, payment handoff via a shared payment token. Deployed in ChatGPT Instant Checkout. |
| Authorization & trust | AP2 | Google + 60+ partners; v0.2 donated to the FIDO Alliance (April 2026) | Cryptographically signed mandates proving what the user authorised — the accountability layer for both card and crypto payments. |
| Settlement | x402 · card rails | Coinbase / Cloudflare · the networks | Moving the money. AP2's crypto extension is x402; its card path rides normal network authorization with the PaymentMandate attached. |
AP2's three mandates
AP2 (Agent Payments Protocol) encodes user authority as verifiable digital credentials — signed, tamper-evident objects that travel with the transaction. Three mandate types cover the two shopping modalities:
| Mandate | Signed by | What it proves |
|---|---|---|
| IntentMandate | User (up front) | Delegated authority for a future purchase: the natural-language prompt playback, allowed merchants, SKU criteria, budget cap, refundability requirements, and a TTL. An unexpired, in-scope IntentMandate is the agent's only authority to buy in the user's absence. |
| CartMandate | Merchant, then user | The exact cart — items, prices, total. The merchant's signature is a fulfilment commitment at that price; the user's counter-signature (hardware-backed, on a trusted surface) binds them to exactly this cart. Dynamic-linking semantics, the same idea as PSD2 SCA. |
| PaymentMandate | Built by the agent | What the network and issuer see: payment method reference, agent-presence and human-present/not-present signals, linked back to the Intent/Cart mandate that authorised it. |
Paste any of these into the AP2 Mandate Decoder to inspect the structure field by field. The credentials themselves use the same SD-JWT VC machinery as EUDI wallet credentials — decode one in the SD-JWT Decoder.
Human present: the CartMandate path
The everyday case: the user delegates shopping but approves the final cart themselves. The critical design choice is that the shopping agent is kept out of the trust path — the cart is rendered on a trusted surface outside the agent's control, payment credentials go from the credentials provider (wallet) straight to the processor, and the agent never sees a raw PAN, keeping it out of PCI scope.
The issuer receives two always-shared signals with the authorization: an AI agent was involved, and the human was present. Risk systems reason over agentic traffic instead of guessing.
A user delegates shopping to an AI agent but approves the final cart themselves. The merchant signs the exact cart (CartMandate), the user counter-signs it on a trusted surface, and a PaymentMandate carries agent-presence signals to the network/issuer alongside normal authorization.
Shopping Prompt
User delegates the task to the agent in natural language.
"Buy me white running shoes, size 10, under $150." The agent may confirm its understanding back to the user — this playback becomes part of the auditable trail.
Human not present: the IntentMandate path
"Buy the tickets the moment they drop, budget $1000." The user signs an IntentMandate and leaves; the agent completes the purchase later, alone. Two mechanics keep this safe:
- Mandatory intent playback — the agent repeats back what it will buy before the user signs. The playback is part of the signed mandate, so "the agent misunderstood me" is auditable.
- Merchant force-back — the merchant reads the signed intent and decides whether it can fulfil unambiguously. If three seating options all match, it can refuse to guess and pull the user back in-session to sign a CartMandate — converting the flow to human-present.
The issuer sees agent-present + human-not-present — the signal risk teams care most about. If the purchase violates the signed intent (over budget, wrong item), the mandate-vs-cart discrepancy is the dispute evidence, and liability lands on whoever broke the contract — including the agent.
"Buy the tickets the moment they drop, budget $1000." The user signs an IntentMandate up front and the agent completes the purchase later, in their absence — the merchant decides whether the intent is specific enough to fulfil, or forces the user back into session.
Delegated Task
User states the goal, constraints, and budget.
"2 tickets to the Vegas show in July, as soon as they become available, close to the main stage, max $1000."
ACP: the checkout layer
ACP (Agentic Commerce Protocol, OpenAI + Stripe) solves a narrower problem than AP2: letting an agent run a checkout against a merchant. The merchant exposes its catalogue and checkout as a structured API; the agent assembles the cart; payment is handed off via a shared payment token so the merchant charges through its existing processor without the agent touching credentials. It is deployed today in ChatGPT Instant Checkout.
ACP and AP2 meet in the middle: ACP handles the merchant conversation (offers, cart, checkout), AP2 provides the signed proof of user authority that travels with the payment. AP2's spec explicitly names ACP as a compatible checkout layer.
What the networks are doing
- Visa and Mastercard both back AP2 while running their own agentic programmes — Visa Intelligent Commerce and Mastercard Agent Pay — centred on agent-specific tokens riding the existing network tokenization stack.
- EMVCo stood up a Digital Identity and Payments Task Force to work agentic payments into the EMV specifications, alongside its 3DS and SRC work.
- FIDO Alliance — AP2 v0.2 landing at FIDO matters: agent authorization and human authentication (passkeys) are converging into one attestation story.
Practical takeaway for engineers: agent traffic will arrive on rails you already run. Expect new data in authorization (agent-presence signals, mandate references), new token types, and dispute processes that consume signed mandates as evidence — not a new network.
Related reading & tools
AP2 Mandate Decoder · AP2 Flow Simulator · x402 Header Decoder · x402 Flow Simulator · SD-JWT Decoder