Agent Payments Protocols Guide: AP2, Agent Tokens, x402

When an AI agent pays, the merchant, the issuer and the network can no longer assume that the party pressing "buy" is the cardholder, or that it is buying what the cardholder wanted. A new set of protocols tries to close that gap with signed mandates, agent-bound payment tokens and signed agent requests. This guide goes one level below the business view: it explains how the Agent Payments Protocol (AP2) mandates are built and verified, how card network agent tokens and payment instructions constrain a credential, where x402 and delegated vault tokens fit, and which checks fraud, payments and security teams should implement. It is written for payment risk teams, merchant engineers and security architects. For the wider identity model and the list of initiatives, see the Agentic Commerce Identity Guide; this page does not repeat it.

Key takeaways

Treat the agent as a potential attacker. The AP2 specification states that preventing prompt injection is infeasible and that all LLMs and agents must be considered potential attackers, so every check that matters must run in deterministic code outside the model.
Bind three things cryptographically. A safe agent payment links the user's consent, the exact checkout and the payment credential: AP2 does it with a Checkout Mandate, a Payment Mandate and a shared checkout_hash.
Constrain the credential, not just the agent. Agent-specific tokens (Visa Intelligent Commerce tokenisation, Mastercard Agentic Tokens, ACP delegated vault tokens) should only work for the merchant, amount and time window the user approved.
Autonomous mode is where fraud risk concentrates. In "Human Not Present" flows the agent signs the final mandate itself, so the open mandate's constraints, expiry and double-spend rules are the only brake.
Keep the evidence. Signed mandates and receipts are designed to support disputes, but retention and retrieval are outside the AP2 specification, so each party must decide what it stores and for how long.

The protocol landscape by layer

Agent payment protocols are not competitors for one slot. They work at different layers, and a single purchase may touch three or four of them. Knowing the layer tells you which team owns the control.

Layer	Protocol or programme	What it proves or controls	Primary verifier
Agent request identity	Visa Trusted Agent Protocol; IETF Web Bot Auth (HTTP Message Signatures, RFC 9421)	That a request comes from a known agent key, for this site and this operation	Merchant, CDN or bot management layer
User authorisation	AP2 Checkout and Payment Mandates; Verifiable Intent (Google and Mastercard)	What the user approved, with which limits, and whether a human was present	Merchant, credential provider, network, processor
Payment credential	Visa Intelligent Commerce tokenisation; Mastercard Agentic Tokens; ACP delegated vault token	That the credential is specific to the agent and usable only within set limits	Issuer, network, token service, PSP
Checkout and commerce flow	Agentic Commerce Protocol (ACP); Universal Commerce Protocol (UCP)	Catalogue, cart and checkout exchange between agent and merchant	Merchant platform
Machine-native settlement	x402 (HTTP 402 Payment Required)	Per-request payment for an API or resource, usually with stablecoins on-chain	Resource server and facilitator

Status matters: AP2 v0.2.0 was released on 28 April 2026 and Google has donated it to the FIDO Alliance; ACP describes itself as beta; Visa's developer pages say Intelligent Commerce is still in development and may not be available in all markets; Web Bot Auth is an IETF working group Internet-Draft. Track changes in the Agent Identity Standards Tracker.

How AP2 mandates work

AP2 is a security layer that sits inside a commerce protocol; the catalogue and checkout APIs are out of its scope. It defines five roles, and a single company can hold several of them.

Shopping Agent (SA): finds products, builds the checkout and runs the purchase. It is expected to be agentic, which means non-deterministic and untrusted.
Trusted Surface (TS): the interface that shows the mandate to the user and collects consent. The specification says this role MUST be non-agentic. In practice it is a wallet screen, an operating system prompt or a deterministic part of the agent provider's app.
Credential Provider (CP): the wallet or issuer side that releases a scoped payment credential only after verifying the Payment Mandate.
Merchant (M): issues a merchant-signed Checkout JWT, verifies the Checkout Mandate and returns a signed Checkout Receipt.
Merchant Payment Processor (MPP): checks that the payment credential is scoped to this checkout and returns a signed Payment Receipt.

Mandate types and binding

Mandate	`vct` value (closed / open)	Verified by	Binding
Checkout Mandate	`mandate.checkout.1` / `mandate.checkout.open.1`	Merchant	`checkout_hash` of the merchant-signed Checkout JWT
Payment Mandate	`mandate.payment.1` / `mandate.payment.open.1`	Credential provider, network, processor	`transaction_id` carries the checkout hash; open mandates use the `payment.reference` constraint

