The whole landscape.
One connection.
None of these standards has won, and none of them talks to the others. Connecting to one is a bet. This is the list of bets we took so you do not have to.
They are layers, not rivals.
The internet runs on a stack of protocols nobody thinks about. Addressing, delivery, naming, encryption: each solved one problem and stayed out of the way of the others, and the result is an experience that feels like one thing. The layer it never got was payment. The status code for it was reserved in 1997 and left unimplemented, so commerce was bolted on afterwards through systems that were never part of the web.
Agents make that gap impossible to ignore, and the response has been an explosion of standards that look like rivals and mostly are not. They sit at different heights. Two that look like duplicates are usually answering different questions.
Which is why the useful position is not picking a winner. It is covering the whole height of it, and holding the one thing that spans every layer: an account of what happened.
- 13x
- Growth in orders from AI search in a year, as reported by Shopify
- Discovery is working. It is everything after discovery that is not.
- 1.18%
- Conversion on agent-built carts in early Walmart data, against an industry norm of 2.5 to 3%
- Agents are already finding things to buy and then failing at the buying.
- 95%
- Share of AI-driven purchases that still finish on the merchant's own site
- The handoff back to a human is not a preference. It is a missing layer.
How do agents talk?
Agents already have ways of talking to each other and of reaching tools. None of those standards say anything about whether the agent on the other end should be believed, or what it may spend. That is the hole everything below fills.
Agent2Agent
Google
Work passed between agents. We pause a task at the point it needs to pay.
How work passes between agents. The place we care about is the moment a task cannot continue until something is paid for.
Model Context Protocol
Anthropic
Our actions, available to any agent that speaks it.
How an agent reaches a tool. It is how most agents will meet this API at all.
XMTP
XMTP
Encrypted messages, as a way for a request to reach you at all.
Encrypted messaging as a delivery route, for when a request has to arrive somewhere that is not an HTTP endpoint.
Should I believe this agent?
Recognition comes first, because nothing else can be decided without it. Sellers spent two decades learning to block bots and now have to let the right ones through.
Visa Trusted Agent Protocol
Visa
Lets a seller tell a trusted agent from a bot. The signing layer is built and proven against Visa's own samples; their enrolment for production is not open yet.
Signed requests that let a merchant, or the service in front of it, tell a vetted agent from a scraper before any checkout begins. It rides beneath the card rails rather than replacing them, and it does not settle anything itself.
ERC-8004 Trustless Agents
Contributed to by MetaMask, Google, Coinbase and the Ethereum Foundation
An onchain register of agents. We read it, and never write to it.
Registries for agent identity, reputation and validation. Its own text is candid that existing agent communication standards do not cover discovery or trust, which is the hole it exists to fill.
What is it allowed to spend?
The layer most stacks skip. A permission is only worth something if it is enforced somewhere the agent cannot reach, and if it survives being handed to a second agent.
Agent Payments Protocol
Google
Google's format for a person handing an agent authority to spend.
How a person hands an agent authority to spend: what it may buy, what the person actually asked for, and which credentials may be used. Deliberately abstract enough to sit above several different ways of paying, which is why it composes with the others rather than competing with them.
Verifiable Credentials
W3C
The same permission, carried as a signed credential anyone can check.
The same authority carried as a signed credential that any party can check without calling the issuer.
ERC-7710 Smart Contract Delegation
Ethereum standards process
The same permission again, enforced onchain instead of by us.
Delegated authority enforced by a contract rather than by a service. Useful precisely where the counterparty does not want to trust us either.
Session keys
Wallet ecosystem
Short-lived keys that cover a single stretch of work and then expire.
Short-lived keys scoped to a stretch of work, so a compromise expires instead of persisting.
What is being bought, and for how much?
Two large camps are forming here, built by parties with different incentives, and they do not talk to each other. Most sellers of any size will end up supporting both, because they are reached through different assistants.
Agentic Commerce Protocol
OpenAI and Stripe
OpenAI and Stripe's checkout for agents.
Prescriptive: a defined cart, token and checkout that plugs into what a merchant already runs. Less flexible by design, and already carrying real transactions inside a chat interface.
Universal Commerce Protocol
Google and Shopify
Google and Shopify's. Sellers publish what they can do, agents agree terms.
The other approach: merchants publish what they are capable of and agents work with it. More work for the merchant, more room to move. Most sellers of any size will end up supporting both this and the prescriptive one, because they are reached through different assistants.
Is this transaction legitimate?
There is no standard here at all. The commerce standards say what is being bought. The payment standards say how value moves. Neither says whether this particular payment should happen, and the networks have shipped agent programmes without publishing who is liable when one goes wrong. So this layer is ours.
Deny-first decision
General Liquidity
Arithmetic against the authority you granted, run before money moves rather than after. No standard exists for this layer.
Nobody publishes a standard for this. The card networks have agent programmes without a settled liability framework behind them, and none of the commerce or payment standards say whether a given payment should be allowed. So this layer is ours: arithmetic against the authority you granted, evaluated before the money moves, with the predicates recorded in the order they ran.
Irreversible-outlay bound
General Liquidity
A separate, tighter ceiling on the share of a budget that can go where it cannot be recovered.
A budget can allow a large payment that can be reversed and refuse a much smaller one that cannot. Nested inside the period cap rather than beside it, so it can only ever subtract authority.
Human approval
General Liquidity
A parked payment released by a person holding a credential the agent does not have.
The step everything else defers to. It is measured, because an approval that is always granted is not a control.
Dispute and reversal
General Liquidity
A governed lifecycle before a payout, rather than a support ticket after one.
Runs before a payout rather than after one. This is the gap the networks have publicly not closed: when an agent buys the wrong thing, the rules were written for a human who clicked.
How does the money actually move?
Money moves differently depending on what is being bought. A fraction of a cent for a web request is not an invoice, and neither is a card checkout.
x402
Coinbase, with Cloudflare
Pay for a web request as you make it.
Uses the HTTP status code reserved for payment in 1997 and never implemented. A request hits a paid resource, gets told what it costs, pays, and retries. It is the natural shape for anything sold by the call.
Machine Payments Protocol
Stripe and Tempo, with Visa, Lightning and Solana
The same idea, across cards, stablecoins and Lightning.
The same request-and-pay shape, but deliberately not tied to one way of settling: card, stablecoin or Lightning behind the same exchange.
ATXP
ATXP
A hosted payment server with its own tool store. We pay it as one settlement backend, and we govern it, because its own approval hook defaults to yes.
Not a new way of paying: paid tool calls settle over the same web-request scheme in stablecoins, so it enters as one selectable backend underneath it. What it ships no answer for is the decision. Its own pre-spend hook approves everything by default when unset, runs inside the agent it is meant to constrain, and is handed a payload with no payee, no expiry and no nonce. So we pay it through the same gate as everything else and treat its approval hook as absent.
L402
Lightning ecosystem
Lightning, over the same web request.
The Lightning version of the same idea, and the oldest of them. Suited to amounts too small for anything that charges a fixed fee.
Onchain settlement
Stablecoin issuers and networks
Straight to the chain, for the payments where finality is the point.
Fast, cheap, continuous and programmable, which is why it fits machine-to-machine payments. What it has never had is an agreed standard for business-to-business use with real adoption behind it.
Cards
Visa and Mastercard
Through your own processor. We never hold the card details.
Both networks have built agent-specific token programmes. They are the most familiar way to pay and the least suited to the amounts and frequencies agents actually transact at, and neither has published a settled answer on who is liable when an agent buys the wrong thing.
Wire
Banking system
For the payments businesses actually make to suppliers. Instant finality, no return window, and refused after the daily cutoff rather than queued, because a payment that has not left is not a settlement.
The rail businesses pay suppliers on, and nothing like a card or a chain. It settles the banking day it is sent and cannot be returned, so it is the strictest thing we route: submitted after the cutoff it is refused rather than held overnight, because no receipt claiming instant finality would be true of money that has not moved. The bank stays yours; we hold no credential.
ERC-5792 Wallet Call API
Ethereum standards process
Several onchain actions that succeed together or not at all.
Batch several onchain actions so they succeed together or not at all. It is what stops a payment landing while the thing it paid for does not.
What can anyone check afterwards?
Not on anybody's map, which is the point. Five parties each see a slice of a purchase and none of them sees all of it.
Supply Chain Integrity, Transparency and Trust
IETF
The record, published where a third party can audit it without asking us.
A published, append-only record a third party can audit. Borrowed from software supply chains, where the problem of proving what happened was solved earlier than it was in payments.
Portable receipt
General Liquidity
One string that verifies on its own, with no call back to us.
One string that verifies on its own. No call to us, no account with us, no trust in us.
Finding it is nearly solved. Paying for it is not.
Borrowing the ladder the self-driving world uses, and applying it to the stages of a purchase rather than to the whole journey at once.
- Finding itAgents already read thousands of options without being asked, and sellers are actively making themselves readable to them.
- Mostly autonomous
- Deciding what may be spentThe formats for a person delegating spending authority exist. Adoption does not, largely because nobody has settled who is liable when it goes wrong.
- Early
- Agreeing the purchaseSellers are beginning to state plainly what they will and will not sell to an agent. Most have not started.
- Early
- PayingA person still clicks. Overwhelmingly, purchases that begin with an agent are finished by a human on the seller's own site.
- Barely started
The gap between the top of that list and the bottom is the whole opportunity. An agent that can find anything and pay for nothing is a research tool, not an economic actor.
What a payment layer for machines has to do.
These are the properties argued for publicly by people building in this space. Our answer to each, including the two where the honest answer is not yes.
- Indifferent to how it is paidMet
- If either side supports a way of paying, the transaction should work.
- This is the whole product. The way of paying is a field on the instruction, and everything above it is unchanged.
- Shaped like the web already isMet
- Ordinary HTTP semantics, not a parallel universe with its own vocabulary.
- One request, standard headers, standard problem documents on failure.
- Authorise in milliseconds, settle wheneverMet
- Proving an agent may spend is urgent. Moving the money is not.
- The decision and the settlement are separate steps, and the holding band exists precisely so a bound spend can wait for evidence without blocking the decision.
- Built for machine volumePartly
- The fastest payment systems on earth run at a fraction of the rate the internet moves messages. Agents will transact far above that.
- Batching and delayed finality are how this is approached, and we would rather say plainly that it is unproven at that scale than claim a number we have not reached.
- No intermediary requiredPartly
- The protocol should still work if no third party is in the middle.
- Partly, and worth being exact about. We are in the path when a decision is made, because a limit nobody enforces is not a limit. We are not in the path afterwards: the record verifies with no call to us, no account with us, and no assumption we still exist.
What none of them solves.
Not criticism. These are gaps the parties themselves have published, and they are the reason a layer above the standards has to exist at all.
- Nobody holds the whole trail
- The payment network sees an authorisation. The commerce platform sees a cart. The checkout standard sees a session. The assistant sees what the person originally asked for. Every one of those is a fragment, none of them joins up, and when something goes wrong there is no single account of what happened.
- Agent identity exists in slices
- One standard ties an agent to a card and through it to a legal owner. Another lets an agent carry loyalty between platforms. A third registers it onchain. They run in parallel and none of them is the whole picture.
- No agreed answer on liability
- When an agent buys something the person did not want, the dispute rules were written for a human who clicked. The networks have built agent programmes without publishing a settled framework for who eats the loss, and merchants are choosing their own answers in the meantime.
- Business-to-business has no standard with traction
- Stablecoins have the properties the case needs and no agreed way of using them that anyone has adopted at scale. The older rails are familiar, slower, and were not designed for a buyer that never sleeps.
- Fraud now moves at machine speed
- Valid credentials, unusual addresses, and a buyer that can attempt thousands of times an hour without tiring. The checks that catch this have to run before the money moves, not in a nightly batch.
We do not fix all of these. We cover the standards, and we hold the one thing none of them holds: a single account of what happened, that a third party can check.
What did not make it.
- Two branded card products, because they turned out not to be standards at all.
- A hosted payment service, because it holds the money and pays on your behalf.
- An identity protocol, documented and not used.
Every one above was built against the published specification and then tested against the real thing. More often than not the documentation was wrong, and we only found out by testing. A list only means something if something could have failed to make it.
Missing one you need?
Tell us which, and what your agents are trying to buy through it. Most of this list started as somebody asking.
Get in touch→