← All guides · Selling to AI agents

ACP vs. AP2 vs. x402: Which Agent Payment Rail Should You Implement?

Part 3 of Selling to AI agents · 1,603 words · published 2026-07-30 · updated 2026-07-30 · Markdown variant

A decision framework for choosing between ACP, AP2, and x402 (plus the self-hosted 402 gate) — sorted by who your buyer actually is, what you are selling, and what is live versus waitlisted today.

Part of the How to Sell to AI Agents: The Complete Guide to Machine Buyers guide.

Before comparing ACP, AP2 and x402 feature-by-feature, answer one question: which of two entirely different problems are you actually trying to solve? The full mechanics of each protocol — Shared Payment Tokens, Intent/Cart/Payment Mandates, the x402 handshake, the CAIP-2 network list, the comparison table — are documented at length in agentic payment protocols; this article does not repeat any of that. It covers the decision the resource does not make for you: given what you sell and who is actually paying, which rail to build, and in what order.

This is the rail-selection companion to how to sell to AI agents, which lays out the full five-stage machine purchase funnel and names four live payment rails at Stage 4. This piece narrows to the specific comparison between ACP, AP2 and x402 that funnel skims past — because those three names get lumped together constantly in coverage of "agent payments", and they are not interchangeable.

The question that actually sorts these rails

ACP and AP2 gate a different thing than x402 and the self-hosted 402 gate do: ACP and AP2 authorize an agent to spend a human's money, with the human's consent, over conventional fiat rails — letting a shopping assistant complete checkout at a merchant without that person typing a card number in every time. x402 and a self-hosted 402 gate settle a payment directly against a request, and the buyer can be software all the way down: an agent spending its own funds (x402) or reusing a key a human bought once (402-plus-key).

That gives you the real decision axis, and it is not a protocol comparison — it is a buyer question:

A second axis narrows it further inside each branch. Inside the "software pays for itself" branch: is your buyer crypto-native (holds a wallet, can sign a stablecoin authorization) or fiat-only (its operator would rather pay a card once)? That decides x402 versus 402-plus-key — agent wallets: paying per run with x402 covers the buyer-side loop. Inside the "agent spends a human's money" branch: do you want reach specifically inside ChatGPT's Instant Checkout, or broader cross-network reach across whichever assistants adopt the FIDO-governed spec? That decides how much weight to put on ACP versus AP2, which are additive rather than mutually exclusive.

Scenario 1 — you sell an API or content that agents buy for themselves

If your product is API calls, a document, or a tool invocation, and the buyer is the agent — not a person the agent represents — ACP and AP2 are the wrong protocols to reach for at all. Neither one gates a resource or settles against a fetch; both assume a merchant checkout flow with a named consumer behind it. The choice here is between x402 and a self-hosted 402 gate, and it is almost entirely a question of whether your buyer holds a wallet.

A wallet-holding agent making one-shot or per-call purchases with no human anywhere in the loop is the case x402 was built for: it signs a stablecoin transfer authorization and retries, no account and no sign-up. An agent whose operator would rather complete one ordinary checkout and reuse a credential indefinitely is the case for a self-hosted 402 gate. Nothing stops you offering both on the same resource — reaching a crypto-native buyer on one path and a fiat-only buyer on the other.

Scenario 2 — you sell something a human's agent buys on their behalf

If your product is a consumer purchase — a subscription, a physical good, a service booking — and the buyer is a person's shopping agent acting with that person's consent and card, x402 and a self-hosted 402 gate are the wrong tools. Neither has a concept of a human principal whose spend needs authorizing; they gate a fetch, not a checkout on someone else's behalf. This is ACP or AP2 territory, and the practical choice is mostly about where you want to show up. As of July 2026, ACP currently powers OpenAI Instant Checkout inside ChatGPT, and a merchant already running Stripe has the shorter path since Stripe co-developed the spec. AP2 aims at broader cross-network reach under FIDO Alliance governance with a wider partner roster, but a specific stable version is not independently confirmable from primary FIDO Alliance sources as of this writing. As of July 2026, implementing ACP is the more settled bet; tracking AP2 is reasonable, committing engineering time to it ahead of a confirmed stable spec is not.

Scenario 3 — you sell both, and the rails coexist

A seller with more than one product line does not have to pick one rail company-wide. As an illustrative pattern — not a claim about any real deployment — imagine a company selling two things: a metered data API that other agents call programmatically, and a consumer subscription a person's shopping assistant might buy on their behalf. There is no conflict in running x402 (or a 402-plus-key gate) on the API product, gating each call directly, while separately accepting ACP-authorized checkout on the subscription product, so a consumer agent can complete that purchase with the buyer's consent and card. The two rails sit on different products, answering different buyer types, not layered on top of each other for the same transaction. Treat this as a hypothesis about how a multi-product seller could structure things, not a case study — no company is named here because none has been independently verified running exactly this combination.

What is actually live versus still waitlisted, as of July 2026

Adoption cost is not equal across these four names, and the gap between "live" and "announced" changes what you should build first.

The practical read, as of July 2026: if your buyer is software paying for itself, you can ship a working rail this quarter on either x402 or a self-hosted 402 gate — both are mature enough to build against today. If your buyer is a human's shopping agent, ACP is the more settled integration target; AP2 is worth architecting toward but not worth blocking a launch on.

ChangeGamer's own position, stated exactly

This site is a useful, narrow example precisely because its status is small and checkable rather than impressive. The self-hosted 402-plus-Bearer-key rail described in paying for access: the HTTP 402 flow is live in production: a 402 body with price_usd and a payment_url, a webhook-minted key, retries with Authorization: Bearer <key>. The native x402 endpoint exists as code but is dormant — every request answers 503 x402_not_configured because none of the operator environment variables that would enable on-chain settlement are set. ACP and AP2 are not implemented here at all, and that is not an oversight: this site has no consumer checkout flow for a human's agent to complete on someone else's behalf, so neither protocol has a job to do yet. If that changes, ACP would be the first of the two worth integrating, for the reason given above — it is the more settled spec today (as of July 2026).

For the mechanics of what a checkout actually has to do to be completable by a machine at all — independent of which of these four rails sits behind it — see agent checkout vs. human checkout; that article covers the failure modes at the point of payment, this one covers which rail to put behind that point.

A short decision checklist

• Name your buyer first: software paying for itself, or a human's agent spending the human's money. Everything else follows from this.
• Buyer is software, paying for itself: crypto-native → x402; fiat-only, or you want a reusable credential → self-hosted 402 gate. Run both if your buyers split across the two.
• Buyer is a human's agent: build ACP first if you already run Stripe or want reach inside ChatGPT's Instant Checkout; track AP2 for broader reach but do not treat it as shippable yet.
• Do not force one rail across product lines with genuinely different buyers — two rails on two products is matching the rail to the transaction, not technical debt.
• State your own status honestly, the way you'd want a competitor to: which rail is live, which is scaffolded-but-dormant, which is not built. A wrong "we accept x402" claim is worse than a smaller, accurate list.

#payments #x402 #acp #ap2 #agents #monetization #402