HTTP 402 Payment Required: charging agents per request

RFC 9110 still describes HTTP 402 Payment Required as "reserved for future use", and MDN still calls it nonstandard, with "no standard use convention". Both are behind the deployments. Cloudflare already returns 402 to AI crawlers in production, the x402 protocol specifies exactly what that response carries, and Cloudflare's Monetization Gateway is being built to put a price on any API or MCP tool behind it.

The facts, as of 1 October 2026:

• The standard has not changed. RFC 9110 §15.5.3 is one sentence long and says nothing about prices.
• x402 v2 is the spec doing the work. It carries the price in a PAYMENT-REQUIRED response header and the proof in a PAYMENT-SIGNATURE request header.
• One Cloudflare product ships 402 today: pay per crawl, which is in closed beta, with Cloudflare as Merchant of Record.
• The general-purpose one does not. The Monetization Gateway, announced on 1 July 2026, is a waitlist. Every capability in that post is written in the future tense.

What is HTTP 402 Payment Required in the specification?

Almost nothing. RFC 9110 §15.5.3 reads, in full: "The 402 (Payment Required) status code is reserved for future use." There is no registered header for the price, no field for the asset, no mechanism at all.

MDN is blunter, and its wording matters if you are deciding whether to build on this: the code "was created to enable digital cash or (micro) payment systems", but "no standard use convention exists and different systems use it in different contexts". MDN also notes that no browser supports a 402 and it surfaces as a generic 4xx error.

That is the real constraint. 402 is a shared slot, not a shared protocol. Anything interoperable has to be layered on top, which is why the useful reading is the protocol specs, not the RFC.

An HTTP 402 Payment Required example from the x402 transport spec

x402 is an open protocol for paying over HTTP, now governed by the x402 Foundation. Its v2 specification defines three roles: a resource server that wants paying, a client that wants the resource, and a facilitator that verifies and settles the payment so the server does not have to touch a blockchain.

Here is the 402 from the spec's own HTTP transport document, with the base64 payload truncated for the page:

HTTP/1.1 402 Payment Required
Content-Type: application/json
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6MiwiZXJyb3IiOiJQQVlNRU5ULVNJR05B... (base64)

{}

The header decodes to a PaymentRequired object. The spec's example:

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "resource": {
    "url": "https://api.example.com/premium-data",
    "description": "Access to premium market data",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "amount": "10000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USDC", "version": "2" }
    }
  ]
}

Three details are worth pausing on. accepts is an array, so a server can advertise several networks and schemes and let the client choose. amount is a string in atomic token units, so "10000" means nothing until you apply the asset's decimals. And network is a CAIP-2 identifier — eip155:84532 is a specific chain, which is the part your finance team will ask about.

The client then repeats the same request with a base64 PAYMENT-SIGNATURE header carrying the signed authorization, and a success looks like this:

HTTP/1.1 200 OK
Content-Type: application/json
PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLCJ0cmFuc2FjdGlvbiI6... (base64)

That header decodes to {"success": true, "transaction": "0x1234...", "network": "eip155:84532", "payer": "0x857b06519E91e3A54538791bDbb0E22373e36b66"}. A failure comes back as another 402 with "errorReason": "insufficient_funds". Note that the spec puts everything in headers and treats the body as your own concern — the same discipline that makes stateless MCP servers easier to run behind a proxy.

Header	Direction	Carries
PAYMENT-REQUIRED	Server to client	Price, asset, network, payee
PAYMENT-SIGNATURE	Client to server	Signed payment authorization
PAYMENT-RESPONSE	Server to client	Settlement result and transaction

The 402 that is already live: pay per crawl

If you want to see 402 in production rather than in a spec, look at Cloudflare's pay per crawl. It is a much simpler scheme than x402 — a price per zone, in fiat, with Cloudflare acting as Merchant of Record — and it is in closed beta, not general availability. The documented exchange for an AI crawler is three headers:

HTTP/2 402
date: Fri, 06 Jun 2025 08:42:38 GMT
crawler-price: USD 0.01

