The shape of the question

By mid-2026, three protocols have emerged as the serious contenders for how AI agents move money: x402, AP2, and ACP. Conference talks treat them as competitors. Vendor decks position them as alternatives. Twitter threads ask which one will win.

That framing misses what is actually happening. The three protocols are solving different problems. They are not three answers to the same question; they are three answers to three questions that have been awkwardly conflated under the label "agent payments". This post takes each one apart, says what it does, what it does not, and where it actually fits in a real agent product.

The conclusion - which we will earn rather than assert - is that the right architecture in 2027 will use all three at different layers. The interesting question is not which protocol wins, but which problem each is the right primitive for.

What x402 actually is

x402 is HTTP 402 reborn as an agent-payment pattern. The HTTP spec has carried a 402 Payment Required status code since the early 1990s, reserved for a future where machines paid each other directly. That future never arrived for human-driven commerce because card networks and account-based banking grew up to fill the gap. For agent-driven commerce, the future arrived in 2024-2025, and 402 became the natural shape.

The mechanics are unglamorous and that is the point. A server returns 402 with a price and a payment URL. A client (an agent's wallet runtime) settles the payment and retries with a receipt. The server validates the receipt and returns 200. Everything else - the chain, the stablecoin, the wallet provider - is implementation detail under the URL.

Three properties make x402 important:

It is transport-shaped, not commerce-shaped. x402 does not know anything about carts, orders, line items, taxes, refunds, or merchants-of-record. It knows that an HTTP request needs payment before it succeeds. That is the entire abstraction. The lack of structure is a feature - any HTTP endpoint can adopt it without rewriting itself as a checkout flow.

It composes with anything. Because x402 is just an HTTP convention, it works with any agent runtime that can speak HTTP, any wallet that can settle a URL, and any chain or rail that the wallet supports. You can build an x402-paid API in an afternoon and any agent in the world can pay you.

It optimises for high-frequency micropayments. A single API call costing $0.005 is the canonical example. Card networks cannot price-discriminate that low because their fixed costs eat the margin. Stablecoin rails on a modern L2 can. The economic argument for x402 is the economic argument for stablecoins; the protocol part is just the connective tissue.

x402 is what happens when you take "pay for this" and reduce it to its smallest possible HTTP form. That is a strength for some workloads and a limitation for others.

What AP2 actually is

AP2 (Agent Payments Protocol) lives one layer up. It does not replace x402; it answers a different question: how does a human authorize an agent to pay on their behalf, with terms that survive after the human has stopped paying attention?

The AP2 primitive is the mandate. A mandate is a structured artifact that says "this agent, acting for this principal, may pay this counterparty for this purpose, up to this amount, expiring at this date, with these constraints." The agent presents the mandate when initiating a payment. The merchant accepts the mandate as authorization. The principal can later audit, revoke, or extend the mandate without touching the underlying payment rails.

Where x402 says "the agent has a wallet, the server returns 402, the wallet pays", AP2 says "the agent has permission from a named human, the merchant verifies that permission, settlement proceeds."

The model has clear strengths. Mandates are accountable: there is a documented chain of authority from human to agent to payment. They are revocable: a principal can cancel a mandate and stop all future payments cold. They are auditable: the mandate plus the resulting payment is a complete record of who authorized what, when, and why. For workloads where regulatory or organizational policy demands an authorization trail - enterprise procurement, healthcare, fiduciary use cases - AP2 is the right primitive.

The model also has trade-offs. Mandate issuance is human-mediated; you cannot, by design, have a fully autonomous agent settle a fresh payment without a pre-existing mandate. The mandate format is more verbose than x402's bare HTTP response; merchants who want to accept AP2 take on more integration work than merchants who only need a 402 plus a settlement URL.

AP2 was not designed to compete with x402 at the per-API-call layer. It was designed to put a name and a scope on the authority behind whatever the agent does next.

What ACP actually is

ACP (Agent Commerce Protocol) is the youngest of the three and the most often confused with the others. It is a commerce-layer protocol - what x402 is for HTTP and AP2 is for authorization, ACP is for the structured back-and-forth between an agent acting as a shopper and a merchant acting as a seller.

The ACP primitive is the cart conversation. An agent describes what its principal wants (in natural language or a structured form). The merchant responds with offers, options, prices, and constraints. The agent negotiates - swaps items, adjusts quantities, asks about delivery, applies discount codes. Eventually they agree on a cart. The cart is then paid for over whatever rail the merchant accepts (often delegating to x402 or AP2 underneath).

This is a different shape from either x402 or AP2. x402 doesn't model carts at all. AP2 models authorization, not negotiation. ACP fills the gap where the agent is shopping rather than just calling an API.

The use cases that need ACP are the ones where the agent is doing what a human consumer would do: ordering groceries, booking travel, comparing insurance quotes, picking a contractor. There the "API call returns 200 if paid" model is way too thin - the agent needs to talk to the merchant, exchange information, and converge on a deal. ACP gives that conversation a structure that both sides can interpret without bespoke integration per merchant.

ACP is less standardized in mid-2026 than the other two; "ACP" is a label applied to several similar emerging protocols rather than one canonical spec. That is normal for protocols at this stage of the curve. The shape is clear; the wire format is still settling.

How they actually compare

The three protocols answer different questions, but a comparison table makes the trade-offs concrete:

Reading this row by row makes the "competition" framing dissolve. The protocols overlap zero rows on "right for" and "wrong for". They are non-rivalrous.

The layering that actually emerges

If you actually build an agent product that has to do all three things, the layering writes itself.

At the bottom is x402. Every paid API call - whether the agent is doing pure research, fetching premium data, calling a paid MCP tool, or paying another agent - settles over x402. The agent's wallet has a spend policy that bounds risk. The merchant returns 402 with a price. Wallet settles. The merchant returns 200. This works for millions of calls per day with no human in the loop, which is the regime where the bulk of agent traffic lives.

In the middle is AP2. The agent's right to operate at all derives from a mandate. The mandate names the human principal, sets the budget envelope, specifies the allowed counterparties, and defines an expiry. The wallet enforces the mandate when handling x402 settlements - if a payment intent exceeds the mandate, the wallet refuses regardless of whether the merchant returned 402. AP2 sits between the human and the agent's payment runtime as the persistent authority layer.

At the top is ACP for use cases that need it. Most agent products do not. Most agents are not shoppers; they are API consumers. But for the subset that genuinely needs to negotiate with merchants - book me a flight, find me a contractor, order me groceries - ACP gives the cart conversation a structure. ACP confirmations then settle over x402 (or sometimes AP2 mandates with merchant-specific overrides) at the bottom.

┌─────────────────────────────────────────────┐
│  ACP   - cart conversation, when needed     │
│         (agent-as-shopper use cases)        │
├─────────────────────────────────────────────┤
│  AP2   - mandate / authorization layer      │
│         (human-issued, persistent scope)    │
├─────────────────────────────────────────────┤
│  x402  - transport / settlement layer       │
│         (pay-per-call, sub-second)          │
├─────────────────────────────────────────────┤
│  Stablecoin rail (USDC on Base etc.)        │
│  Chain settlement                           │
└─────────────────────────────────────────────┘

This is not a hot take; it is a reading of where the production deployments are actually landing. Vendors that try to position one protocol as "the" agent-payment protocol are oversimplifying the stack. Vendors that build for the layering are building for what the next two years actually look like.

The hot questions for 2027

Three questions are still genuinely open.

Will AP2 mandates and ACP carts converge? They share enough DNA - both are structured documents authorizing payment under specific terms - that some teams will try to merge them. The argument against is that mandates are issuer-driven (the principal writes them) and carts are merchant-driven (the seller offers them); collapsing them risks weakening the authorization story. We expect them to stay distinct.

Will x402 grow up the stack? There is pressure from the ecosystem to add more semantics to x402 - line items, refund tokens, escrow primitives, dispute flows. The current "402 + URL + receipt" is intentionally narrow. The pull to enrich it will be strong. The risk is that x402 stops being lightweight and starts duplicating what ACP and AP2 already do.

Will any incumbent rails native-ize one of the three? The clearest case is Stripe adopting x402 as a first-class response for API endpoints, or Visa-affiliated processors implementing AP2 mandate verification. As of mid-2026 the incumbents are observing; serious moves are 12-18 months out. When they happen, the layering above stays intact but the rail mix changes.

What to take from this

The most useful thing a builder can do in 2026 is to stop asking "which protocol should we adopt" and start asking "which layer of the stack are we working on". If you are exposing an API to AI agents, you implement x402 - that is the layer your problem lives in. If you are building an agent platform that holds budgets for enterprise customers, you implement AP2 - because the accountability story is the product. If you are building a consumer-facing agent that shops on behalf of humans, you watch ACP closely and pick the variant your target merchants accept.

These are not competing camps. They are different layers of an agent-commerce stack that is finally getting deep enough to need them all. The future of agent payments is not one protocol; it is the layering of three.