Mandates are SD-JWTs (Selective Disclosure for JWTs, RFC 9901), chained using a Delegate SD-JWT individual draft. Implementations must match the vct string exactly, including the version suffix, so a schema change cannot be silently accepted. User delegation can use OpenID for Verifiable Presentations with a user credential, or a "Trusted Agent Provider" model in which the provider signs mandates on the user's behalf after consent; in that model the provider MUST ensure the agent cannot reach or use the signing key without the Trusted Surface.

Human Present and Human Not Present

Human Present (direct): the user sees the final ("closed") checkout and signs both mandates on the Trusted Surface. Because the user saw the exact basket, the specification notes this can often be replaced by an ordinary e-commerce journey.
Human Not Present (autonomous): the user signs "open" mandates containing constraints and the agent's public key in a cnf claim. When the agent finds a matching checkout it signs the closed mandate with that key. Verifiers receive both and check that every constraint holds. The specification recommends setting exp on open mandates to the smallest value that lets the agent finish the task.

Constraint types defined in v0.2

Constraint	What it limits	Fraud control it supports
`payment.amount_range`	Minimum and maximum amount, in a currency	Per-transaction spending cap
`payment.budget`	Total spend across closed mandates linked to the open one	Cumulative cap for recurring or multi-step tasks
`payment.agent_recurrence`	How many closed mandates may be created	Limits repeated charges
`payment.allowed_payees`	Which payees may receive funds	Blocks redirection to a different beneficiary
`payment.allowed_payment_instruments`	Which instruments, such as a card or UPI	Prevents switching to a riskier instrument
`payment.allowed_pisps`	Which payment initiation service providers	Restricts account-to-account initiation paths
`payment.execution_date`	When the payment may execute	Stops stale or premature execution
`payment.reference`	Links the open Payment Mandate to its checkout	Prevents reuse against an unrelated checkout
`checkout.allowed_merchants`, `checkout.line_items`	Which merchants and items	Bounds what a manipulated agent can buy

Two rules carry most of the safety: any unknown constraint MUST be treated as failing (verifiers return unresolved_constraint), and a Shopping Agent MUST NOT present a further closed mandate under the same open mandate until it has a rejection receipt for the previous one. That second rule is AP2's double-spend control, and the specification adds that those receipts must be integrity protected from the agent's LLM. Credential providers, networks and processors may also reject overlapping mandates or invalidate earlier tokens.

Card network agent tokens and payment instructions

Card networks approach the same problem from the credential side: instead of a primary account number (PAN) shared with an agent, the agent receives a token whose use the network can police at authorisation time.

Visa Intelligent Commerce: Visa's developer page lists five services. Tokenisation provides an agent-specific token that Visa provisions and manages. Authentication performs step-up cardholder verification and sets up a passkey that authenticates later Payment Instructions. Payment Instructions checks that credential requests match the user's authenticated instruction and that authorisations arriving at VisaNet match the original instruction, including the intended merchant and amount. Signals collects the original instruction and purchase details to help resolve disputes. Personalisation lets agents request user insights only with consent.
Visa Trusted Agent Protocol: agents sign requests to merchants with RFC 9421 HTTP Message Signatures covering @authority and @path, with created, expires, nonce, keyid and a tag that distinguishes browsing (agent-browser-auth) from paying (agent-payer-auth). With consumer consent it can pass identifiers such as a Payment Account Reference (PAR) for a card on file.
Mastercard Agent Pay: announced on 29 April 2025 as an agentic payments programme built on Mastercard Agentic Tokens, which extend existing tokenisation. Mastercard states that agents will have to be registered and verified before they can pay, and that consumers control what an agent may buy. With Google, Mastercard co-developed Verifiable Intent, a tamper-evident record of user-authorised agent actions that has also been contributed to the FIDO Alliance.
ACP delegated payment: the Agentic Commerce Protocol, maintained by OpenAI and Stripe, issues a delegated vault token that the merchant's PSP may use only within an Allowance of reason, max_amount (minor units), currency and expires_at. Requests require an Idempotency-Key, and a detached Signature with a Timestamp is recommended.

The common design principle: the credential should fail closed outside the approved merchant, amount and time window, even if the agent is fully compromised. See the Tokenisation and Data Masking Guide for token design in general.

x402 and machine-native payments

x402 revives the HTTP 402 Payment Required status code for per-request payments, mostly by agents paying for APIs and content. It is now governed under the x402 Foundation repository, and its principles say it is network, token and currency agnostic.

