🧠 The Agentic Payments Map

ACP, UCP, A2P, MPP, x402.

If your eyes just glazed over, you’re not alone.

The agentic payments conversation has become an alphabet soup of competing protocols, each claiming to solve the problem of how agents pay for things. And that’s before you look at anything the card networks are doing, with their own emerging standards.

Why so many? Because they’re not all solving the same problem.

There are commerce protocols (how agents buy stuff from merchants). There are B2B protocols (how agents pay invoices). And there are agent-native protocols (how agents pay each other for compute, data, and API access at machine speed).

Different problems. Different protocols. One confusing mess.

So I made you a map.

To understand why there are so many protocols, and why they’re not as redundant as they appear, we need to split a few things apart:

When you’re doomscrolling you’re probably not thinking about TCP/IP, HTTPS, or the video codec streaming content to you. You’re probably not thinking at all.

That’s the point. When protocols work together well, the experience is seamless. But the path there is often messy.

The internet relies on a stack of canonical protocols to function:

TCP/IP (Transmission Control Protocol/Internet Protocol)

DNS (Domain Name System)

HTTP/S (Hypertext Transfer Protocol/Secure)

New protocols get added quietly all the time—gRPC for efficient application communication, WebSocket for persistent connections. Around these sit certificate authorities, CDNs, and a whole swathe of infrastructure that makes it work.

The internet isn’t static. It evolves.

HTTP status code 402 is “Payment Required.” It was reserved in 1997. Never implemented.

The internet was designed to move information, not money. Commerce got bolted on top through specialized financial messaging systems—your browser talks HTTPS to the merchant, who talks to a payment gateway, who talks to financial networks like Visa or ACH.

There’s no single, universally adopted protocol that standardizes the entire lifecycle from “add to cart” to “settled payment.”

This is precisely why ACP, UCP, and the others are emerging—they aim to create a structured language for agents to communicate commerce intent.

The plumbing that worked for humans at keyboards doesn’t work for software making decisions at machine speed.

Consider what happens when an agent tries to buy something on your behalf:

These are genuinely hard problems. And they’re being attacked from multiple directions by multiple players, which has led to an explosion of new protocols.

But before we get to payment protocols, there’s a layer that has to come first: trust.

MCP and A2A handle how agents communicate. But as the ERC-8004 specification puts it: “these agent communication protocols don’t inherently cover agent discovery and trust.”

Before agents can transact, they need to establish legitimacy. This is especially critical for merchants, who’ve spent years blocking bots. Now they need to let the right bots through.

Two protocols are emerging to solve this:

ERC-8004 creates on-chain registries for identity, reputation, and validation. The spec explicitly shows how an agent’s registration file can list MCP endpoints, A2A agent cards, ENS names, and DIDs together. It’s designed to work with existing communication protocols, not replace them.

Visa TAP takes a different approach—verifiable signatures that prove an agent is: A Visa-trusted agent with commerce intent (not a scraper or attacker). Acting on behalf of a recognizable consumer (via loyalty accounts or device identifiers). Carrying valid payment credentials that merchants can verify

The takeaway: Trust is a prerequisite for payment. These protocols answer “should I believe this agent?” before anyone asks “how should this agent pay?”

Commerce means buying goods or services as a business or human. With agentic commerce, you outsource that purchase moment to an agent. The transaction still involves buying a thing—like a Fallout Vault Boy figurine or a PlayStation subscription—but now the agent handles discovery, selection, and payment.

Firstly, two protocols are emerging to standardize this flow:

These protocols achieve similar consumer experiences in different ways:

The takeaway: If you’re a merchant wanting to appear in both ChatGPT and Gemini, you’ll likely need to support both. For now. Your trade-off appears to be that UCP requires more work but offers greater flexibility across the entire flow. ACP works with a lot of what’s already there.

Secondly, there are those designed to enforce at the payment network level.

The takeaway: In practice, both standards are likely very similar—the core difference is that tokens work with their respective networks. These network-level tokens ensure consumer protections, chargebacks, and fraud are handled as merchants expect.

Commerce gets all the attention, but B2B payments are where the volume actually lives. Think invoices, supplier payments, payroll—the unsexy plumbing of business. Here, the agents tend to talk directly to the rail.

Agents handling B2B flows face different challenges:

Stablecoins offer card-like guarantees of payment success plus programmability, but there isn’t yet a universally adopted standard with real traction.

This is where it gets interesting.

The internet has valuable resources locked behind API keys and subscriptions. If you want Google Maps data or ChatGPT in your application, you create an account, pre-fund it, get a key, and then you can access the service.

That model doesn’t scale for billions of agents writing code, buying from each other, and needing resources on demand.

Today this shows up as two friction points:

These friction points mean agents can’t truly be autonomous. They’re your junior dev, but you don’t trust them with the expenses card or company credentials yet.

Agent-native protocols aim to fix this:

AP2 deserves special attention:

Imagine trillions of fractional, instant micropayments for compute, data, and API calls. Imagine autonomous economies where agents transact for every resource consumed, creating massive new transaction volume for products that aren’t properly monetized today.

It sounds like sci-fi. But so did self-driving cars, robot dogs, and AI solving novel math problems. Those are here now.

I wrote a long-form piece, “Invisible Commerce,” that deep dives specifically into the agent-to-agent protocols like MPP and x402.

In a word: messily. For now.

I created this. I have two key takeaways:

First, a Google stack is emerging. Google’s approach (A2A → AP2 → UCP) creates a coherent stack that works for both commerce and non-commerce payments.

Second: These protocols operate at different levels of abstraction:

These standards are emerging, incomplete, and not yet widely adopted. In five years they could all have disappeared—remembered like WAP and Betamax, forgotten standards lost to time.

But that assumes AI agents go away. Which seems unlikely.

If you’re a merchant, payments company, or bank, you can’t ignore this. But it’s also nearly impossible to pick winners. Here’s how I think about it:

The next era of agentic payments will be defined by how these protocols fit together and inherit capabilities from each other. Just as A2A → AP2 → UCP creates a coherent stack, expect similar compositions to emerge for B2B and agent-native flows.

The path there will be messy. Standards will compete. Some will die.

But the underlying shift—software that can discover, negotiate, and pay for resources autonomously—is coming regardless of which protocol wins.

Now at least you have a map.

ST.

If you enjoyed this why not subscribe?

I also run an event for operators, founders, and C-Suites looking to know what happens next in AI, finance, and payments, and what you should do about it. It’s called Fintech Nerdcon, and it takes place in San Diego on the 19th and 20th of November.

👉 And you can grab your tickets here.