AP2 vs x402
What permits the action, and what pays for the resource?
An HTTP payment flow and a purchase-authorization protocol answer different questions. Payment success alone does not define the full scope of a shopper’s authority. Document the authorized intent separately from the resource payment. Confirm both are supported by your actual providers, rather than inferring interoperability from an ecosystem diagram.
What this establishes
A practical way to inspect evidence and make the next merchant decision.
What it cannot establish
Live merchant deployment, private account eligibility, purchase completion or guaranteed AI selection.
The overlap
An HTTP payment flow and a purchase-authorization protocol answer different questions. Payment success alone does not define the full scope of a shopper’s authority.
The merchant decision
Document the authorized intent separately from the resource payment. Confirm both are supported by your actual providers, rather than inferring interoperability from an ecosystem diagram.
Where they overlap.
Where they complement.
Compare roles and implementation work. A shared capability does not make two systems interchangeable.
| Decision dimension | AP2 | x402 |
|---|---|---|
| Layer | Identity & trust | Payments |
| Role | Uses linked checkout/payment mandates and receipts to bind authorization. | Connects a resource request to payment requirements and a paid retry. |
| Status | released | published specification |
| Version | 0.2.0 | 2 |
| Discovery | Outside scope | Resource-specific payment requirements |
| Checkout | Authorizes checkout; does not define commerce API | Outside retail checkout scope |
| Payment | Mandates and receipts; not a settlement rail | HTTP 402 payment flow |
| Authorization | Core role | Scheme-dependent |
| Transport | Integration with commerce protocols | HTTP-native |
| Adoption | Public specification; individual deployments Unknown | Public implementations; merchant deployment Unknown |
| What it does not solve | Does not define the catalog API or replace a commerce protocol. | Does not describe a retail order, shipping policy or return workflow. |
| Evidence | 3 source record(s) Checked 2026-09-28 public-preview; scope-dependent | 3 source record(s) Checked 2026-09-28 live; scope-dependent |
Unknown ≠ unsupported. Announcements and product documentation are not proof of your live integration.
Overlap and replacement risk
These entries occupy different layers. They can work together; replacing one with another may leave a commerce, communication or authorization gap. Keep your source of product truth, fulfillment responsibility and payment obligations explicit.
Go to the source.
Primary documentation records what is publicly stated. It does not independently prove outcomes or your account’s eligibility.
Claim scope: Authorization mandates and receipts
Payment authorization within a commerce protocol; catalog API details are out of scope.
Claim scope: Stewardship and integrations
Site states continued standardization within FIDO working groups.
Claim scope: Version metadata and documented changes only; not merchant adoption.
SHA-256 of retrieved source response: 43572d4defa8d53e8ab8dbfe90cc2d6734892aa93fcce009015d73cf21336ad6
Claim scope: HTTP payment flow
Repository says canonical development moved to x402 Foundation; Coinbase repo is a development fork.
Claim scope: Internet-native payments
Claim scope: Version metadata and documented changes only; not merchant adoption.
SHA-256 of retrieved source response: aa6dc5e8ccc7758689945fc7502674f51cd0f21f09ec886aa1dbc4cd86bc81b6