x402 Payments on Arbitrum

If your feed has been buzzing with mentions of x402 and you’re wondering what the excitement is about, you’re not alone. Even token listing sites are adding an x402 token category, but behind the memes and the hype is a genuinely interesting protocol that could change how we think about payments on the web.

Let's break it down.

The missing HTTP status code gets a job

Developers have long known about HTTP 402: Payment Required, a status code that has existed for years but has never had a standardized implementation. The x402 protocol finally gives it a purpose: a standardized way to request, verify, and settle onchain payments directly through the web's native request-response cycle.

Instead of integrating with third-party billing systems or managing API keys, x402 lets a client and server negotiate and complete a payment using standard HTTP headers.

How it works

Imagine you run an API that sells access to up-to-date weather information, or the latest sentiment scores on crypto trends for a few cents per request. Usually, you'd need user accounts, API keys, and a full billing setup.

With x402, that entire flow can happen without any of that.

Here's what that looks like:

1. The client (e.g., the user) requests a resource as usual.
2. The server (e.g., your API) responds with a 402 Payment Required, including a JSON object describing accepted payment options like network, token, price, and pay-to address.
3. The client builds a Payment Payload, signs it with their wallet, and retries the request with an X-PAYMENT header.
4. The server verifies the payment locally or through a facilitator service (e.g., trusted payment relay) using a /verify endpoint.
5. If valid, the server fulfills the request and returns a 200 OK HTTP status with an X-PAYMENT-RESPONSE header containing settlement details.
6. The facilitator then settles the payment onchain.

Below is a simple diagram of the process:

Beyond payments: composability and autonomy

What makes x402 compelling isn't just the flow, but what it enables.

By embedding payment negotiation into HTTP itself, any API, agent or application can become a paid service without relying on a centralized payment processor. It introduces value exchange as a native web primitive, rather than a proprietary product feature.

That means:

• APIs can charge per request without OAuth or dashboards.
• AI agents can pay other agents automatically for services.
• Users can interact with paid resources directly from their browsers with one click.

Together, it creates a more composable, programmable, and open web. It brings us a step closer to a machine-to-machine economy.

Try it yourself

I've published a working demo showing how x402 can handle batch payments for a private AI service, using Google's AP2 protocol for signed payment intents and Arbitrum for final onchain settlement.

You can explore it here:

GitHub - hummusonrails/x402-demo-arbitrum

Contribute to hummusonrails/x402-demo-arbitrum development by creating an account on GitHub.

GitHubhummusonrails

x402 is more than a clever revival of an old HTTP status code. It's a bridge between web protocols and blockchain. By bringing payments into the fabric of the web itself, it opens a new design space for builders who want to make the web programmable, not just readable and writable, but payable.