The crawler retries with crawler-exact-price: USD 0.01, or with crawler-max-price if it wants a standing ceiling across every site, and gets back crawler-charged: USD 0.01 on a 200. Get the price wrong and you get crawler-error: InvalidCrawlerExactPrice.

Two rules in that documentation are easy to miss and both will cost you a day. The payment header must be included in the components signed by Web Bot Auth, in the signature-input header, or the payment is not processed. And if you block a crawler in the WAF or Bot Management, those rulesets override the charge rule, so the crawler never gets the chance to pay.

What an API owner has to build

The Monetization Gateway's pitch is that metering, the payment exchange and settlement move off your origin, and that you write a rule instead of a billing system. Cloudflare's stated plan is expression-based rules managed through the dashboard, the API or Terraform, with examples including a flat charge per verb on a route such as /api/premium/*, variable pricing up to a ceiling for work whose cost varies, and intercepting a 401 from your origin and returning a 402 instead. The handshake is meant to happen at the edge, across Cloudflare's 330+ cities.

What does not move off your origin is the harder half:

1. Defining the billable unit. A request, a token, a megabyte, or a resolved outcome. This is a product decision, and it is the one that takes the longest to agree internally.
2. Idempotency. If a paid request is retried, you need the second call to return the first result rather than charge twice. The same retry and idempotency patterns you already need for webhooks apply, with money attached.
3. Deciding what a failure costs. A 500 after you have taken payment is now a refund, not a log line.
4. Your own ledger. You still need a record you can reconcile against, because the settlement record lives on a chain and your accountant does not read chains.

In the API integration work we do, taking the money has never been the hard part of usage-based billing. Agreeing what one unit is, and making that unit survive a retry, is where the weeks go.

Chargebacks, identity and metering disputes

Start with the strongest version of the case for this design. Cloudflare's own framing is that stablecoins "can settle in under a second for a fraction of a cent with zero chargebacks", and for a seller taking sub-cent payments from strangers, no chargebacks is not a footnote — it is the only reason the economics work at all. Card rails cannot price a $0.001 call because the dispute machinery costs more than the call.

The cost of that is real too. Irreversible settlement means a buyer who was overcharged has no rail-level recourse, so every dispute arrives at your support queue instead, and a refund is a fresh transaction you choose to make. If you are going to charge per request, publish what you refund before anyone asks.

Identity is the second gap. In x402 the payment is the credential, so by default you learn a wallet address and nothing else. Cloudflare's stated plan is that you will be able to require agents to authenticate with Web Bot Auth as well. Even then, Cloudflare's own Verified bots documentation distinguishes Direct operators from Intermediary ones, where "the operator and the end user are not the same party", and describes transitive trust as an open problem it is experimenting with by forwarding end-user information in an RFC 7239 Forwarded header. Knowing who paid is not the same as knowing who benefits — the same distinction that makes identity-based gateway routing more useful than handing out keys.

Metering disputes change shape rather than disappearing. When the request is the invoice there is no monthly statement to argue over, but there is also no line item to point at three weeks later. Keep your own request log with the settlement reference, or you will be reconstructing a disagreement from someone else's dashboard.

Finally, the question that decides whether any of this is actionable: can your buyers pay this way? At launch the Monetization Gateway will require stablecoins — Cloudflare names Open USD and USDC — and sellers redeem to fiat. For clients in India and the UAE, that is a treasury and compliance question before it is an engineering one, and it is worth confirming with your own adviser rather than your architect.

Is this worth doing this quarter?

x402 is not the only protocol in this space, and it is not trying to be the whole stack. Google's Agent Payments Protocol sits a layer up, at authorization, with signed mandates that prove a human approved a purchase, and its documentation lists x402 among its sample payment flows. The two are complements: AP2 answers "was this allowed", x402 answers "was this paid".

The honest position for most teams is narrower than the announcements. Joining a waitlist costs nothing. Rebuilding billing around 402 before you can name one buyer that will pay in stablecoins is premature, and the same applies to letting shopping agents into a checkout. What is worth doing now is the part that holds whichever rail wins: name your billable unit, make it idempotent, and keep a ledger you can reconcile. Do that and turning on a 402 later is a configuration change rather than a project.