The client requests a resource; the server replies 402 with a base64 PaymentRequired object in the PAYMENT-REQUIRED header.
The client picks one of the accepted scheme and network options (networks use CAIP-2 identifiers such as eip155:8453 for Base mainnet) and retries with a PAYMENT-SIGNATURE header.
The server verifies locally or calls a facilitator's /verify endpoint, serves the resource, then settles directly or through /settle, returning a PAYMENT-RESPONSE header.

Schemes include exact, upto and batch-settlement. In upto, the amount at verification time is a maximum and the settled amount can be lower, so client-side limits matter. For EVM networks, replay protection relies on EIP-3009 authorisations with a 32-byte nonce and a validBefore expiry. The security model differs sharply from cards: on-chain settlement is generally final, there is no chargeback, and the agent's wallet key is the payment credential. The AP2 FAQ describes AP2 as payment-agnostic and points to an A2A and x402 implementation. For runaway per-call costs, see the Denial-of-Wallet and AI Agent Cost Runaway Guide.

Threats and the controls that answer them

The AP2 security considerations name five threat classes. The table maps them, plus two common card-side threats, to the control and the party that must enforce it.

Threat	Example	Control	Enforced by
Manipulated checkout	A stolen Payment Mandate replayed against a different basket	`checkout_hash` and `transaction_id` binding; merchant checks hash of the latest Checkout JWT	Merchant, processor
Manipulated payment	Agent alters amount or payee in transit	Verify user signature; evaluate `amount_range` and `allowed_payees`	Credential provider, processor
Payment credential theft	Token taken from agent memory and used elsewhere	Release the token only after a verified final Payment Mandate; agent-bound, merchant-locked tokens	Credential provider, network
Manipulated discovery	Prompt injection on a product page steers the agent to a malicious seller	Merchant-signed offers; `allowed_merchants` and `line_items` constraints bound the worst case	Merchant, verifier
Double spend	Injected agent signs several checkouts under one open mandate	One outstanding closed mandate per open mandate; reject overlaps; invalidate earlier tokens	Agent runtime, credential provider
Agent impersonation	A scraper bot claims to be a registered shopping agent	Verify RFC 9421 signatures against a published key directory; check `tag` and expiry	Merchant edge, bot management
Social engineering through the agent	A fraudster persuades the user, or the agent, to pay a "new" beneficiary	Payee constraints, confirmation of payee, step-up for new payees	PSP, bank

The last row is where agent payments meet push payment fraud. See the Authorised Push Payment (APP) Fraud Guide.

Implementation roadmap

Inventory the flows. List every place an agent can start a payment: your own agents, partner agents calling your checkout, x402 endpoints and employees' AI assistants holding corporate cards. Record which protocol, which credential and which party holds the signing keys.
Decide your role per flow. Merchant, credential provider, processor or agent provider each carry different MUST rules. A merchant can delegate Checkout Mandate verification to its processor, but the delegate then follows the merchant rules.
Build verification in deterministic code. Signature, vct, exp, hash binding and constraint evaluation must never be delegated to an LLM, even if the role itself is agentic.
Run in shadow mode first. Verify mandates and agent signatures on real traffic and log the result without blocking. Measure verification failures by reason before enforcing.
Enforce for Human Present flows, then autonomous. Start enforcing where the user approved the exact basket. Enable Human Not Present only with short exp, low amount_range and budget values, and allow-listed merchants.
Set step-up rules. Purchases outside the mandate, to new payees or above thresholds go back to the user on a phishing-resistant authenticator such as a passkey. See the AI Agent Action Approvals and Spending Limits Guide.
Plan rollback. Keep a feature flag that reverts agent checkouts to the Human Present path or to ordinary guest checkout, and a runbook to revoke agent tokens and agent keys within minutes.
Agree dispute evidence handling. Decide which mandates and receipts you store, for how long and how they are retrieved by transaction_id, because AP2 leaves this outside its scope.

Decision guidance

Card tokens or x402: choose card network agent tokens for consumer purchases where dispute rights, issuer controls and merchant acceptance matter. Consider x402 for low-value, high-frequency machine payments to APIs where finality is acceptable and wallet keys are managed as privileged secrets.
Human Present or Not Present: default to Human Present. Allow Not Present only for well-specified tasks with a clear trigger, such as a ticket on-sale or a replenishment order, and only with merchant and amount constraints.
Small merchants: rely on your PSP, CDN or bot management provider to verify agent signatures and mandates, and focus on clear refund and dispute processes.
Large merchants and issuers: run your own verification, publish your key directory, maintain an allow list of agent providers and feed verification outcomes into fraud models. See the Financial Services Identity Security Guide.

