Understanding x402 Fundamentals

HTTP status code 402 — "Payment Required" — has been reserved since 1999 but was never standardized. For over two decades it sat unused, a placeholder for a future that hadn’t arrived yet. x402 is that future: a protocol that finally gives 402 its purpose, turning any API endpoint into a paid resource that machines can access without accounts, API keys, or human intervention.

Why x402 Exists

Traditional API monetization requires developers to sign up, generate API keys, subscribe to a billing plan, and manage OAuth tokens. This works for humans, but it creates friction for AI agents that need to discover and consume APIs autonomously. An agent can’t fill out a registration form or enter credit card details.

x402 removes that friction entirely. Instead of pre-registering, an API consumer simply makes a request. If the endpoint requires payment, it responds with a 402 Payment Required status and a base64-encoded PAYMENT-REQUIRED header listing accepted payment options (amount, currency, network, destination wallet, and the signing scheme). The consumer signs an EIP-3009 transferWithAuthorization message off-chain, then retries the request with the signed authorization in a PAYMENT-SIGNATURE header. A facilitator verifies the signature, the API serves the resource, and the facilitator broadcasts the transfer on-chain on the consumer's behalf. No accounts, no subscriptions, no API keys — and crucially, no on-chain tx infrastructure on the consumer side.

How It Compares

Approach	Setup Required	Machine-Friendly	Settlement
API Keys	Registration + dashboard	Partially (keys can be provisioned)	Monthly invoice
OAuth 2.0	App registration + token refresh	Complex (token lifecycle)	Via billing provider
Stripe / Pay-per-call	Account + payment method	Requires stored credentials	Delayed settlement
x402	None	Fully autonomous	Instant on-chain

The key difference is statelessness. With x402, every request is self-contained: the payment proof travels with the request, and the API verifies it independently against the blockchain. There’s no session, no stored credentials, and no billing relationship to manage.

The Core Flow (x402 v2)

Every x402 v2 interaction follows four steps:

1. Request — The client calls the API endpoint. No authentication headers needed.
2. Challenge — The API returns 402 Payment Required with a base64-encoded PAYMENT-REQUIRED header. Decoded, it's a JSON object with one or more accepts entries — each naming a scheme (exact), a network (e.g. eip155:8453 for Base mainnet), a price, a payTo address, and the asset.
3. Sign and Retry — The client picks an accepts entry and signs an EIP-3009 transferWithAuthorization message from their wallet. No on-chain transaction happens yet. The signed authorization is base64-encoded and sent back in a PAYMENT-SIGNATURE header.
4. Verify, Serve, Settle — The server hands the signature to a facilitator (Coinbase CDP, PayAI, or a self-hosted one) which verifies the authorization off-chain. The server runs the handler and returns the resource with a PAYMENT-RESPONSE header. The facilitator broadcasts the transfer on-chain, paying gas on the consumer's behalf.

This flow works identically whether the client is a human with curl, a backend service, or an autonomous AI agent. Because settlement is delegated to the facilitator, the agent doesn't need its own RPC, nonce management, or gas token — the signed authorization is the entire payment artifact it has to produce.

Supported Chains and Networks

x402 is chain-agnostic by design. Any blockchain that supports verifiable transactions can serve as the payment layer. At node4all, we currently support:

• Base Sepolia (testnet) via sandbox.node4all.com
• Base mainnet (production) via api.node4all.com — real USDC, same interface as testnet
• Solana (coming soon) — will be added as an additional entry in the accepts[] array on the same endpoint

Because the protocol advertises accepted networks via the PAYMENT-REQUIRED header, adding a new chain is purely a server-side configuration change: append an accepts[] entry for the new network identifier and register the corresponding scheme with the facilitator. Clients see the new option automatically and pick whichever chain they hold funds on.

Built for the AI Web

x402 is particularly powerful in the context of AI agents and tool-use workflows. When an LLM agent discovers a useful API through a tool registry, an MCP server, or a discovery index like the Coinbase CDP Bazaar, it can autonomously negotiate payment and access the resource without any human in the loop. The agent receives the 402 challenge, signs an authorization from its wallet, and completes the flow — all within a single tool-call cycle, with the facilitator handling on-chain settlement.

This is the model node4all is built on: APIs that are instantly consumable by both humans and machines, with payment as a native protocol feature rather than an afterthought.

Editor's note — April 2026. An earlier revision of this post described a receipt-based flow (client pays first, submits the tx hash in a custom Payment-Signature header). We've migrated to the x402 v2 authorization flow via Coinbase's CDP facilitator so Node4All endpoints can be consumed by mainstream x402 tooling and indexed in the CDP Bazaar. The language above reflects the v2 behavior.

Ready to try it yourself? A full hands-on walkthrough for Base Sepolia and Base mainnet is coming soon.