>_ x402.cloudless.sh

A guide · the HTTP-native shift

How x402 works, and why the browser case is different.

The usual framing of x402 is "crypto payments over HTTP." That misses the architectural point. The shift is not that it moves money — it is where the payment negotiation lives. x402 moves it out of a bespoke application-layer checkout workflow and into the resource's own HTTP request/response cycle. This page makes that argument in full, then shows it running on the routes this server already serves.

A reference-implementation guide, not a product pitch — the full architectural story, kept at depth, because the depth is the point. (x402 is not a transport-layer protocol in the OSI sense; it is HTTP-native — the payment is negotiated in the request and response to the resource itself.) For the short two-persona tour, see the front page.

The core thesis

The wallet stops broadcasting. It just signs.

The foundational move is to reduce the client-side wallet's responsibility from a blockchain-broadcasting machine to a pure local signing machine. Once the wallet only signs — and something downstream does the broadcasting — a human browser runtime can behave with the same request-response symmetry as an autonomous machine agent. The person and the program run the identical protocol; the only difference is who holds the signing key.

That symmetry is the whole result. Everything below is why it falls out of moving the payment negotiation out of a per-merchant application workflow and into the resource's own request/response cycle.

The two execution models

Where the payment lives, side by side.

One common Web3 checkout pattern mimics credit-card rails with a heavy, dual-track application loop — though this is an illustration, not a universal rule (gasless, relayed, and server-mediated designs exist too). The real contrast is that each such checkout defines its own workflow, whereas x402 standardizes the payment challenge and response independently of any one merchant's application. The contrast is the argument.

Pre-x402

MetaMask / legacy Web3 checkout

  1. Client-driven intent. The client explicitly triggers an orchestration script — "Connect Wallet", then "Buy Now".
  2. Sideways RPC broadcast. The wallet extension talks sideways to an external RPC node to broadcast a transfer to global blockchain state.
  3. Mempool polling / webhooks. The browser sits on a spinner while the merchant backend polls the chain or waits for an asynchronous webhook to confirm.
  4. Session-cookie fulfillment. Once a block confirms, the merchant database flips the session cookie to "paid" and refreshes the UI to unlock the resource.

With x402

native header flow

  1. 402 challenge. The client attempts a normal data fetch. Interceptor middleware blocks it at the HTTP layer with 402 Payment Required and a machine-readable challenge (network, asset, amount, recipient).
  2. Local delegation / sign. The client hands the payload to a local wallet or secure enclave to sign an EIP-3009 transferWithAuthorization — no private key is exposed to the page runtime.
  3. Retry with the header. The client retries the same request, injecting the signature into the network headers (PAYMENT-SIGNATURE).
  4. Sessionless 200 + body. The server (or its facilitator) verifies off-chain, settles on-chain, and returns 200 OK with the asset in the body and a settlement reference. No cookie is flipped, no checkout UI spun up.

Verification is not settlement, and x402 does not prescribe one settlement mechanism. A facilitator verifying a signature in milliseconds does not mean the payment has reached on-chain finality — verification establishes that a valid authorized payment exists; settlement is a separate event. x402 deliberately leaves the mechanism open: the Coinbase whitepaper describes direct on-chain, L2 / rollup, payment-channel, and batched settlement, and x402 v2 allows several flow orderings (authorization, upfront settlement, escrow). The walkthrough above is one model, not every x402 exchange.

What this reference implementation does: the simplest, most legible path — the facilitator verifies the EIP-3009 transferWithAuthorization off-chain, then settles it directly on-chain (Base) and fronts the gas, returning 200 on soft-confirmation with a PAYMENT-RESPONSE settlement reference. "Sessionless" here means no cookie and no checkout UI — not that the payment is stateless or instant off-chain. The difference from the legacy model is that the browser never left the request-response loop, not that the chain disappeared.

Protocol symmetry · the browser case

A human browser behaves like an agent.

The live network sequence of a person at an x402 paywall is symmetric with the machine-agent flow. The signer owns only the signing block — not the request-response cycle. The GET and the 402/200 travel browser ↔ merchant directly; only steps 3 and 4 — "request signature" and the returned EIP-3009 payload — ever touch the signer.

browser ↔ signer ↔ merchant 
[Browser Runtime]          [Secure Signer / Passkey]          [Merchant Endpoint]
       |                            |                                  |
       | --- 1. GET /resource ------------------------------------->  |
       | <== 2. HTTP 402 Payment Required ==========================  |
       |                            |                                  |
       | --- 3. request signature ->|                                  |
       | <-- 4. EIP-3009 payload ---|                                  |
       |                            |                                  |
       | --- 5. GET /resource  [PAYMENT-SIGNATURE header] --------->  |
       | <== 6. HTTP 200 OK + resource body ========================  |

The security layer

A browser cannot autonomously sign without exposing a key to the JavaScript runtime. A wallet extension — or a Smart Wallet + passkey component — solves this by acting as an isolated signature engine. With a passkey-backed smart-contract wallet the signature is an EIP-1271 (P-256) signature, so the signer can be a passkey, not only a seed-phrase key.

The unified path

The signature engine takes over only the cryptographic signing block. It does not spin up a separate checkout interface, and the broadcast is handled downstream by the facilitator — so the request-response cycle stays unbroken from the client's point of view, whether the client is a script or a person.

Here it is, running

The same loop, two signers, by name.

The argument is abstract; the routes are not. This server runs both ends of the symmetry on real paths, settling real USDC on Base mainnet. The agent path is the loop with a key as the signer; the human path is the identical loop with a browser wallet or passkey as the signer.

agent · key signs

The CLI / @x402/fetch client pays the machine routes. It catches the 402, signs an exact EIP-3009 authorization with its key, and retries with the PAYMENT-SIGNATURE header — the facilitator verifies it and settles on-chain, returning the resource with a settlement reference.

  • GET /v1/lambda-runtimes · $0.001 · Base

    Supported Lambda runtimes as JSON — served from Lambda@Edge, settled through CDP.

  • GET /v1/x402-observers · $0.001 · Base

    The observers dataset as JSON — CDP, Base mainnet.

human · wallet / passkey signs

A person runs the identical loop in the browser. The same @x402/* SDK catches the 402; the wallet or passkey is the signer. No account, no checkout modal — just the signature and the 200.

The advertised price and terms above are read from this server's shared route catalog; the live 402 challenge is always authoritative over anything shown statically.

Where this points

The header is the extension surface.

This is our reading of where the pattern extends, not a settled conclusion. If the HTTP-native logic holds, the interesting consequence is that it need not stay crypto-specific. Non-crypto credentials — a tokenized card cryptogram, a zero-knowledge payment proof — could ride the same PAYMENT-SIGNATURE request header, produced by the operating system's secure enclave (via WebAuthn / passkeys), rather than reintroducing the checkout modals and iframes x402 standardizes away.

Put plainly: the win is the single request-response loop with the signer isolated to one block. Anything that can be reduced to "sign this payload, hand back a credential, inject it into the header" fits that loop — stablecoins today, potentially other payment credentials later. That is a position on an evolving protocol, held against its direction, not a claim that the standard has decided it.