x402: HTTP 402 Is Finally a Real Payment Protocol

On July 14, 2026 the Linux Foundation announced the operational launch of the x402 Foundation, with 40 member organizations including Visa, Mastercard, Stripe, Shopify, Google, AWS, Cloudflare and Coinbase. The short version: 402 Payment Required — the status code reserved "for future use" since the early web — now has an open specification and vendor-neutral governance instead of being one company's initiative.

The problem: an agent can call, but it cannot pay

API monetization today is built for humans. Sign up, confirm an email, open a dashboard, add a card, copy an API key, receive an invoice at month end. That flow makes sense for a developer at a keyboard. It falls apart the moment an autonomous agent needs one dataset, once, in the middle of a task.

The practical consequence is that every paid integration becomes advance work: a contract, a key, a quota, an environment variable. As agentic systems spread, that friction — not model capability — is the real ceiling. There has never been a standard way for a payment to travel inside the request itself.

What changed: a three-header handshake

x402 puts payment inside the HTTP cycle rather than beside it. The V2 specification defines three headers, each base64-encoded:

• PAYMENT-REQUIRED — server to client, carrying the payment requirements.
• PAYMENT-SIGNATURE — client to server, carrying proof of payment authorization.
• PAYMENT-RESPONSE — server to client, carrying the settlement outcome.

On the wire the exchange stays readable:

GET /v1/reports/q3 HTTP/1.1
Host: api.example.com

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64>

Decoded, that header is an explicit description of what the server will accept:

{
  "x402Version": 2,
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "10000",
      "asset": "0x<usdc-contract>",
      "payTo": "0x<treasury-address>"
    }
  ]
}

The client then retries the same request carrying its authorization:

GET /v1/reports/q3 HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: <base64>

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64>

Server-side, wiring it up is middleware that declares what each route accepts:

import express from "express";
import { paymentMiddleware } from "@x402/express";

const app = express();

app.use(
  paymentMiddleware({
    "GET /v1/reports/:id": {
      accepts: [
        { scheme: "exact", network: "eip155:8453", payTo: process.env.TREASURY },
      ],
      description: "Quarterly report",
    },
  })
);

Three pricing shapes

The specification defines three schemes. exact is a fixed, advertised price the buyer authorizes upfront. upto is usage-based billing where the buyer authorizes a ceiling and is charged for actual consumption — the right shape for bandwidth, compute time or token volume. batch-settlement accumulates repeated micro-authorizations into a reusable channel and redeems them together, which is what makes high-frequency access economically viable.

Verification and settlement are handled by a facilitator: a service that verifies and settles payments on behalf of the resource server. Several production facilitators exist across EVM and Solana networks, teams can self-host, and a no-setup testnet facilitator is available for experimentation.

What changed between v1 and v2

Older repositories will show different names. The v1→v2 migration renamed the headers from X-PAYMENT to PAYMENT-SIGNATURE and from X-PAYMENT-RESPONSE to PAYMENT-RESPONSE. Network identifiers moved to the CAIP-2 standard: base became eip155:8453, base-sepolia became eip155:84532. Packages were split into a more modular layout — @x402/core, @x402/express, @x402/evm, @x402/svm — with schemes registered explicitly rather than a wallet being passed straight into an interceptor.

Real-world caveats

The standard is promising, but adoption is an engineering and a finance decision:

• On-chain settlement costs money. That is precisely why batch-settlement exists; settling every single call individually is not economical for a busy API.
• Choosing a facilitator is a trust decision. Services differ in supported networks and in compliance screening, and they sit inside your money path.
• Payment is not identity. A 402 answers "was this paid for?", never "who are you?". Authentication and authorization stay a separate layer — see the recent MCP specification.
• The spec is young. v1 to v2 already broke header and package names. Isolate the integration behind a thin, swappable layer.
• There is no card-network equivalent for refunds and disputes. That needs a written policy, not an assumption.

Takeaway

x402 does not give agents a new capability so much as remove an old blocker: a request can now carry its own price. Teams that stand up one priced route behind a 402 today — even on a testnet — build the operational experience before the question becomes urgent.

Primary source: the Linux Foundation announcement of the x402 Foundation's operational launch and the official documentation at docs.x402.org.