HTTP has carried the status code 402 – Payment Required since the early days of the web. The idea was simple: servers could charge per request. The reason it never worked wasn’t conceptual, it was infrastructural. Payments were slow, expensive, and required accounts, sessions, and chargeback-heavy intermediaries.
x402 revisits this idea with modern primitives: stablecoins, fast settlement, and programmable authorization. The result is a web-native payment protocol that lets services charge for access directly in the HTTP request–response loop.
How x402 Works (At a Protocol Level)
x402 introduces a small extension to standard HTTP flows:
- A client (human or agent) requests a resource.
- The server responds with HTTP 402 plus payment metadata:
- token
- amount
- chain
- destination address
- The client signs a permit-style authorization using transferWithAuthorization (EIP-3009).
- A facilitator verifies the authorization off-chain and settles it on-chain.
- Once settlement is confirmed, the server returns the requested resource.
From the client’s perspective, this feels like a normal API call.
From the server’s perspective, payment is verified before access is granted.
No accounts, no sessions, no API keys.
Why This Is Interesting for Developers
Micropayments become viable
The protocol itself has no fees. Costs are limited to gas, which on modern L2s makes sub-cent pricing realistic.
Stateless by design
Each request carries its own payment authorization. There’s no need to manage balances, subscriptions, or identity layers.
Web-native integration
x402 works with plain HTTP. Any backend capable of returning a 402 response can adopt it without special SDKs.
Machine-friendly payments
This model fits agents far better than traditional payment systems. An agent can pay per request, per inference, or per compute unit without human involvement.
Agent-to-Agent Payments
The real unlock isn’t just charging humans, it’s enabling autonomous economic activity.
An agent can:
- pay an API for data,
- pay another agent to process it,
- pay a compute service to run a job,
- all conditionally and programmatically.
These are high-volume, low-value, composable payments that traditional rails can’t support efficiently, but blockchains can.
Where Trust Comes In: x402 + ERC-8004 + ROFL
x402 handles payment, not trust.
For agent ecosystems, that matters. When an agent pays a service, it needs to know:
- what code is actually running,
- who controls the keys,
- whether execution can be verified.
That’s where complementary primitives fit:
- ERC-8004 provides on-chain registries for agent identity, reputation, and validation.
- ROFL enables verifiable execution inside TEEs, with enclave-generated keys and cryptographic attestations.
Together:
- x402 moves money,
- ERC-8004 enables discovery and coordination,
- ROFL provides execution integrity and confidentiality.
Even facilitators themselves can run inside ROFL, making the payment layer auditable and resistant to censorship.
Practical Examples
Early demos already exist:
- pay-per-inference services where users pay cents per request,
- multi-model AI pipelines with cross-validation,
- document processing APIs with verifiable execution.
In each case, pricing tracks actual usage instead of subscriptions.
Closing Thoughts
x402 doesn’t try to reinvent payments. It makes them composable with the web itself.
By aligning HTTP semantics with on-chain settlement, it opens the door to pricing models and agent workflows that were previously impractical. Combined with verifiable execution and standardized agent discovery, it points toward a more granular, automated, and open internet economy.
For developers building APIs, agent systems, or compute-heavy services, x402 is worth paying attention to.
Resources:
More...