Table of Contents
The question gets asked as though the three standards were competing for the same slot. They are not, and that misreading is the most expensive mistake a team can make here.
x402 moves the money. AP2 proves the user authorised the purchase. ACK-Pay proves who the agent is and what it was paid for. A team that picks one believing it covers the others ships a gap it will discover in production.
The useful comparison is therefore not which standard wins. It is which layer your product actually needs first, and which choices leave the other layers available later.
These are not three answers to one question. They are three answers to three questions, and most serious deployments will eventually touch all of them.
Key Takeaways
- The three standards govern different layers, not competing rails.
- x402 moved to the Linux Foundation as a neutral project.
- AP2 standardisation is moving into the FIDO Alliance.
- ACK-Pay issues receipts as verifiable credentials, rail-agnostic.
- Start with the layer your first failure would come from.
Three Layers, Not Three Competitors
Separate the stack before comparing anything, because each standard occupies a different part of it.
The settlement layer answers how value moves for a single request. The authorisation layer answers whether a human agreed to this purchase, at this price, within these limits. The identity and attestation layer answers who the paying agent is, who is accountable for it, and what proof exists afterwards.
x402 is strongest at the first, AP2 at the second, and ACK-Pay at the third. That framing also explains why the specs reference each other rather than attacking each other.
Authorisation is the layer teams underestimate most, which is the argument our analysis of payments for AI agents makes about rails being ready before permissions are.
What to note: write down which layer your first production incident would come from, because that is the layer to solve first.
x402 Is the Settlement Layer
x402 revives HTTP 402 as a working status code and makes a paid request a two-step exchange.
A client requests a protected endpoint and the server responds with 402 plus its requirements in a payment-required header. The client signs a payment payload and repeats the same request with the signature attached, the server verifies it locally or through a facilitator, and settlement details come back with the 200 response. Note that the header names were revised during 2026, so older tutorials referencing an X-PAYMENT header describe a superseded draft.
The facilitator is the part worth understanding commercially. It verifies payloads and broadcasts the settlement transaction so the seller never runs blockchain infrastructure, and Coinbase's hosted facilitator covers EVM chains including Base, Polygon and Arbitrum plus Solana, with a free monthly transaction allowance before a fee of a tenth of a cent per transaction.
Governance changed in a way that matters for anyone choosing a long-lived dependency. x402 now runs as a Linux Foundation project with its own foundation and working groups, which makes it considerably easier to justify than a single vendor's protocol.
What to note: x402 says nothing about whether a human approved the spend, so it is a payment mechanism rather than a control framework.
AP2 Is the Authorisation Layer
AP2 starts from the problem that a merchant has no way to know whether an agent was actually told to buy something.
Its answer is the mandate, a tamper-evident signed credential that records user intent. The current specification works with a Checkout Mandate covering the items and purchase details shared with the merchant, and a Payment Mandate authorising a specific instrument and shared with credential providers and processors. Each exists in an open stage capturing constraints such as budget and allowed instruments, and a closed stage authorising a finalised amount.
Many secondary write-ups still describe AP2 in terms of an Intent Mandate and a Cart Mandate, which was the earlier naming. Chained together, these credentials produce a non-repudiable audit trail for transactions whether or not the user is present.
Two details decide whether AP2 fits. It launched around pull payments such as cards, with push rails and digital currencies on the roadmap and an x402 flow among its samples, and it is published under Apache 2.0 by Google with standardisation now moving into the FIDO Alliance working groups on agentic authentication and payments.
What to note: AP2 is an extension of A2A rather than a standalone rail, so it assumes an agent-to-agent architecture around it.
ACK-Pay Is the Identity and Receipt Layer
ACK-Pay comes from the opposite direction, treating identity and proof as the missing primitives rather than the transport.
It is one half of the Agent Commerce Kit, paired with ACK-ID, which builds a cryptographic chain from an accountable legal entity to the agent acting for it using W3C decentralised identifiers and verifiable credentials. The payment half standardises how requirements are communicated, how payments are initiated through a payment service, and how confirmation is issued as a verifiable credential receipt.
The deliberate design choice is rail neutrality. ACK-Pay positions itself alongside card-network programmes and the 402-style stablecoin implementations rather than replacing them, so x402 can be the settlement path inside an ACK-Pay flow.
It is MIT licensed and was built by Catena Labs before being contributed as an open project, and the practical build path is covered in our walkthrough of ACK-Pay settlement.
What to note: the receipt is the feature finance teams care about, because it is the artifact that makes an agent payment auditable after the fact.
The Shift Underneath All Three
Step back from the specs and one economic change explains why all three appeared within roughly a year of each other.
The minimum viable transaction has collapsed. A fixed card fee made anything under a dollar absurd, and a rail where cost scales with amount makes a fraction of a cent for a single API call a sensible price, which is what per-request pricing requires to exist at all.
Consumer finance went through the same collapse slightly earlier and it is worth noticing because it is the same mechanic. Minimums that once gated participation are gone, so an offer to invest $5, earn $25 is possible for the same structural reason a $0.004 API call is, which is that the cost of processing stopped setting the floor on the size of a transaction.
For builders the implication is that pricing models, not protocols, are the thing being unlocked. The standard you choose determines how safely you can charge per action, and the business question is whether charging per action is better than charging per seat.
What to note: if your product does not benefit from per-action pricing, none of these standards is urgent for you yet.
The Three Standards Compared
| Dimension | x402 | AP2 | ACK-Pay |
|---|---|---|---|
| Layer it solves | Settlement for one request | Authorisation and user intent | Identity and verifiable receipts |
| Origin | Coinbase, now a Linux Foundation project | Google, standardising via FIDO Alliance | Catena Labs, contributed as open source |
| Licence | Open specification under foundation governance | Apache 2.0 | MIT |
| Primary rails | Stablecoins on EVM chains and Solana | Cards first, push rails and digital currencies on roadmap | Rail-agnostic, including card networks and 402 flows |
| Proof it produces | An onchain settlement record | A chain of signed mandates | A receipt as a verifiable credential |
| Natural fit | Paid APIs, data and tool calls | Consumer and merchant checkout | Regulated flows needing audit trails |
Read along the first row and the decision gets much simpler. Most teams need the row that matches their first hard requirement, and can adopt the others as the product grows into them.
What to note: nothing in this table is mutually exclusive, and the specs were written assuming composition rather than exclusivity.
How to Choose Without Rebuilding Later
1. Identify who needs convincing
If a seller needs to know the payment is real, you need settlement. If a merchant or bank needs to know a human agreed, you need mandates. If an auditor or counterparty needs proof afterwards, you need receipts.
2. Match the rail to the buyer
Software buying from software settles naturally in stablecoins per request. A consumer buying physical goods through an agent still runs on card rails, which is the world AP2 was designed for first.
3. Treat limits as separate from the standard
None of these protocols caps what an agent spends in a day. That enforcement is your own policy layer, and the mechanics are in our guide to agent spend limits.
4. Ship one flow before standardising on anything
Build a single paid endpoint or a single mandated checkout end to end, including the failure cases. A working narrow implementation teaches more than a protocol comparison, this one included.
5. Prefer the layer with neutral governance
For a dependency you expect to keep for years, a foundation with working groups is a materially different risk from a single company's roadmap. Both x402 and AP2 moved in that direction during 2026, which is the strongest signal in this entire comparison.
What to note: the composition you want is usually identity around authorisation around settlement, built in whichever order your constraints demand.
Risks and Limitations
- All three are young, and header names, mandate naming, and endpoints have already changed once.
- Secondary documentation is frequently out of date, so the specs are the only reliable reference.
- Settlement remains irreversible, and no standard here restores a dispute mechanism comparable to a card chargeback.
- Facilitator and platform allowances are generous until a threshold, after which per-transaction fees apply.
- The field is wider than these three, and competing commerce protocols from other vendors are also live.
Conclusion
Which agent payment standard should you build on? The one that matches the layer where your product breaks first, because these three were not designed to be alternatives.
Build on x402 if the job is charging per request and settling in stablecoins without running chain infrastructure. Build on AP2 if the hard part is proving a user authorised a purchase on rails that merchants already accept. Build on ACK-Pay if identity and an auditable receipt are what your counterparties or regulators will demand.
The composability is the real answer. An ACK-Pay flow can settle over x402, AP2 ships x402 among its samples, and the teams likeliest to be right in two years are the ones that chose one layer deliberately and left the other two open.
Read Next:
FAQs:
1. Are x402, AP2, and ACK-Pay competitors?
Mostly no. x402 handles settlement for an individual request, AP2 handles proof that a user authorised a purchase, and ACK-Pay handles agent identity and verifiable receipts, and each specification explicitly accommodates the others rather than excluding them.
2. Who controls each standard now?
x402 operates as a Linux Foundation project with its own foundation and working groups. AP2 is published by Google under Apache 2.0 with standardisation moving into FIDO Alliance working groups on agentic authentication and payments. ACK-Pay is MIT licensed and was contributed as an open project by Catena Labs.
3. What are AP2 mandates?
They are signed, tamper-evident credentials recording authorisation. The current specification uses a Checkout Mandate for the items and purchase details shared with the merchant and a Payment Mandate for the instrument, each with an open stage for constraints and a closed stage authorising a finalised amount.
4. Does x402 still use the X-PAYMENT header?
No. The current documentation describes a payment-required header on the 402 response, a payment-signature header on the retried request, and a payment-response header carrying settlement details, so tutorials referencing X-PAYMENT are describing an earlier draft.
5. Can one product use more than one of them?
Yes, and that is the expected pattern. ACK-Pay can use an x402 flow as its settlement path, AP2 includes an x402-based sample, and a mature deployment typically layers identity around authorisation around settlement.
Disclaimer:
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional. These specifications are evolving quickly and header names, mandate structures, fees, and supported networks have already changed; verify every technical detail against the official documentation before building on it.
