Agentic Payments: AP2, ACP & the Trust Stack

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 most of them: MCP to find the merchant, a signed HTTP request to prove which agent is calling, UCP or ACP to run the checkout, AP2 to prove the human authorised it, and x402, MPP or card authorization to move the money. Two checkout protocols and two 402-style settlement protocols now coexist; the table shows who backs which.

Decoders for four of these layers live on PayProbe: HTTP Message Signature / TAP, AP2 mandates, x402 headers and SD-JWT credentials.

AP2's mandates: checkout and payment, open and closed

AP2 (Agent Payments Protocol) encodes user authority as verifiable digital credentials: SD-JWT VCs that travel with the transaction. Since v0.2 (28 April 2026) there are two mandate types, each in an open and a closed form:

With the user present, the user signs the closed mandates directly. For autonomous purchases the user signs the open ones; the agent later signs the closed ones as key-binding JWTs whose sd_hash chains them to the open mandate. Only the disclosures relevant to the checkout are revealed. After verifying, the merchant and the payment processor each return a signed receipt. Mandates and receipts together are the dispute evidence.

Paste a mandate or a whole open-to-closed chain into the AP2 Mandate Decoder. It resolves the disclosures and checks the binding, the checkout hash, the agent's signature and the constraints in your browser. The SD-JWT machinery is the same as in EUDI wallet credentials (SD-JWT Decoder).

Version note: the current AP2 release is v0.2 (28 April 2026); there is no v1.0. v0.2 replaced v0.1's IntentMandate, CartMandate and PaymentMandate with the model above; the decoder still recognises v0.1 objects and labels them as superseded. In the FIDO Alliance's Agentic Authentication working group, Google contributed AP2 and Mastercard contributed Verifiable Intent.

Human present: the user signs the closed mandates

The everyday case: the user delegates shopping but approves the final checkout themselves. The shopping agent is kept out of the trust path. The checkout and payment are rendered on a trusted surface outside the agent's control, where the user signs both closed mandates. The credential provider verifies the Payment Mandate and issues a token scoped to this payment, so the agent never sees a raw PAN and stays out of PCI scope.

The merchant checks the Checkout Mandate against its own signed checkout; the payment processor checks that the Payment Mandate's transaction_id matches the same checkout hash. Issuers get agentic traffic they can reason about instead of guessing.

Human not present: open mandates, agent-signed closed mandates

"Buy the tickets when they drop, at most $1000." The user signs open Checkout and Payment Mandates and leaves; the agent completes the purchase later, alone. The safeguards are cryptographic and rule-based:

• Constraints, not prose: the open mandates carry machine-checkable limits (line items, merchants, amount range, payees, budget). Every verifier evaluates them against the closed mandate, and unknown constraint types fail.
• A bound agent key: the open mandate names the agent's key in cnf. Only that key can sign the closed mandate, and sd_hash ties it to the exact open mandate the user approved.
• No double spend: the agent must not present another open mandate until it has an error receipt for the previous one.
• Force-back: if the checkout doesn't satisfy the constraints, the merchant or credential provider returns unresolved_constraint and the user is brought back to approve, which turns the flow into a human-present one.

If the purchase breaks a constraint, the open mandate against the closed one is the dispute evidence: what the user allowed next to what the agent signed.

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.

Agent identity: signed requests before the checkout starts

Before any mandate is exchanged, the merchant has a simpler question: is this HTTP request from a legitimate agent at all? The answer that has won is Web Bot Auth — an IETF httpbis draft profile of RFC 9421 HTTP Message Signatures. The agent signs a set of covered components (authority, path, a timestamp window, a nonce, a tag) with a key it has published in a registry; the receiving CDN or merchant fetches the key and verifies. Cloudflare, AWS WAF, Vercel, Shopify and Akamai already verify it at the edge.

Visa's Trusted Agent Protocol (TAP) builds on it for payments: the signature is bound to the merchant's domain and the operation (browse vs pay), Visa's Agentic Registry confirms the agent is enrolled and not revoked (Know-Your-Agent), and the agent can pass trusted consumer and payment identifiers — including the card's Payment Account Reference — so checkout can be pre-filled. Mastercard Agent Pay adopts the same signature foundation. Paste the headers into the HTTP Message Signature decoder to see the signature base a verifier reconstructs.

What the networks and standards bodies are doing

