The agentic payments map: what the protocols are, and what they cannot do without you
ACP. UCP. AP2. MCP. VIC. MAP. MPP. If you have sat in a meeting where someone rattled off this list and everyone nodded, this is the piece that explains what they actually are. And why knowing them is only half the problem.
Simon Taylor at Fintech Brainfood mapped the agentic payments protocol landscape. It is a useful piece. The short version: there are a lot of protocols, they are not all solving the same problem, and that is why there are so many of them.
They operate at different layers. You do not pick one. You need to work across all of them.
Here is the map. Then we will tell you what the map leaves out.
The protocols, explained
There are three categories worth separating. They stack — each layer depends on the ones below it.
MCP (Model Context Protocol) is the standard for how agents identify themselves and communicate with a merchant's systems. TAP (Transaction Authorization Protocol) is how merchants verify whether a given agent is authorised to act on a user's behalf. Without these, you do not know who is at the door or whether to let them in.
ACP (Agentic Commerce Protocol) is what gets you into ChatGPT shopping flows. UCP (Universal Commerce Protocol) is the Visa/Mastercard-backed standard that Gemini and other agents use. Klarna's Agentic Product Protocol covers discovery and purchase through their agent ecosystem. These are the interfaces agents use to query your catalogue and initiate a transaction.
VIC and MAP operate at the card network layer, handling tokenisation and settlement once a transaction is authorised. They are mostly invisible to merchants but determine whether a charge actually goes through. MPP (Machine Payments Protocol) sits here too: it is an HTTP-native payment layer, built on the existing 402 Payment Required status code, that lets an agent pay for a resource in the same round-trip it uses to request it. No human checkout. No redirect. The card network tokens handle payment regardless of which commerce protocol sits on top.
MCP handles how agents talk. TAP handles whether to trust them. ACP and UCP handle how they buy. VIC, MAP, and MPP handle how the payment clears. The question is not which one to pick. It is how many of them your site can actually work with.
MPP: the protocol that arrived in 2026
The Machine Payments Protocol is worth separating out. Stripe and Tempo published the IETF draft (draft-httpauth-payment-00) in May 2026. The spec lives at paymentauth.org and mpp.dev. It is the first serious attempt to wire payment directly into HTTP rather than layering it on top.
The flow has three steps:
Agent requests a resource. A standard HTTP GET or POST to a merchant endpoint.
Server returns 402 with a payment challenge. The response header is WWW-Authenticate: Payment, which tells the agent what it costs and how to pay. Discovery happens via /openapi.json with x-payment-info path extensions.
Agent pays and retries. The second request carries Authorization: Payment <credential>. The server responds with the resource plus a Payment-Receipt header confirming the transaction.
Payment methods supported at launch: Stripe tokens (SPT) and cards, Tempo stablecoins on Base, Solana, and Stellar, and Visa IC card network tokens. Merchant endpoints follow a predictable pattern: /paid for the default flow, /spt/paid for Stripe, /crypto/paid for Tempo.
Stripe ships CLI tooling for it: npm i -g @stripe/link-cli. The same tooling ships as an MCP server, which means Claude and other MCP clients can invoke MPP payment flows directly. The whole thing is designed to require no human checkout step.
MPP is still a draft. But it is a draft with two major payment infrastructure companies behind it and working tooling already in the wild. It belongs in any honest account of what agents are going to use to pay for things.
You do not need to pick one. You need to be ready for all of them.
If you want to appear in ChatGPT shopping results, you need ACP. If you want Gemini, you need UCP. If you want Klarna agent flows, you need their product protocol.
Nobody knows which protocol will dominate. The safe bet right now is not to pick a winner but to show up across all of them. The merchants who are present across the full stack will capture demand that others miss while the consolidation plays out.
"The question is not which protocol to pick. It is how many of them your site can actually work with."
This is what we track at Aidō. Whether you have a UCP manifest published, whether your MCP endpoints are correctly configured, whether you are detectable in agentic product flows. The difference between knowing you ticked a box once and knowing your setup is actually working.
What the protocol map leaves out
Simon's piece ends with a sharp observation: merchants now have to optimise for agents, not just humans. He calls it Agent Engine Optimisation. He is right.
What the map does not cover is what that means on the ground. This is where most brands get stuck.
Protocols are the road. But you still need a vehicle that can drive on it.
Consider what happens when an agent connects to your store via ACP. It reaches your product catalogue. Now what? If your product data looks like this:
No GTINs or standardised product identifiers. The agent cannot match your product against other sources or verify it is what the user asked for.
Missing variant data. Size, colour, and availability are not structured per SKU. They are described in copy the agent cannot parse.
Returns policy buried in a PDF. The agent cannot tell the consumer what happens if the item does not fit.
Cart API that errors on programmatic requests. The agent stalls before checkout begins.
WAF rules that block non-browser traffic. The agent gets turned away at the door, regardless of which protocol it is using.
The protocol did its job. Your infrastructure did not. The transaction never happened.
These brands are not ignoring this. Most are actively thinking about it. The gap is that nobody has looked at their sites from an agent's point of view and told them exactly what breaks.
Both things have to work.
You need to be present across the protocols. And you need your data and technical infrastructure to hold up when an agent actually arrives. These are not separate problems. They are the same problem at different layers.
Getting the first right without the second is like publishing your phone number and letting it go to voicemail. The agent found you. It just could not buy anything.
Getting the second right without the first means you have a technically sound site that no agent can reach because you are not in any of the discovery flows.
Both. That is the answer.
See what an agent sees on your site
We scan e-commerce sites and tell you exactly what an AI agent can and cannot do on them. Genuinely quite nerdy. Drop us a line if you want us to run the numbers on yours.
Scan your siteThis piece draws on Simon Taylor's Agentic Payments Map, Fintech Brainfood. Worth reading in full: The Agentic Payments Map