Ready to get started?
Easily integrate next-generation payments and financial data into any app. Build powerful products your customers love.
Why agentic commerce needs new protocols
When an AI agent shops and pays for someone, four separate jobs have to happen safely, and the web was never designed for any of them to be done by software acting on a person’s behalf:
- Discovery. The agent has to find products and read a merchant’s capabilities in a machine-readable way.
- Checkout. It has to build a cart and agree an order with the merchant.
- Authorisation. Someone has to be able to prove the human genuinely approved this specific purchase, within limits.
- Settlement. The money has to move, and the merchant and its bank have to trust the instruction.
No single company owns all four, and building one closed system would not scale across the whole internet. So a set of open protocols has appeared, each solving one layer. Understanding the stack is the difference between treating “agentic payments” as a buzzword and actually building for it.
The agentic commerce stack at a glance
The cleanest way to think about it is as four layers: communication, merchant journey, authorisation, and settlement.
| Protocol | Layer | From | Open standard | What it does |
|---|---|---|---|---|
| MCP (Model Context Protocol) | Communication / discovery | Anthropic | Yes | Lets an agent connect to tools, data and merchant capabilities |
| A2A (Agent2Agent) | Communication (agent to agent) | Google and partners | Yes | Lets agents talk to each other and to services |
| ACP (Agentic Commerce Protocol) | Merchant journey / checkout | Stripe and OpenAI | Yes | In-surface checkout with a scoped payment token |
| UCP (Universal Commerce Protocol) | Merchant journey / retail | Yes | Standardises catalogue, cart and order interactions | |
| AP2 (Agent Payments Protocol) | Authorisation / trust | Google (Apache 2.0) | Yes | Proves the buyer authorised the purchase, via signed mandates |
| x402 | Settlement (machine to machine) | Coinbase | Yes | Pays for a resource over HTTP using the 402 status code |
| Mastercard Agent Pay / Visa Intelligent Commerce | Settlement (card rails) | Card networks | Network schemes | Bring agent-initiated payments onto card rails |
MCP and A2A: The communication layer
The Model Context Protocol (MCP), an open standard originally from Anthropic, is how an AI model connects to external tools, data and services. In commerce it is the discovery and tool layer, letting an agent find a merchant’s catalogue and call its capabilities in a structured way. Most of the other protocols now assume MCP is the data plane underneath them.
Agent2Agent (A2A) is the sibling standard for agents talking to other agents and services, rather than to tools. Together, MCP and A2A are the plumbing that carries everything else.
Atoa runs a live MCP server, so agents can work with Atoa payments programmatically today.
ACP: The checkout layer
The Agentic Commerce Protocol (ACP), from Stripe and OpenAI, handles the checkout itself. It gives a merchant a small set of REST endpoints to create, update, complete and cancel an order, and it uses a Shared Payment Token, a credential scoped to a single merchant and amount, so an agent can pay without ever holding the buyer’s raw card details.
ACP is worth a short history lesson, because it shows how fast this field moves. In February 2026, OpenAI launched “Buy it in ChatGPT”, an Instant Checkout feature that let US users buy inside the chat. By March 2026, OpenAI retired Instant Checkout and pivoted ChatGPT towards product discovery, letting shoppers complete the purchase on the retailer’s own site, with several major ACP retailers live. The consumer product changed, but the ACP protocol itself continues. The lesson for merchants: build on the open standard, not on any one company’s checkout button.
UCP: The retail interaction standard
The Universal Commerce Protocol (UCP), from Google, standardises how agents and merchants interact for retail: reading a catalogue, building and confirming a cart, and placing an order. It overlaps with ACP at the checkout layer and is one of the standards the card networks are choosing to support. Expect ACP and UCP to converge or interoperate over time rather than one simply winning.
AP2: The authorisation layer
The Agent Payments Protocol (AP2), from Google and released under an open Apache 2.0 licence, is the trust layer, and it is the piece most people underestimate. AP2 does not move money. Its job is to produce a verifiable chain of proof that a human authorised a specific purchase, so a merchant, bank or card network can trust an agent-initiated payment. It does this with three cryptographically signed “mandates”:
- Intent Mandate. The user signs this up front, with explicit constraints: a price cap, a time window, a merchant allowlist, an item specification, and a “prompt playback”, a plain-language summary of what the user asked for that the merchant can display back. This is the agent’s authority to act.
- Cart Mandate. The merchant assembles the exact cart (items, SKUs, unit prices, tax, shipping, total, currency) and signs it. The user (or the user’s agent, under the intent mandate) then co-signs it, producing a credential proving the buyer approved this exact cart at this exact price.
- Payment Mandate. A derived credential that the payment network or bank actually sees, linking the authorised cart to a payment method.
Because each mandate is cryptographically signed and chained, AP2 gives something card payments have always lacked for automated flows: non-repudiation and an audit trail. If a purchase is disputed, there is signed proof of who authorised what, and within which limits.
AP2 leaves settlement to the rails. If the payment method is a card, the transaction settles down the normal card path. If it is a stablecoin, settlement happens through an x402 extension that Google developed with Coinbase and others. Atoa is building AP2 support (on our roadmap, not yet shipped).
x402: The machine-to-machine settlement layer
x402, from Coinbase, revives the long-dormant HTTP status code 402 Payment Required so that agents and APIs can pay each other programmatically, with no accounts, sessions or API keys. The flow is elegant and worth understanding:
- An agent requests a paid resource (an API call, a dataset, a tool).
- The server responds with HTTP 402 and the payment terms: network, token, amount and recipient.
- The agent checks its own policy (budget, allowed vendor, purpose) and, if it passes, signs a payment authorisation (for example an EIP-3009 “transfer with authorisation”) and reattaches the request with the payment in the header.
- A facilitator verifies the payment and triggers settlement, usually in stablecoins.
- The server returns the resource.
This is aimed at machine-to-machine payments, often in tiny sub-cent amounts, rather than consumer shopping. Adoption has been fast: by April 2026, x402 had roughly 69,000 active agents that had processed more than 165 million transactions worth about $50 million cumulatively (Chainalysis analysis of Coinbase’s x402).
The card networks join in
The card networks are not sitting this out, and this is the biggest 2026 development the shorter explainers miss. Mastercard Agent Pay introduced “Agentic Tokens” (extending EMVCo network tokenisation to agent-initiated flows) and “Verifiable Intent” (an artifact that travels with each agentic transaction). Visa Intelligent Commerce, with its Trusted Agent Protocol (TAP), defines how agents identify themselves to merchants, and Visa’s Intelligent Commerce Connect aims to accept agent payments across several protocols through one integration.
Crucially, the layers are converging: as of 2026, payment service providers can mint AP2 mandates that Mastercard treats as Verifiable Intent. In other words, the authorisation layer (AP2) and the card rails are being wired together. (Sources: Mastercard, Visa, American Banker, 2026.
How they compose, not compete
The single most important idea is that these are layers, not rivals. A full agentic purchase can use several at once:
- Discover. The agent uses MCP to read the merchant’s catalogue and capabilities.
- Build the cart. It uses UCP or ACP to assemble and confirm the order with the merchant.
- Authorise. It presents an AP2 cart mandate, proving the buyer approved this exact cart within their intent mandate’s limits.
- Settle. The payment runs down a card rail (increasingly carrying the AP2 mandate as verifiable intent) or, for machine-to-machine, over x402.
So “which protocol wins?” is the wrong question. The better question for a merchant or developer is “which layer am I solving, and does my payment provider fit into that stack cleanly?”
Security, trust and the liability question
Agent payments raise a real question: if an agent is tricked, overspends, or buys the wrong thing, who is responsible? The protocols are part of the answer. AP2’s signed mandates create non-repudiation and an audit trail, so there is provable evidence of what a human authorised. Scoped tokens (ACP’s Shared Payment Token, Mastercard’s Agentic Tokens) limit blast radius by tying a credential to one merchant and amount. And policy checks at the agent level (budget, allowlist, purpose) add guardrails before any payment is signed.
None of this fully settles the liability question, which remains unresolved in the UK as of 2026, with the CMA, FCA and HM Treasury all engaged. We cover that in depth in AI payment security.
Where UK Pay by Bank fits
Agent payments favour rails that are authenticated, instant and hard to reverse fraudulently, because reversing a bad automated payment at scale is costly. Pay by Bank fits that profile: the payment is approved in the customer’s own Bank app (strong authentication built in), it settles in seconds over Faster Payments, and it carries no card-style chargeback. That makes it a natural UK settlement option in an AP2-style world where consent is proven up front and the rail just needs to move money reliably.
Atoa is a UK, FCA-authorised platform building for this: a live MCP server, commercial Variable Recurring Payments, and AP2 support in progress. If you want to build with it, see the Atoa payment API and CLI.
What this means for UK merchants and developers
You do not need to adopt every protocol in 2026. You need to be positioned so you can:
- Be discoverable to agents (clean product data and, increasingly, an MCP or A2A surface).
- Design for provable consent, so you can accept AP2-style mandates as they land on the card networks.
- Choose a settlement rail that is authenticated, instant and low-risk, and a provider that plugs into the stack rather than locking you into one closed checkout.
Frequently asked questions
What is the agentic commerce protocol?
There is no single protocol. Agentic commerce uses a stack of open standards, each for one layer: MCP and A2A for communication and discovery, ACP and UCP for the merchant checkout, AP2 for authorisation, and x402 (plus the card networks) for settlement.
What is ACP?
The Agentic Commerce Protocol, from Stripe and OpenAI, is a checkout layer that gives merchants REST endpoints to create, update, complete and cancel orders, using a Shared Payment Token scoped to one merchant and amount. It powered ChatGPT’s Instant Checkout, which OpenAI retired in March 2026 in favour of product discovery, though the protocol continues.
What is AP2?
The Agent Payments Protocol, from Google, is an open authorisation layer that proves a buyer approved a purchase, using three signed mandates: intent, cart and payment. It does not move money; settlement runs down card rails or x402.
What are the AP2 mandates?
An Intent Mandate (the user’s up-front authority, with a price cap, time window and merchant allowlist), a Cart Mandate (the exact cart, co-signed by merchant and buyer), and a Payment Mandate (the credential the network sees). Together they give non-repudiation and an audit trail.
What is x402?
An open protocol from Coinbase that uses HTTP 402 to let agents and APIs pay each other. The server returns 402 with payment terms, the agent signs a payment and retries, and a facilitator settles it, usually in stablecoins. By April 2026 it had around 69,000 active agents and over 165 million transactions.
Is x402 only for crypto?
It is used mostly for stablecoin, machine-to-machine payments today. Consumer purchases more often settle on card rails or, in the UK, on Pay by Bank. The protocols are rail-agnostic at the authorisation layer.
Do ACP, AP2 and x402 compete?
No. They cover different layers and compose together: discovery, checkout, authorisation and settlement. A single purchase can use several.
Where do Mastercard and Visa fit?
They are bringing agent-initiated payments onto card rails. Mastercard Agent Pay uses Agentic Tokens and Verifiable Intent, and can treat AP2 mandates as verifiable intent; Visa Intelligent Commerce and its Trusted Agent Protocol define how agents identify to merchants.
Does Atoa support these protocols?
Atoa runs a live MCP server and offers commercial Variable Recurring Payments, and is building AP2 support (on the roadmap). Pay by Bank provides the authenticated, instant UK rail agent payments favour.
Sources
- x402 adoption (approx 69,000 agents, 165M+ transactions, ~$50M by April 2026): Chainalysis, “Inside x402”; Coinbase x402.
- ACP and ChatGPT Instant Checkout launch (Feb 2026) and retirement (March 2026): DigitalCommerce360; CNBC.
- AP2 mandates (intent, cart, payment), Apache 2.0, settlement via card rails or x402 extension: Google Cloud blog; ap2-protocol.org.
- MCP (Anthropic), A2A and UCP (Google): Descope developer guide; Universal Commerce Protocol blog.
- Card networks: Mastercard Agent Pay; Visa and Mastercard agentic deployments (American Banker); RisingWave comparison.