Where identity fits

Every protocol on this page rests on non-human identity: the agent's signing key in the cnf claim, the agent provider's mandate signing key, the merchant's Checkout JWT key, RFC 9421 keys in a published directory and, for x402, a wallet private key. Each needs an owner, storage in an HSM or managed key service the agent process cannot read directly, rotation (Web Bot Auth publishes the new key alongside the old one before removing it) and fast revocation. A stolen agent key in autonomous mode can sign closed mandates up to every limit in the open mandate. See the Credential Vaulting for AI Agents Guide and the Know Your Agent (KYA) Guide for verifying the agent before trusting its keys.

Detection and measurement

Log, per agent transaction: agent identifier and key ID, mandate vct, human present flag, constraint results, checkout_hash, receipt status, token ID and authorisation outcome. Alert on verification failures by reason, open mandates used more than once, tokens presented at merchants outside their scope, and spikes in a single agent key's volume.

Mandate verification failure rate by reason (signature, expiry, constraint, hash mismatch).
Share of agent transactions with a verified mandate versus unverified automated checkouts.
Agent-initiated dispute and chargeback rate compared with the human baseline.
Median open mandate lifetime (exp minus iat) for autonomous flows.
Time to revoke an agent token or key after a confirmed compromise.
Step-up rate and completion rate for out-of-mandate purchases.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	IA-9 Service Identification and Authentication; AU-10 Non-repudiation; AC-6 Least Privilege; IA-5 Authenticator Management	Agent request signing; signed mandates and receipts; constrained tokens; agent key lifecycle
NIST CSF 2.0	PR.AA-03; PR.AA-05; DE.CM-09	Authenticate agents; enforce least-privilege authorisations; monitor agent payment activity
ISO/IEC 27001:2022 Annex A	5.16 Identity management; 8.5 Secure authentication; 8.15 Logging	Agent identity lifecycle, key-based authentication, evidence retention
MITRE ATT&CK v20	T1657 Financial Theft; T1528 Steal Application Access Token; T1565 Data Manipulation	Fraud outcome; theft of agent tokens; tampering with checkout or payment data
MITRE ATLAS	AML.T0051 LLM Prompt Injection; AML.T0053 AI Agent Tool Invocation	Steering the shopping agent; misuse of its payment tools
OWASP Top 10 for LLM Applications 2025	LLM01:2025 Prompt Injection; LLM06:2025 Excessive Agency	Manipulated discovery; agents with payment power beyond the task

Common failure patterns

Verification inside the model: letting the agent "check" that the basket matches the user's request. AP2 requires validation in deterministic code because the agent is in the threat model.
A trusted surface that is not trusted: if the consent screen can be altered, a genuine signature approves the wrong transaction. In the Bybit hack, tampered JavaScript in a third-party signing interface led signers to approve a transfer that was not what they believed it to be. Protect the Trusted Surface's code supply chain and signing keys as critically as the payment keys.
Long-lived open mandates: an autonomous mandate valid for weeks with a broad merchant list behaves like a standing payment authority. Keep exp short and constraints narrow.
Ignoring unknown constraints: a verifier that skips constraint types it does not recognise silently widens the mandate. The specification says unknown constraints must fail.
Raw PANs or wallet keys in agent context: putting card numbers or private keys in prompts, memory or tool configuration exposes them to prompt injection and logging. Use scoped tokens released only after mandate verification.
Blocking or trusting all automation: treating every agent as a bot loses legitimate sales; treating every signed request as safe ignores that a verified agent can still be manipulated. Identity verification and mandate verification are separate checks.

Practitioner checklist

Map each agent payment flow to its layer, protocol, credential and signing-key owner.
Implement mandate, signature and constraint verification in deterministic code, with unknown constraints failing closed.
Match vct values exactly and reject expired or overlapping mandates.
Require agent-specific, merchant- and amount-limited tokens; never expose PANs or wallet keys to the agent.
Run verification in shadow mode, then enforce Human Present flows before enabling autonomous ones.
Set short exp, low amount_range and budget values, and allow-listed merchants for Human Not Present mandates.
Route out-of-mandate and new-payee purchases to passkey step-up.
Store agent keys in managed key services, rotate them and test revocation time.
Retain mandates and receipts for disputes, indexed by transaction_id.
Track verification failures, agent dispute rate and revocation time as standing metrics.

Agent Payments Protocols Guide: AP2 and Card Network Agent Tokens