In ACP, the agent platform vaults the card and hands the merchant a token capped at the checkout total. In AP2, a Credential Provider keeps the card and the user signs an SD-JWT that says what the agent may do with it. In x402 there is no card and nothing to vault: the payer's wallet signs a one-off USDC transfer and a facilitator puts it on-chain.
Those are three different answers to the question of who holds the money. Most pages ranking for "AP2 vs ACP vs x402" skip that and describe layers. Several, one earlier piece of mine among them, still explain AP2 with Intent and Cart Mandates, which the v0.2 spec replaced in April 2026.
What Is the Difference Between AP2, ACP and x402?
They standardise different things. ACP is a merchant checkout API. AP2 is a format for signed evidence that a user authorised an agent. x402 is an HTTP handshake for paying on a stablecoin rail. You can use all three in one flow, and the specs increasingly expect you to.
| AP2 | ACP | x402 | |
|---|---|---|---|
| Governed by | FIDO Alliance (donated by Google, 28 Apr 2026) | OpenAI and Stripe | x402 Foundation, Linux Foundation (operational 14 Jul 2026) |
| Current version | v0.2 | 2026-04-17 | Spec v2 |
| What it defines | Mandates and receipts | Checkout sessions, delegated payment, product feeds | 402 challenge, payment payload, facilitator API |
| Who holds the credential | Credential Provider | Agent platform's PSP or vault | Payer's own wallet |
| Proof of authorisation | User-signed SD-JWT mandate | Single-use token with an allowance | EIP-3009 signature per payment |
| Money moves on | Any rail the processor supports | The merchant's existing card processor | On-chain, e.g. USDC on Base (eip155:8453) |
| Dispute path | Evidence only, resolution out of scope | Normal chargeback via merchant of record | None in the spec |
| Transport | Extension to A2A, MCP and UCP | REST, plus MCP from 2026-04-17 | HTTP headers, A2A, MCP |
The x402 Foundation launched with 40 members, including Adyen, American Express, Google, Mastercard, Shopify, Stripe and Visa. That membership overlaps almost entirely with AP2's and ACP's backers, which tells you nobody expects one protocol to win outright.
How Does ACP Checkout Work in 2026?
The merchant implements five endpoints:
POST /checkout_sessions
POST /checkout_sessions/{checkout_session_id}
GET /checkout_sessions/{checkout_session_id}
POST /checkout_sessions/{checkout_session_id}/complete
POST /checkout_sessions/{checkout_session_id}/cancel
Every POST must carry an Idempotency-Key (up to 255 characters, UUID v4 recommended) and an API-Version date. A replayed request comes back with Idempotent-Replayed: true. If you have built idempotency keys for a payment API before, this is the Stripe pattern moved into a protocol.
The session status enum grew from five values in the 2025-09-29 spec to eleven in 2026-04-17: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress and expired. Code written against the first release that switches on status will silently miss six states.
Payment runs through a separate call, POST /agentic_commerce/delegate_payment, from the agent platform to a PSP or vault. It returns a vt_ token bound by an allowance, and all six fields are required:
"allowance": {
"reason": "one_time",
"max_amount": 2000,
"currency": "usd",
"checkout_session_id": "csn_01HV3P3...",
"merchant_id": "acme",
"expires_at": "2025-10-09T07:20:50.52Z"
}
reason accepts only one_time. ACP has no recurring delegation.
Stripe's Shared Payment Token is the first implementation. The seller receives an spt_ token with usage_limits of currency, max_amount and expires_at, then confirms a PaymentIntent with payment_method_data[shared_payment_granted_token]. Stripe clones the customer's PaymentMethod, so the seller never sees the card and refunds behave like any other payment. The docs still use Stripe-Version: 2026-04-22.preview.
One gap in the spec: the Signature header is described as an HMAC for webhook verification in the checkout OpenAPI file, and as a detached JSON signature in the delegate-payment file. Neither names an algorithm. Agree one with each counterparty in writing.
How Does AP2 Prove an Agent Is Authorised to Pay?
AP2 v0.2 has two mandate types, Checkout and Payment, each in an open and a closed form. All four are SD-JWT verifiable credentials, and the vct claim identifies which one you are holding.
| Mandate | vct | Required claims |
|---|---|---|
| Checkout, closed | mandate.checkout.1 | checkout_jwt, checkout_hash |
| Checkout, open | mandate.checkout.open.1 | constraints, cnf |
| Payment, closed | mandate.payment.1 | transaction_id, payee, payment_amount, payment_instrument |
| Payment, open | mandate.payment.open.1 | constraints, cnf |
The merchant signs the checkout as a JWT, and checkout_hash binds the mandate to that exact cart. After that, the flow depends on whether a human is present.
amount_range, budget, allowed_payees, allowed_pisps and agent_recurrence, whose frequency runs from ON_DEMAND to ANNUALLY. The cnf claim (RFC 7800) binds the agent's public key. When the agent later buys something, it signs the closed mandates with its own key, and a verifier checks the chain back to the user's open mandate.
The open Payment Mandate schema requires a payment_reference constraint in the array. The closed one has an optional pisp field. That field matters in the UK: an AP2 mandate can name an Open Banking payment initiation provider as the executor, which puts it next to a VRP consent with periodic limits as a way to cap agent spending.
AP2 never moves money itself. The Merchant Payment Processor executes on whatever rail it has, and a signed Payment Receipt comes back whether the payment was accepted or rejected.
How Does an x402 Payment Work Over HTTP?
The client requests a resource and gets a 402. The server says what it wants, the client retries with a signed payment, and the server returns the resource with a settlement result. Version 2 moved everything into headers:
| Direction | x402 v1 | x402 v2 |
|---|---|---|
| Server to client | JSON body | PAYMENT-REQUIRED (base64 JSON) |
| Client to server | X-PAYMENT | PAYMENT-SIGNATURE |
| Settlement result | X-PAYMENT-RESPONSE | PAYMENT-RESPONSE |
A decoded requirement looks like this:
{ "scheme": "exact", "network": "eip155:84532", "amount": "10000",
"asset": "0x036C...CF7e", "payTo": "0x2096...287C",
"maxTimeoutSeconds": 60, "extra": {"name": "USDC", "version": "2"} }
Two v2 changes break v1 clients. maxAmountRequired became amount, and network names like base-sepolia became CAIP-2 identifiers. The amount is a string in the token's smallest unit, and USDC has six decimals, so "10000" is one cent.
Under the exact scheme on EVM chains, the client signs an EIP-3009 transferWithAuthorization with from, to, value, validAfter, validBefore and a nonce. The resource server passes it to a facilitator's POST /verify and POST /settle. Coinbase's CDP facilitator charges nothing to verify, gives 1,000 settlements a month free, and charges $0.001 for each one after that.
Treat the volume numbers carefully. Chainalysis attributed much of x402's late-2025 growth to memecoin activity. On 14 September 2026 the x402.org dashboard showed roughly 75 million transactions carrying about $24 million over 30 days, an average near 32 cents. That is a machine-payments rail, not a checkout.
AP2 vs ACP vs x402: What Happens When a Payment Fails?
ACP returns errors in amessages[] array on the checkout session. The code enum has 21 values, including payment_declined, requires_3ds, out_of_stock, region_restricted, approval_required and intervention_required. If the session is in authentication_required and the agent calls complete without an authentication_result, you get requires_3ds. The delegate-payment endpoint has its own error codes: idempotency_key_required, idempotency_in_flight (HTTP 409), idempotency_conflict, invalid_card, rate_limit_exceeded and service_unavailable.
x402 answers a failed payment with another 402. The facilitator's /verify returns isValid and an invalidReason. /settle returns success, transaction, network, payer and, on failure, an errorReason. The spec's codes are specific: insufficient_funds, invalid_exact_evm_payload_authorization_valid_before for an expired signature, invalid_exact_evm_payload_authorization_value_mismatch when the amount is off by any amount at all, and invalid_transaction_state when the chain rejects the transfer.
AP2 has no error-code enum. A rejection is a signed receipt. In the autonomous flow, an agent must not present another open mandate until it holds a rejection receipt for the previous attempt. The spec's stated reason is to stop one open mandate approving several different checkouts, which is the double-spend your retry loop would otherwise create.
In short, ACP gives you product-level reasons, x402 gives you chain-level reasons, and AP2 gives you a signed record that something was refused.
Who Handles Disputes and Chargebacks in Agentic Payments?
| AP2 | ACP | x402 | |
|---|---|---|---|
| Refund primitive | Depends on rail | Standard processor refund | None, needs a new transfer |
| Chargeback | Depends on rail | Yes, card scheme rules | No |
| Evidence | Mandates plus receipts, "non-repudiable" | Session, allowance, processor records | On-chain transaction hash |
AP2's spec has a Dispute Evidence section and then declares resolution, retention and retrieval out of scope. ACP inherits card chargebacks because OpenAI is explicitly not the merchant of record. x402 settlement is final, and a refund is just another payment in the opposite direction, if the merchant agrees to make one.
Card schemes have not decided who is liable when an agent buys the wrong thing inside its limits. EMVCo's draft agentic framework defines an intent layer and stops short of a liability rule.
Which Agentic Payment Protocols Work in the UK in 2026?
- Visa Intelligent Commerce and Trusted Agent Protocol: live. Visa's 2 July 2026 announcement named Barclays, HSBC UK, Lloyds Banking Group, NatWest, Nationwide and Revolut as issuers, with lastminute.com and Frasers among the merchants. TAP signs agent requests with RFC 9421 HTTP Message Signatures.
- Stripe Shared Payment Tokens (the ACP payment layer): GB is on the supported country list, alongside the US, Canada and 31 other European markets, under preview terms.
- Google UCP checkout: not yet. Rollout is US first, then Canada and Australia, "and later the U.K.", per Search Engine Land on 20 May 2026.
- Mastercard Agent Pay: tested, not rolled out. Santander ran a live agent payment across Madrid and London on 2 March 2026 and said it was not a commercial rollout.
- x402: the protocol has no geographic gate. Whether a UK business should take USDC is a regulatory question, and the UK stablecoin regime is still being settled.
Which Agentic Payment Protocol Should You Build On?
This section is my opinion.
If you sell physical goods to UK consumers this year, the card path is the only one that reaches real customers with chargeback protection. That means Visa's programme through your acquirer, or SPTs if you are already on Stripe. ACP's checkout API is worth implementing where agent platforms ask for it. Just don't let it define your data model.
Build your order records around AP2's shapes instead. It is the only one of the three whose artefacts are designed as evidence. FIDO governance puts it next to passkeys, and UCP already carries AP2 mandates through its dev.ucp.shopping.ap2_mandate extension.
x402 wins one job clearly: charging software for API calls worth a few cents, where a fixed card fee would exceed the price. For anything a person might dispute, the lack of a refund primitive is a product decision you are making for your customer.
My prediction is that by the end of 2027 nobody frames these as alternatives. The a2a-x402 extension already defines an "embedded" flow in which an AP2 Payment Mandate wraps an x402 payload. Checkout will be ACP or UCP, authority will be an AP2 mandate, and x402 will be one payment handler among several. The expensive mistake is hard-coding any single one of them into your order model.
What This Means for Payments Engineers
1. Store authorisation evidence as a first-class record. Keep the mandate, allowance or signed authorisation next to the order, with its hash. When disputes arrive, the evidence has to exist already.
2. Make idempotency non-optional. ACP rejects POSTs without a key and returns 409 idempotency_in_flight for concurrent retries. EIP-3009 nonces are single-use by design. Your retry logic has to respect both.
3. Pin versions explicitly. Send an API-Version date on every ACP call. Accept both X-PAYMENT and PAYMENT-SIGNATURE while x402 clients migrate, and parse networks as CAIP-2.
4. Map every failure code to a user state. requires_3ds and intervention_required mean a human has to come back. insufficient_funds means the agent's wallet needs topping up. Neither should become a silent retry.
5. In the UK, start with what is live. Ask your acquirer about Visa's agentic programme, or test SPTs in Stripe's preview. Don't plan a launch around UCP until Google gives the UK a date.
Key Takeaways
- ACP vaults the card, AP2 signs mandates over it, x402 has no card at all.
- AP2 v0.2 replaced Intent and Cart Mandates with open and closed Checkout and Payment Mandates.
- x402 v2 renamed every header and switched to CAIP-2 networks.
- Only card-backed flows give UK buyers a chargeback, and Google's UCP checkout has no UK date.