x402: How AI Agents Pay for APIs over HTTP

For decades, HTTP status code 402 sat in the specification with a single, almost apologetic note: "Payment Required — reserved for future use." That future arrived in 2026. The x402 protocol, developed by Coinbase and now stewarded by the x402 Foundation, finally gives 402 a job — letting software pay for resources the same way it requests them: over HTTP, in seconds, with no human in the loop.

This matters because the payment rails we built for humans break down completely for autonomous agents. An AI agent cannot fill in a credit card form, click a confirmation email, or negotiate an enterprise contract. It needs a way to discover a price, pay it, and move on — all inside a single request-response cycle. That is exactly what x402 delivers.

Why traditional payments fail for agents

Think about how your code calls a paid API today. Someone signed up for an account, generated an API key, attached a credit card, and configured a monthly subscription. Every one of those steps assumes a human did the onboarding ahead of time.

Now picture an autonomous agent that needs to call forty different APIs it has never seen before to complete a research task. Pre-registering accounts and keys for all of them is impossible. The agent needs just-in-time payments: discover a service, pay a few cents for exactly what it uses, and never create a standing relationship. Subscriptions and API keys are the wrong abstraction for machines.

x402 reframes payment as a property of the HTTP request itself, not a separate billing system bolted on the side.

How the x402 flow works

The mechanism is elegant because it reuses the request-response pattern every developer already knows. Here is the full cycle:

1. The client (an agent or app) requests a protected resource.
2. The server responds with 402 Payment Required and a PAYMENT-REQUIRED header describing accepted networks, tokens, and the price.
3. The client picks a payment requirement and builds a signed payment payload.
4. The client retries the request, this time attaching a PAYMENT-SIGNATURE header.
5. The server verifies the payment, either locally or through a facilitator.
6. On success, the server returns 200 OK with the resource and a PAYMENT-RESPONSE header confirming settlement.

The whole loop takes seconds and settles onchain. There is no login, no stored card, and no prior relationship between buyer and seller. The price is communicated in the very response that rejects the unpaid request, so an agent can read it, decide, and pay autonomously.

The facilitator: blockchain without the headache

The part that scares most backend developers is the phrase "settles onchain." Nobody wants to run RPC nodes, manage gas, or track block confirmations just to charge a tenth of a cent. This is where the facilitator comes in.

A facilitator is a service that handles two jobs through simple endpoints: /verify checks that a payment payload is valid, and /settle submits the transaction to the blockchain and waits for confirmation. Your server just makes two HTTP calls. The Coinbase Developer Platform runs a hosted facilitator that processes payments on Base, Polygon, Arbitrum, World, and Solana, with a free tier of 1,000 transactions per month and a fee of roughly one tenth of a cent per transaction beyond that.

In other words, your application never touches a private key or an RPC endpoint. It speaks plain HTTP to the facilitator, and the facilitator speaks blockchain.

Selling: turning an endpoint into a paywall

On the server side, x402 ships as middleware for the frameworks developers already use — Express, Next.js, Hono for Cloudflare Workers, FastAPI for Python, plus Go and Rust SDKs. Here is the shape of an Express integration:

import { paymentMiddleware } from "@x402/express";
 
app.use(
  paymentMiddleware({
    "GET /weather": {
      accepts: [
        {
          scheme: "exact",
          price: "$0.01",
          network: "eip155:8453", // Base mainnet, CAIP-2 format
          payTo: "0xYourWalletAddress",
        },
      ],
      description: "Real-time weather data",
      mimeType: "application/json",
    },
  }),
);

That single block turns GET /weather into a paywalled endpoint priced at one cent per call. Unpaid requests automatically receive a 402 with the payment terms; paid requests pass through to your normal handler. The scheme: "exact" means a fixed amount per call — the protocol also defines an upto scheme for usage-based pricing.

Buying: letting an agent pay automatically

On the client side, the buyer flow wraps the standard fetch API so payment becomes invisible. The agent makes a normal request; if it hits a 402, the wrapper reads the requirements, signs a payment from a configured wallet, and retries — all without your code branching on payment logic:

import { wrapFetchWithPayment } from "@x402/fetch";
import { createSigner } from "@x402/evm";
 
const signer = createSigner(privateKey);
const fetchWithPay = wrapFetchWithPayment(fetch, signer);
 
// The agent just fetches. Payment happens automatically on 402.
const res = await fetchWithPay("https://api.example.com/weather");
const data = await res.json();

This is the detail that makes x402 feel native to agents: the payment is not a separate workflow. It is a retry. An LLM tool call that hits a paywall can settle it and continue reasoning, the same way a browser silently follows a redirect.

Stablecoins as the settlement layer

x402 settles in stablecoins, with USDC the dominant choice across the ecosystem and EURC also supported. The protocol uses EIP-3009 for gasless authorization on USDC and EURC, meaning the payer signs an authorization rather than broadcasting and paying gas themselves. Any ERC-20 token works through Permit2, and SPL tokens are supported on Solana.

Stablecoins matter here for a practical reason: agents transact in tiny amounts, often fractions of a cent, across borders and at machine speed. Card networks and bank transfers cannot economically clear a one-cent payment, and their settlement times are measured in days. A stablecoin micropayment settles in seconds with effectively zero protocol fee, which is the only model that makes per-request pricing viable.

What this unlocks for the MENA region

For developers and businesses across the MENA region, x402 is more than a crypto curiosity. It sidesteps two long-standing frictions at once. First, cross-border card payments and merchant accounts are notoriously difficult to set up for many MENA developers selling to a global audience; an x402 endpoint accepts payment from anywhere on day one. Second, it lets local SaaS and data providers monetize APIs in granular, pay-per-call units — a Tunisian weather service, an Arabic NLP endpoint, or a Saudi market-data feed can charge agents directly without building a billing department.

As autonomous agents start doing real economic work — booking, researching, purchasing, and calling tools on your behalf — they will need to pay for what they consume. The protocol that lets them do it cleanly is shaping up to be x402, much as MCP became the standard for how agents call tools. If you build APIs, it is worth a serious look now, while the standard is young and the integration is a few lines of middleware.

Getting started

The fastest path is to install the SDK for your framework and point it at the Coinbase-hosted facilitator so you skip blockchain infrastructure entirely. Stand up a single paid endpoint, test it with the wrapped-fetch client against a testnet like Base Sepolia, then graduate to mainnet once the flow works end to end. The free tier covers your first thousand transactions, which is more than enough to validate whether per-call pricing fits your product.

The web finally has a native answer to "Payment Required." For the agent economy, that answer is x402.

Building APIs or AI agents and want to monetize or consume them with machine-native payments? Noqta helps teams across Tunisia and the MENA region design AI-ready architectures and modern payment integrations.