x402 revives HTTP 402 as a pay-per-call billing protocol for AI agents

A technical walkthrough published on dev.to lays out x402, a protocol that repurposes HTTP's long-dormant 402 Payment Required status code as a machine-to-machine billing layer. The target audience is developers building autonomous agents who want a lightweight, on-chain way to charge per call, and the article backs the concept with runnable server and client code.

The problem it targets

According to the dev.to article, autonomous agents repeatedly call LLM endpoints, data feeds and tool wrappers, often dozens or hundreds of times per task. Conventional access models fit poorly: an agent cannot enter credit card details, manage a stack of SaaS subscriptions, or safely hold the long-lived, highly privileged API keys that today's billing assumes. Per the author, what makes HTTP 402 practical now is the arrival of low-latency Layer 2 networks and stablecoins, which make tiny programmatic settlements viable. The 402 code has sat reserved in the HTTP specification for decades without a standard use.

The handshake

The protocol keeps payment inside the ordinary request/response cycle. The client sends a normal request; the server replies 402 with payment metadata; the client pays and retries; the server verifies and serves the payload. An agent can therefore treat a paid call like any other GET or POST: catch the 402, attach payment, retry.

Notably, the article appeared on dev.to in two versions on the same morning, and the drafts describe settlement differently. One draft has the server issue a challenge containing a price, an ERC-20 token address, a chain ID and a server-generated nonce. The client signs a keccak-256 hash binding those values plus a hash of the request body, and returns the signature and signer address in an X402-Payment header; the server verifies the signature off-chain and consumes the nonce to block replays. The second draft uses an actual on-chain transfer instead: the 402 response names a destination wallet, a USDC amount and the target network (Base, chain ID 8453), the agent submits a signed transfer and retries with the transaction hash in an X-402-Payment-Proof header, and the server checks the receipt against the chain before responding.

The code

Both drafts ship implementations. The signature variant is Node.js with Express and ethers.js: middleware returns 402 with an X402-Challenge header when payment is missing or invalid, recomputes the request-body hash, recovers the signer from the signature, and only then runs the handler. The example prices a trivial endpoint at 0.01 USDC. The on-chain variant is TypeScript with Hono on the server and viem on the agent side, using USDC on Base for what the author cites as sub-cent fees and instant settlement. Its verification function reads the transaction receipt, parses ERC-20 Transfer events to confirm the merchant address was paid the right amount, and rejects proofs older than 100 blocks to stop double-spending with stale transactions. The agent side is a fetch wrapper that intercepts the 402, builds the payment and retries automatically.

Trade-offs the author flags

The demos make simplifying choices. The Express version keeps nonces in a per-IP in-memory Map, which the author says will not scale; production code should use a shared store such as Redis or DynamoDB with expiry, or a smart-contract nonce like the ERC-4337 entry point. The signature demo also skips the on-chain balance check, assuming a pre-funded escrow or paymaster, where a real deployment would query the ERC-20 balance. The claimed properties of the design are stateless requests, payment and execution in a single atomic call, compatibility with any EVM chain supporting ERC-20 tokens, and only a few bytes of overhead per request.

Why it matters

If agents are to consume arbitrary services without a human in the loop, payment has to travel with the request. x402's pitch is that HTTP reserved a status code for exactly this decades ago, and cheap Layer 2 settlement finally makes it usable: any agent holding a wallet can call any priced endpoint, and any provider can bill per call without accounts, metering or key management. The discrepancy between the two drafts, off-chain signature proofs versus on-chain transaction receipts, suggests the verification details are still settling, but the pattern itself is concrete, and the article's code gives developers a starting point on both sides of the handshake.