Which agent commerce protocol should you build on?
TL;DR: key takeaways
- These three are not competitors. x402 is a settlement flow, AP2 is an authority model, ACP is a merchant checkout integration.
- Pick by who your buyer is: a machine buying compute, or a person's agent buying goods.
- None of the three decides whether a payment is a good idea. All three leave spend control to you.
- Building for two rails is less work than it sounds, because the risk layer is shared and only the protocol checks differ.
Three specifications landed inside five months, every one described as the agent commerce protocol, and none of them doing quite the same job. If you are choosing what to build against, the marketing is actively unhelpful; they read like competitors and behave like layers. This piece puts x402, AP2 and ACP side by side, says plainly what each solves and ignores, and gives you a way to choose that does not depend on guessing which one wins.
The confusion is structural
The phrase "agent commerce protocol" is doing too much work. It gets applied to at least three different problems:
- How does a machine pay for a request? A wire protocol. Negotiation, settlement, retry.
- How does an agent prove a human said yes? An authority model. Signed grants a merchant can verify.
- How does a merchant expose its shop to agents? A commerce integration. Catalogue, cart, checkout.
x402 is mostly the first. AP2 is mostly the second. ACP is mostly the third. Comparing them head to head is like comparing HTTPS, OAuth and Shopify, all real, all necessary, none replacing another.
Three agent commerce protocol options, briefly
x402: published by Coinbase, May 2025. Revives HTTP 402 Payment Required. A server quotes a price machine-readably, the client pays, the request retries with a signed payload. Optimised for micropayments and stablecoin settlement. The specification is short; we wrote a longer walk-through of the HTTP 402 flow.
AP2: published by Google, September 2025. The Agent Payments Protocol. Its unit is the mandate: a signed object recording what a human actually approved, verifiable by a merchant. Rail-agnostic by design, the mandate can front cards, transfers or stablecoins. See AP2 payment safety and the protocol documentation.
ACP: the Agentic Commerce Protocol, from OpenAI and Stripe, also September 2025. Concerned with merchants and agents transacting: product feeds, checkout sessions, order handoff. Closest to conventional e-commerce, which is both its strength and its ceiling.
Side by side
| x402 | AP2 | ACP | |
|---|---|---|---|
| Published | May 2025 | September 2025 | September 2025 |
| Primary problem | Paying for a request | Proving authorisation | Merchant checkout for agents |
| Unit of work | HTTP 402 quote and retry | Signed intent and cart mandates | Checkout session |
| Typical amount | Fractions of a cent to a few dollars | Consumer purchase | Consumer purchase |
| Settlement | Stablecoin, on-chain | Rail-agnostic | Card rails via existing processing |
| Human in the loop | No | Encoded before the fact, as a mandate | Optional, varies |
| Best for | Agents buying compute, data, APIs | Agents buying on a person's behalf | Merchants selling to agents |
| Leaves to you | Whether to pay at all | Whether the authorised thing is sensible | Whether the agent should be buying |
Table: the three agent commerce protocol options compared on what they actually specify. Compiled from each project's published specification, August 2026.
Read the last row twice. It is identical in substance across all three columns, and it is the row that costs money.
Choosing an agent commerce protocol: two questions
You can usually settle this without a spreadsheet.
Question one: is your buyer a machine or a person's proxy?
A machine buying compute, data or API calls has no human to consult and no consumer-protection story to tell. That is x402's territory. The amounts are tiny, the frequency is enormous, and the whole point is that nobody approves anything.
An agent buying goods for a named human is a different animal. Somebody will eventually ask what that person agreed to, and "we have logs" is a weaker answer than a signed mandate. That is AP2's territory.
Question two: are you the buyer or the seller?
If you are selling to agents, ACP is the one with your name on it. It answers how your catalogue and checkout become legible to a shopping agent. x402 and AP2 barely address this.
If you are the buyer (running the agents, holding the credentials, carrying the losses), ACP is largely somebody else's integration and your attention belongs on the other two.
"Nearly every team we talk to is asking which rail to bet on, and nearly none of them will actually have to bet. The rail changes which protocol checks are available. It does not change the spend cap, the velocity signal, or the log you will want when something goes wrong."
the Spend7 engineering team
What building for two rails actually costs
Less than people expect, provided you get the layering right.
The wrong shape is a payment path per rail, each with its own limits, its own logging and its own idea of what an agent is. Now you have two of everything and two places for the budget to be wrong.
The right shape is one decision layer that takes an intent (amount, counterparty, agent, rail) and returns allow, flag or deny. Underneath it, rail-specific checks: quote overrun and nonce replay for x402; mandate presence, expiry and cart-versus-intent for AP2. Above it, the things that do not care about rails at all: spend caps, velocity, retry-loop detection, the decision log.
In practice the rail-specific portion is a small fraction of the work. Everything expensive (history, baselines, caps, evidence) is shared.
A worked example
A procurement agent at a design studio does two unrelated things.
It buys stock imagery on behalf of a named art director, up to £300 a month. And it pays per-call for a background-removal API at roughly £0.002 a request, several thousand times a day.
Two rails, obviously. The imagery purchases want AP2: there is a human, an authority, and a dispute someone might raise. The API calls want x402: no human, no dispute, just volume.
One risk layer, though. The same daily cap should see both. If the agent burns £280 on imagery and then loops on the API, the cap that stops it does not care that the two payments settled through different protocols. Split the risk layer by rail and neither half can see the aggregate, which is the exact moment an agent overspends while every individual system reports itself healthy.
Common pitfalls
Picking a rail before knowing your buyer. The single most common way to end up rebuilding. Answer "machine or proxy" first; the rail follows.
Assuming a signed mandate means a sensible purchase. AP2 proves authorisation. It cannot tell you the agent was manipulated into something you technically permitted.
Building spend control per rail. Guarantees no view of the total. See the example above.
Waiting for a winner. These are not fighting. A market with a settlement flow, an authority model and a merchant integration is a market with three layers, not three contenders.
Reading demand as adoption. Our Google Ads Keyword Planner measurement on 8 August 2026 put "agent commerce protocol" at 140 US searches a month, "AP2 protocol" at 210, and "x402 payment protocol" at 30, against 5,400 for "agentic commerce" and 110,000 for "agentic ai". People are interested in the category and almost nobody is searching for the specifications yet. Early is not the same as decided.
The short version
Buying compute and data: x402. Buying on a person's behalf: AP2. Selling to agents: ACP. Doing more than one: pick the rails independently and share the risk layer.
Spend7 checks x402 and AP2 protocol defects natively and applies the same caps, signals and decision log regardless of rail: see the x402 rail page, the AP2 rail page, or just get a key and score an intent.
Frequently asked questions
- What is an agent commerce protocol?
- A convention that lets software buy something without a person at the checkout. Different protocols pick different parts of that problem: how the payment is negotiated on the wire, how the agent proves a human authorised it, or how a merchant exposes its catalogue and checkout to agents. The term is used loosely for all three, which is a large part of why comparisons get confusing.
- Is x402 or AP2 better?
- They are not substitutes, so the question does not resolve. x402 answers how a machine pays for an HTTP request; AP2 answers how an agent proves a human sanctioned a purchase. If your agent buys API calls and compute, x402 is the relevant one. If your agent buys goods on a person's behalf, AP2 is. Systems doing both will implement both.
- Do I have to choose one agent commerce protocol now?
- No, and committing early is the more expensive mistake. Keep the payment decision (should this settle) in a layer that does not care about the rail, then the rail becomes an implementation detail you can add to. The protocol checks differ between rails; the spend caps, velocity signals and decision log do not.
- What does none of these protocols do?
- Decide whether the payment is wise. Every one of them will happily carry a payment that is correctly formed, correctly authorised, and a disaster: a retry loop, an inflated amount, a substituted counterparty. Spend control and anomaly scoring sit above all three, which is why they are worth building once rather than per rail.
Score a payment before it settles
Spend7 returns allow, flag or deny in one call, with the signals that produced it. The free tier covers a single agent, its spend caps and its full decision log.
