ACP, AP2 and x402 Compared
They are presented as competitors and they are not. They answer three different questions, and only one of them is probably yours.
Three protocols, three layers
ACP, AP2 and x402 are routinely presented as competitors and they are not. They sit at different heights in a transaction and an enterprise may well end up using more than one.
The useful way to hold them is by the question each answers. How does an agent complete a purchase at a merchant. How does authorisation from a person travel with that purchase. And how do two machines settle value between them without a human account in the middle.
The Agentic Commerce Protocol
ACP addresses the merchant end. Its concern is how an agent discovers a product, constructs an order and completes a checkout against a real commerce system, with the merchant retaining the customer relationship and the record of sale.
For a retailer or an operator this is the layer that decides whether an agent can transact with you at all. It is also the layer where product data quality stops being a marketing concern and becomes a revenue one, because an agent cannot select what it cannot read.
The Agent Payments Protocol
AP2 addresses authorisation. Its concern is the mandate, being a signed statement made before the purchase that says what the agent may do, presented at the moment of payment so that the authorisation can be checked rather than assumed.
For a bank, an issuer or anyone carrying dispute risk this is the layer that matters, because it is the only one that produces evidence of what a person agreed to. It is also, for the same reason, the layer where the governance work sits. The detail is in the AP2 mandate explainer.
x402
x402 addresses settlement between machines. Its concern is a payment small enough and frequent enough that no human account model fits, made directly over the web transport rather than through a card scheme.
For most enterprises this is not yet urgent. It becomes urgent where agents pay other agents or pay for data and compute per call, and where the per-transaction cost of conventional rails exceeds the value being moved.
Where they overlap and where they do not
The overlap is narrow. All three assume an agent is a first-class participant rather than a user pretending to be a browser, and all three need agent identity to be verifiable. Beyond that they answer different questions and adopting one does not answer the others.
Agent identity is the shared prerequisite and it is worth separating from the protocol question entirely. Whichever layer you operate at, you will be asked which piece of software is acting, who it acts for and what it was permitted to do. An organisation that cannot answer those three has a problem no specification solves, and it will have that problem under all three protocols equally.
The mistake worth avoiding is treating a protocol decision as a governance decision. None of the three decides how narrowly your mandates are drawn, what your system does at an exception, or who is accountable for the configuration. Those are the same four artefacts whatever you adopt, and they are the part a dispute will actually turn on.
How to read the announcements
Coverage of these protocols moves faster than adoption and conflates two different things, being what a specification permits and what is actually running in production. A protocol can be published, endorsed by large names and implemented almost nowhere, and that is the normal state for a year or two.
The practical filter is to ask who is already transacting on it, in which market, and at what volume. Where the answer is a pilot, the correct response is to keep the option open rather than to rebuild anything. Where the answer is real volume in a market you sell into, the timeline is no longer yours to set.
A sequence that works
Establish your exposure layer first. Then measure what a machine can currently read of your products, because that is cheap, entirely within your control and useful whichever protocol wins. Then write the four governance artefacts, being mandate scopes, an exception policy, an evidence trail and a named accountable owner, because they are identical across all three protocols.
Only then choose. By that point the choice is narrow, reversible and mostly determined by which of your counterparties has already moved. Organisations that reverse this sequence spend the first six months integrating a specification and the second six discovering they cannot say who authorised anything. The sequence is deliberately boring, and that is the argument for it. Every step except the last holds its value whichever protocol prevails, which means the work is not wasted if the market turns, and the last step is the only one you can afford to get wrong twice. The framing is in agentic commerce governance.
Start the conversation
We advise companies on agentic commerce, from first assessment through to a defensible implementation decision.
Contact contraco