What is each one for?#
The clearest way to separate them is by what is being bought.
| x402 | ACP | |
|---|---|---|
| What you buy | An API call, a data point, compute | A product, from a merchant |
| Who the seller is | Any endpoint | A merchant with a processor |
| Payment rail | Stablecoin, on-chain | The merchant's existing processor |
| Price point | Fractions of a cent upward | Retail prices |
| Buyer identity | None required | Usually attached to a person |
| Refunds | None, settlement is final | The merchant's normal process |
| Integration cost for the seller | A 402 response | A commerce integration |
ACP exists because agents started doing shopping and the card rails already worked. Rather than inventing new money movement, it structures the conversation between an agent and a merchant and hands the payment to the merchant's existing processor through a shared payment token.
x402 exists because the thing an agent buys most often is not a product at all. It is a search, a lookup, an inference, a proof. Those are priced in fractions of a cent, sold by endpoints rather than merchants, and bought thousands of times a day.
Why not use card rails for everything?#
Because the economics do not survive the price point.
A card payment has a fixed cost, typically a flat component plus a percentage. At a $40 order that cost is a rounding error. At a $0.002 API call it is many multiples of the payment. There is no version of card interchange that works for a tenth of a cent.
There is a second reason that matters more for autonomy: a card belongs to someone. Using it means a cardholder, a billing relationship and usually a human-approved mandate. An agent paying a stranger for one call has none of that and does not want it.
Important
This is why "which protocol wins" is the wrong question. Interchange economics make card rails impossible below a cent and make stablecoin rails unnecessary above a few dollars, where chargebacks and consumer protection are worth paying for. The two occupy different price bands by construction.
Where do they overlap?#
In one real place: a mid-priced digital purchase an agent makes on a person's behalf. A $15 dataset, a $9 report, a month of a service. Either could carry it.
The deciding questions are not technical.
- Does the buyer need to be refundable? If yes, card rails. An x402 settlement is final and a refund is a new payment you have to choose to send.
- Does the seller already have a processor? If yes, ACP is less work. If the seller is an endpoint with no commerce stack, standing up a merchant account to sell a $9 report is absurd.
- Does the buyer have an account? If the relationship is ongoing and identified, cards are fine. If the buyer arrived thirty seconds ago, the sign-up is the thing that kills the sale.
What about proof of authorisation?#
Neither one is the answer to that, and it is a third question rather than a tiebreaker between these two.
ACP attaches to a payment method that usually belongs to an identified person, which gets you some of the way. x402 attaches to a wallet key, which gets you none of it. If you need to prove a user agreed to a specific purchase, that is AP2's job, and it composes with either.
Which should a seller implement?#
Pick by what you sell, not by which standard has more members.
You sell API calls, data or compute. x402. The integration is a 402 response and a facilitator call, and it opens you to buyers who will never sign up.
You sell physical or retail goods. ACP. Your processor relationship, your fraud tooling and your refund process are assets, not obstacles, and throwing them away to accept stablecoins would be a strange trade.
You sell mid-priced digital goods to consumer agents. Probably ACP, because the refund path is worth more than the fee saving at that price.
You sell to agents operated by developers. x402, and offer keys for the ones who integrate properly. How agents pay for APIs covers that pairing, which is the practical answer for most API businesses.
Frequently asked questions#
Can I support both?#
Yes, and for a seller spanning both price bands it is the right answer. They touch different parts of your stack and do not conflict.
Is ACP open?#
It is published by OpenAI with Stripe and is implementable by other processors. Governance is less distributed than x402's foundation model, which matters more for a long-lived integration than it does on day one.
Does ACP work without an agent?#
The protocol structures agent-driven checkout specifically. A human checkout does not need it; your existing flow already works.
Which has more live volume?#
Not comparable in any honest way. They count different things in different units: ACP moves retail orders through processors, x402 moves micropayments on-chain. Anyone presenting a single league table across both is adding transactions that are not the same kind of thing.
Can an agent pay with ACP without a human?#
The design assumes a payment method with an owner. Fully autonomous spend with no human anywhere in the chain is the case x402 was built for and the one card rails are least comfortable with.
Where to check this yourself#
The x402 side is checkable and the ACP side is not, which is worth sitting with. Every x402 settlement is on a public chain: /transactions is the record, /services is what is being sold, and the data API answers both programmatically. ACP volume runs through private processors, so there is no equivalent third-party view of it.