Sign up (7-day free trial)
thumbnail_image

The Protocols Behind Agentic Commerce, Explained

✨ Quick Summary

Agentic commerce does not run on one protocol. It runs on a stack, and each layer has its own standard. MCP and A2A handle discovery and agent communication. ACP and UCP handle the merchant checkout journey. AP2 proves the buyer authorised the purchase. x402 settles machine-to-machine payments over HTTP. Card networks (Mastercard Agent Pay, Visa Intelligent Commerce) are wiring these into card rails. They are designed to stack, not to replace one another, so a single purchase can use several at once.

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:

  1. Discovery. The agent has to find products and read a merchant’s capabilities in a machine-readable way.
  2. Checkout. It has to build a cart and agree an order with the merchant.
  3. Authorisation. Someone has to be able to prove the human genuinely approved this specific purchase, within limits.
  4. 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.

ProtocolLayerFromOpen standardWhat it does
MCP (Model Context Protocol)Communication / discoveryAnthropicYesLets an agent connect to tools, data and merchant capabilities
A2A (Agent2Agent)Communication (agent to agent)Google and partnersYesLets agents talk to each other and to services
ACP (Agentic Commerce Protocol)Merchant journey / checkoutStripe and OpenAIYesIn-surface checkout with a scoped payment token
UCP (Universal Commerce Protocol)Merchant journey / retailGoogleYesStandardises catalogue, cart and order interactions
AP2 (Agent Payments Protocol)Authorisation / trustGoogle (Apache 2.0)YesProves the buyer authorised the purchase, via signed mandates
x402Settlement (machine to machine)CoinbaseYesPays for a resource over HTTP using the 402 status code
Mastercard Agent Pay / Visa Intelligent CommerceSettlement (card rails)Card networksNetwork schemesBring 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:

  1. An agent requests a paid resource (an API call, a dataset, a tool).
  2. The server responds with HTTP 402 and the payment terms: network, token, amount and recipient.
  3. 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.
  4. A facilitator verifies the payment and triggers settlement, usually in stablecoins.
  5. 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:

  1. Discover. The agent uses MCP to read the merchant’s catalogue and capabilities.
  2. Build the cart. It uses UCP or ACP to assemble and confirm the order with the merchant.
  3. Authorise. It presents an AP2 cart mandate, proving the buyer approved this exact cart within their intent mandate’s limits.
  4. 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