AETHELFORGESTAGING
Try Axis

PROTOCOL · x402

x402 — HTTP-Native Payments

The long-dormant HTTP 402 "Payment Required" status code, finally given a job. Inline micropayments that settle at the speed of a response.

THE ANSWER

What is x402?

x402 is an open specification from Coinbase that revives the HTTP 402 "Payment Required" status code for inline, per-request micropayments. When a server returns 402, the client attaches a payment proof and retries the request. The settlement happens in milliseconds, making it practical to charge per API call or per token served.

word_count=52 · type=definitional

The dormant status code

HTTP 402 — Payment Required— was reserved in the original HTTP spec and then left sitting unused for three decades. Everyone knew it was there. Nobody used it because there was no human-acceptable micropayment rail fast enough to justify a retry-with-proof protocol. You don't want a modal asking the user to pay a penny to see a weather API response.

Agents change the math. An agent making a million API calls a day does not care about a per-call modal. It cares about latency, predictability, and an accountable ledger. x402 gives all three.

How x402 works

  1. The client makes a normal HTTP request.
  2. The server responds with 402 Payment Required and a header describing the price (currency, amount, supported settlement methods).
  3. The client produces a payment proof — a signed authorization against a stablecoin channel, a card pre-authorization, or any other settlement method the server accepts.
  4. The client retries the request with the proof attached. The server verifies, settles, and returns the content.

The whole round trip adds latency on the order of the settlement method: milliseconds for stablecoin channels, a few hundred for card pre-auths. Fast enough that an agent can treat it as a normal variable in its request path.

Aethelforge uses x402 for

  • Per-request API billing.Forge SDK endpoints that have per-call costs bill directly through x402 against the agent's standing intent.
  • Catalog lookups. Some merchants charge a fractional cent for detailed catalog or inventory queries to keep scraper load sane. x402 settles that inline.
  • Low-value purchases. Items under a few dollars where the overhead of a full ACP negotiation is more expensive than the item itself.

The composition

x402 is a settlement rail, not a commerce protocol. It moves money quickly; it does not negotiate terms, record disputes, or handle delegation scope. For negotiation, Aethelforge layers ACP on top. For delegation scope enforcement, AP2. For the underlying tool-calling wire, MCP. x402 is the last mile of the four-protocol stack — the thing that actually moves the money.

The boring reason x402 works is that it does one thing only. That's also the reason it composes well with everything else.

FAQ

x402 · questions

  1. 01Who stewards x402?

    Coinbase. x402 was introduced in 2025 as an open specification reviving the HTTP 402 status code for per-request payments, with an initial reference implementation supporting USDC on Base.

  2. 02Why micropayments now?

    Because agent traffic makes them make sense. A human is not going to pay a penny to hit an API; an agent hitting it a million times a day will, if it shaves a millisecond off the request. x402 finally has a consumer who values per-call billing.

  3. 03Is x402 cryptocurrency?

    The reference implementation runs on USDC, which is a stablecoin. But the spec is agnostic — any rail that can settle a small payment inline with an HTTP response can implement x402, including card-based rails with sufficient authorization caching.

  4. 04What does Aethelforge add?

    Aethelforge wraps x402 with intent validation, scope enforcement, and audit logging. An agent cannot just spray x402 requests at your API and drain its budget; the gate checks against the signed intent and stops when the scope is exhausted.