A map of the agentic payment stack: agent tokens, x402, ACP and AP2

Card-network agent tokens, x402, ACP and AP2 are not four rival answers to one question. Each covers a different layer of an agent payment, and most real flows will use more than one.

If someone has asked you "should we support agent checkout?", the useful first step is to split the payment into layers and ask which ones your system owns.

The six layers

Discovery and identity. Is this request from a known agent, and what is it allowed to see?
Consent and mandate. What did the person actually ask for, and within what limits?
Credentials. What does the agent present instead of a card number or a key?
Authorisation. Who says yes to this specific payment?
Settlement. How does money actually move?
Disputes. What happens when the payment was wrong?

Where each scheme sits

Layer	Card-network agent tokens (Visa, Mastercard)	x402	ACP (OpenAI, Stripe)	AP2 (now at FIDO)
Discovery and identity	Agents register with the network and sign requests with Web Bot Auth; keys sit in a directory [2][4]	None in the protocol; any HTTP client can pay [5]	Checkout API and product feed [7]	Builds on A2A and MCP [9]
Consent and mandate	Consumer sets limits and conditions [1]	Not defined; the `upto` scheme caps one request [5]	`Allowance`: `max_amount`, `merchant_id`, `expires_at` [8]	Signed Intent and Cart Mandates [9]
Credentials	Network tokens issued for agent use [1][3]	Signed payload in a `PAYMENT-SIGNATURE` header [5]	Delegated vault token [8]	Payment-method agnostic [9]
Authorisation	Issuer, on the card rails	Server or facilitator `/verify` [5]	Merchant's existing PSP, within the allowance [8]	The underlying payment rail [9]
Settlement	Card clearing and settlement	On-chain, via `/settle` or batched vouchers [5]	Merchant's PSP [8]	The underlying payment rail
Disputes	Existing card dispute processes; Visa cites signals to help manage disputes [1]	No refund or dispute step in the README [5]	Not covered in the parts we read	Mandates give an audit trail, not a process [9]

Read the table by column to see what each scheme leaves to someone else. Read it by row to see where you will need two schemes to meet.

Card-network agent tokens

Visa Intelligent Commerce replaces card details with "tokenized digital credentials" and lets the consumer "set spending limits and conditions" [1]. Mastercard Agent Pay introduced Mastercard Agentic Tokens, and requires trusted agents "to be registered and verified" [3].

Both networks identify the agent at the merchant's edge in the same way. Visa's Trusted Agent Protocol is built on HTTP Message Signatures [2]. Cloudflare says that "Both Trusted Agent Protocol and Agent Pay leverage Web Bot Auth", with agent keys published in a directory each network hosts [4].

What this gives you: the issuer still authorises, the card rails still settle, and chargebacks still exist. What it does not give you: a record of what the person asked the agent to buy. That sits a layer up.

x402

x402 uses the HTTP 402 status code. The server answers with a PAYMENT-REQUIRED header listing what it accepts. The client retries with a signed payload in PAYMENT-SIGNATURE. The server verifies it, does the work, then settles directly or through a facilitator [5].

Its schemes include exact, upto (a cap per request, settled on actual use) and a batch-settlement scheme with off-chain vouchers [5]. One of its principles is "Trust minimizing": the facilitator and the resource server must not be able to move funds [5]. The README has no refund or dispute step [5].

Coinbase contributed x402 to the Linux Foundation's x402 Foundation. Visa, Mastercard, Google and Stripe are among its premier members [6].

ACP

The Agentic Commerce Protocol is maintained by OpenAI and Stripe and is labelled beta. Its latest stable spec is dated 2026-04-17 and covers "Cart, feed, orders, authentication, and MCP" [7].

The payment part is the delegate payment spec. It issues "a delegated vault token" that the merchant's PSP may use "only within explicit Allowance constraints". The allowance names a maximum amount in minor units, a currency, a checkout session, a merchant and an expiry. Its reason must be one_time [8].

That is a narrow, checkable mandate tied to one checkout. It is a good shape to copy even if you never use ACP.

AP2, now at the FIDO Alliance

Google announced AP2 in September 2025. Its trust model rests on Mandates: "cryptographically-signed digital contracts" signed with verifiable credentials. An Intent Mandate records the request. A Cart Mandate records "the exact items and price". In a delegated task, a signed Intent Mandate sets price limits and conditions, and the agent creates the Cart Mandate when they are met [9].

On 28 April 2026 Google said it was "donating the Agent Payments Protocol (AP2) to the FIDO Alliance" and released v0.2, which adds "Human Not Present" payments [10]. The FIDO Alliance announced the same day that AP2 is an initial contribution to its new Payments Technical Working Group, led by representatives of Mastercard and Visa. Mastercard also contributed Verifiable Intent, co-developed with Google to work with AP2 [11].

So "run by FIDO" is close, but the exact claim is that AP2 was donated to FIDO, which is now developing agent payment specifications with it as a starting point.

This month's news, checked

Mastercard and x402. Headlines say Mastercard "adopts x402". Here is who said what:

Mastercard launched Agent Pay for Machines on 10 June 2026. It promised credentialing, controls that are "programmatically enforced", and settlement across cards, accounts and stablecoins. In that release Coinbase, not Mastercard, named x402 [12].
On 20 October, The Block reported a statement from Mastercard: developer early access to Agent Pay for Machines, after pilots including Cloudflare, Base and Coinbase. Base was "the onchain settlement network", vouchers "can be batched and redeemed later", and the project "has not yet been made commercially available" [13].
On 24 October, TokenPost reported that "Base said Mastercard is adopting an agent-payment method that uses x402 and USDC and settles on Base" [14].

We could not find a Mastercard release that uses the word "adopts".

Visa, BILL and Billtrust. On 20 October Visa announced a live pilot in which a BILL Payment Agent pays supplier invoices. The agent is registered through Visa's Trusted Agent Protocol and Agentic Directory. It uses "Tokenized payment credentials rather than shared supplier-portal logins". It "only executes eligible payments that have already been approved by the buyer" [15]. That is the card-token column of the table, used for business-to-business payments.

x402 volumes. Chainalysis reports "over 138 million x402 transactions" on Base. Over 87% were between a hundredth of a cent and ten cents [16]. Chainalysis's own caveats: experts consider the market "still in its 'experimentation phase'", memecoins "attracted huge numbers of new wallets only to fade", and some measures counted only wallets that paid on two or more days [16]. CoinDesk's coverage adds, in its own voice, that "transaction counts alone do not establish how much represents genuine commercial demand" [17].

What to build now

Pick your layers. A merchant on the card rails needs agent identity (Web Bot Auth) and an evidence record. An API seller charging per call is looking at x402.
Store the mandate whatever the rail. None of these schemes gives you a dispute process for "the agent bought the wrong thing". Keep the signed request, the cart and the limits.
Treat the specs as moving. ACP is labelled beta. AP2 is at v0.2. Agent Pay for Machines is in early access.

What we do

We review card-programme and agentic payment designs, including where agent tokens and x402 fit. This is not legal or regulatory advice. See the payments section at https://centrob.co/#payments.