What does each one actually do?#
The names make them sound like alternatives. They are layers.
| x402 | AP2 | |
|---|---|---|
| Question answered | How does the money move? | Who agreed to this? |
| Moves funds | Yes | No |
| Artefact produced | An on-chain settlement | A signed mandate |
| Rails | Stablecoins on-chain | Rail-agnostic by design |
| Typical buyer | An agent paying an API | A person delegating to an agent |
| Authorisation model | Implicit, per request | Explicit, signed in advance |
x402 answers a 402 with terms, takes a signed authorisation and settles it. It does not ask, and cannot answer, whether a human ever agreed to the agent spending that money.
AP2 does exactly that and nothing else. A user signs a mandate describing what their agent may buy, and the agent presents it. No funds move as a result of AP2; the mandate is evidence.
When does the difference bite?#
When something goes wrong and somebody has to establish what was agreed.
An x402 settlement proves a transfer happened. It proves nothing about whether the buyer was supposed to make it. If an agent spends a user's money on something the user never wanted, the settlement record shows the payment and is silent on the authority.
An AP2 mandate is the record of that authority. For a $0.002 API call it is overhead nobody needs. For a $400 purchase on a user's behalf it is the difference between a dispute you can resolve and one you cannot.
Note
The amount is the rough guide, but the real test is whether a human would be surprised. Machine-to-machine infrastructure spend, paid from a budget the operator set, needs no mandate. Anything a user would recognise as a purchase they personally made probably does.
Does AP2 make agent spending safe?#
Not on its own, and the published security work on it is worth reading before relying on it.
Analysis in 2026 made a point that generalises past AP2: a signed mandate proves the user signed, not that the user understood. If an agent's context can be manipulated, through prompt injection in a document or a web page it reads, the agent can present a validly signed mandate for a purchase the user never intended. The signature is real. The intent behind it is not.
That is not a flaw you fix in the protocol. It is an argument for the other controls: budget caps, counterparty allowlists, expiring permissions and a kill switch. Agent wallet spending controls covers the enforcement side, and it matters that the strongest version of those controls is on-chain rather than in an agent's own reasoning.
How do they compose in practice?#
The shape most systems end up with:
- A user authorises an agent, and that authorisation is captured as an AP2 mandate or an equivalent signed artefact.
- The agent operates inside a budget, enforced by its wallet rather than by its prompt.
- Individual machine purchases settle over x402, each one an ordinary 402 exchange with no mandate attached.
- Purchases that a user would recognise as theirs carry the mandate through to the merchant.
Note what layer 2 is doing. Neither protocol provides budgets: AP2 proves what was agreed and x402 proves what moved, and neither one stops an agent spending more than it should. That control lives in the wallet, and leaving it out because two protocols are in the stack is a common and expensive mistake.
Which should I build on first?#
Build on whichever matches your buyer.
Your buyer is software, paying for infrastructure. Build x402. Mandates add a layer that has no human to protect, and the per-call overhead buys nothing.
Your buyer is a consumer agent acting for a person. Start with authorisation, whatever settles the money. The risk in that business is a user disputing a purchase, not a payment failing to settle.
You sell to both. They compose, so do x402 for the machine path and add mandate handling on the consumer path. They are not in conflict at any layer.
The agent payment protocols compared puts ACP and Stripe's MPP alongside both, which is the rest of what people are choosing between.
Frequently asked questions#
Can AP2 settle in stablecoins?#
AP2 is rail-agnostic by design and sources describe stablecoin support alongside cards and bank transfers. The mandate describes the authority; what settles it is a separate choice. In principle a mandate can authorise an x402 payment.
Does x402 have any concept of authority?#
Only implicitly. Holding the key that signs the authorisation is the authority. That is adequate when the key holder is the economic owner of the funds and inadequate when it is an agent operating on someone else's behalf.
Is one of them winning?#
They are not in the same race. On deployment, x402 has far more live settlement because it has been in production longer and its unit of use is smaller. On consumer checkout, card-rail protocols have the merchant relationships. Expect both, in different places.
Do I need a blockchain to use AP2?#
No. That is the point of being rail-agnostic. A mandate can authorise a card payment with no chain involved anywhere.
What stops an agent reusing a mandate?#
The mandate's own scope and expiry, which is why both should be tight. The same reasoning applies to an x402 authorisation: short validity windows limit what a leaked artefact can do, in both protocols.
Where to check this yourself#
For the settlement half you can check the claims directly: /transactions is the live x402 record and /facilitators shows who relayed it. For the authorisation half there is no equivalent public record, which is itself the thing to notice. Mandates are private artefacts held by the parties, so AP2 activity cannot be measured from outside the way x402 activity can.