• Visa Intelligent Commerce — TAP, the Agentic Registry, and at the June 2026 Payments Forum Agent Scoring (agent-specific fraud rules: velocity, mandate-vs-transaction matching, behavioural anomalies) and a "Large Transaction Model". Card-based agent payments ride agent-specific tokens on the existing network tokenization stack; Visa also extended MPP to card payments.
• Mastercard Agent Pay — Agentic Tokens bound to one agent, merchant scope and consent policy, confirmed with Payment Passkeys; Verifiable Intent (pilots from February 2026) proves the reason for a purchase, not just the credential. Live bank-issued transactions so far: Santander (Europe's first, 2 March 2026), Singapore (4 March 2026) and Hong Kong, then in September 2026 Danske Bank (Denmark's first: an agent booked and paid via Priceless.com, confirmed with a Payment Passkey) and Rogers Bank with Flybits (Canada's first, an assistant buying within pre-set spending limits); Agent Pay for Machines (10 June 2026, 30+ partners) extends the programme to agent-to-service payments across cards, bank accounts and stablecoins, interoperating with x402.
• EMVCo — the Agentic Payments Task Force published the draft EMV Agentic Payments — Framework for Specifications on 1 September 2026 (the comment period closed on 30 September; as of 1 October EMVCo has not announced a next draft or publication date). Its core proposal, Intent Services, is a shared, interoperable layer where participants register, reference and manage consumer-authorised intent across recurring purchases and cumulative budgets — complementing AP2 mandates and Verifiable Intent rather than replacing them. Future work may add Know-Your-Agent capabilities and an agentic transaction indicator across 3DS, tokenisation, SRC and the Digital Payment Credential.
• FIDO Alliance — AP2 v0.2 landing at FIDO matters: agent authorization and human authentication (passkeys) are converging into one attestation story.
• Coalitions — the x402 Foundation under the Linux Foundation (April 2026; Visa, Mastercard, Amex, Stripe, Adyen, AWS, Google, Shopify among 22 launch members) owns the x402 spec, and the Agentic Payments Alliance (announced by Rain on 18 August 2026 with Visa, Mastercard, Fiserv, Circle, Solana and Remitly) is a member-run working coalition rather than a spec body.

Practical takeaway for engineers: agent traffic will arrive on rails you already run. Expect new data in authorization (agent-presence signals, mandate references, an agent indicator), new token types, signed HTTP requests at your edge, and dispute processes that consume signed mandates as evidence — not a new network.

Beyond cards: account-to-account agents

The same delegation problem is being solved on instant-payment rails. India's NPCI is building agentic payments into UPI — the world's largest real-time system, 23.7 billion transactions in July 2026 — on top of two mechanisms it already has: UPI Circle (delegated payment authority with limits) and Reserve Pay (funds earmarked for a series of future debits). NPCI unveiled the framework as the Unified Agent Protocol (UAP) at the Global Fintech Fest in Mumbai in September 2026: a user sets spend limits, purchase types and conditions and an agent transacts within them, starting with low-value, high-frequency purchases such as groceries — the rules-based equivalent of an open AP2 mandate, without the cryptographic credential. The delegation caps come from the underlying mechanisms (banks currently cap full UPI Circle delegation at ₹15,000 a month).

In the UK, GoCardless processed the first agentic account-to-account payment on 22 September 2026, inside the FCA's AI Live Testing programme: an agent explained a charity's work, offered monthly donation amounts and set up a Direct Debit mandate without the donor leaving the conversation. The authority here is the Direct Debit mandate itself, an old instrument that already has a scope, a payee and a cancellation right. Expect the EU to face the same question inside the PSD3/PSR SCA rules.

Fraud, scams and who is accountable

Banks are now saying out loud what risk teams expected. In September 2026 six of them (ASB, Bank of America, Capital One, Commonwealth Bank of Australia, ING and NatWest) published joint principles for agentic commerce, warning that risks across transparency, safety, privacy, choice and interoperability grow with agent autonomy. Their asks include mandatory disclosure when an AI agent conducts a transaction, more transparency about how agents decide, and safeguards for customer data.

The attacks to plan for map onto the layers above:

• Impersonated agents: a bot claiming to be a known shopping agent. Counter: verify the signed request (Web Bot Auth / TAP) against the agent's published key directory before trusting anything it says.
• Impersonated merchants and injected instructions: a page or listing that steers the agent to a different payee. Counter: allowed-merchant and allowed-payee constraints in the user-signed mandate, checked by the merchant and the credential provider.
• Over-spend and drift: an agent that buys the wrong thing or too much. Counter: amount-range, budget and recurrence constraints, short mandate expiry, and one open mandate in flight at a time.
• Social engineering of the user: persuading someone to approve a broad mandate. Counter: trusted-surface rendering of exactly what is being delegated, and passkey confirmation (Mastercard Payment Passkeys, FIDO).
• Disputes: "I never authorised that". Counter: keep the mandate chain and receipts. The open mandate shows what the user allowed and the closed one what the agent did.

You can inspect each piece: agent request signatures in the HTTP Message Signature decoder, and mandates, constraints and the agent's signature in the AP2 Mandate Decoder.

Related reading & tools

AP2 Mandate Decoder · AP2 Flow Simulator · HTTP Message Signature / TAP Decoder · x402 Header Decoder · x402 Flow Simulator · SD-JWT Decoder