HTTP 402 and x402: how a site charges agents per request, and what a scanner can see

HTTP 402 Payment Required is reserved for future use in RFC 9110, so HTTP itself defines nothing that a 402 should carry. x402, MPP and Cloudflare's Pay Per Crawl each fill the gap with their own headers. The scanner detects x402 only on a narrow path. It reads MPP only in an OpenAPI file and has no check for Pay Per Crawl.

What does HTTP 402 mean?

RFC 9110, section 15.5.3 is one sentence: the 402 status code is reserved for future use. The RFC defines no header, body or retry rule for it. Section 15.1 also leaves 402 off the list of status codes that a cache may reuse without explicit freshness information.

Three protocols have since given the code a meaning, and they do not interoperate. An agent that reads x402 needs separate code to read a Pay Per Crawl 402.

The x402 row comes from the HTTP transport specification and the Linux Foundation announcement. The MPP row comes from the IETF draft and its Datatracker page. The third row comes from Cloudflare's crawl pages and its overview. The comparison of AP2, ACP, UCP, x402 and MPP covers who governs each.

What does a site send in a 402?

An x402 seller answers a request that carries no payment with a 402 and a PAYMENT-REQUIRED header. The header is the base64 of a PaymentRequired object. It holds a protocol version, the resource, and an accepts list of payment options. Each option names a scheme, a network, an amount in atomic token units, an asset and a recipient.

You can read it with curl. The output below is the example from the x402 transport specification, decoded, not a response from a live seller. Point the command at your own priced route.

curl -si https://api.example.com/premium-data \
  | grep -i '^payment-required:' | cut -d' ' -f2 | tr -d '\r' | base64 -d | jq

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

You rarely write that header by hand. The seller quickstart shows Express middleware that prices a route. This is its Base Sepolia branch with the Solana and Algorand branches removed:

import express from "express";
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

const app = express();
const evmAddress = "0xYourEvmAddress";
const facilitatorClient = new HTTPFacilitatorClient({
  url: "https://x402.org/facilitator"
});

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001",
            network: "eip155:84532", // Base Sepolia
            payTo: evmAddress,
          },
        ],
        description: "Weather data",
        mimeType: "application/json",
      },
    },
    new x402ResourceServer(facilitatorClient)
      .register("eip155:84532", new ExactEvmScheme()),
  ),
);

The quickstart says the default facilitator is for testnet development only. Before you take real payments you switch to a production facilitator and a mainnet network.

On Cloudflare you write no response at all. The site owner turns on Pay Per Crawl in the dashboard, sets a price per zone and selects the crawlers to charge. Cloudflare then answers those crawlers with the 402. This is its documented example:

HTTP/2 402
crawler-price: USD 0.01

Four rules hold for most setups.

• Price only the routes you sell. Google treats all 4xx errors except 429 the same, and it does not index a URL that returns one. Its status-code page does not list 402, so this follows from the general rule. A 402 on a page you want in search results removes it.
• Keep the 402 out of shared caches. The MPP draft requires Cache-Control: no-store on every 402. The x402 transport specification says to keep the 402 out of shared caches too.
• Expose the headers to browsers. A cross-origin fetch() cannot read PAYMENT-REQUIRED unless Access-Control-Expose-Headers names it. The preflight must also allow PAYMENT-SIGNATURE.
• Test an unpaid request. Send one with curl. It must return the 402 and the payment terms, because a 402 without terms gives an agent nothing to pay.

What does an agent do with a 402?

The x402 loop has 5 steps.

1. The agent requests the resource with no payment.
2. It reads the 402 and picks an accepts entry that it can pay.
3. It signs a payment authorization and repeats the request with PAYMENT-SIGNATURE.
4. The server verifies the signature itself or posts it to a facilitator's /verify. It serves the resource, then settles through /settle.
5. The agent receives a 200 with PAYMENT-RESPONSE. A payment that fails returns another 402.

That is the default flow. Some schemes settle before the resource runs. The specification puts client-side budget management out of scope, so whether an agent may spend, and how much per request, is the operator's policy. The site only names a price.

A Pay Per Crawl crawler sends one of 2 headers. crawler-exact-price must match the crawler-price it was shown. crawler-max-price is a ceiling, and a page priced above it still answers 402.

The request must be signed with Web Bot Auth, with the payment header listed among the signed components. The Web Bot Auth explainer covers what that signature proves.

Pay per crawl or pay per use?

Pay Per Crawl charges at the fetch. Pay Per Use charges for what the buyer does with the content afterwards. Cloudflare launched Pay Per Crawl in 2025 and published Pay Per Use and the Monetization Gateway on 30 September 2026.

The Pay Per Use post does not describe a 402 for it. The buyer reports each use as a line of JSON, and Cloudflare bills the buyer and pays the publisher monthly. The usage is self-reported. Cloudflare checks that each reported use maps to an enrolled publisher.

The post gives a reason for the design: AI products fetch far more than they use, so a per-fetch price can deter buyers.

The Monetization Gateway post is the x402 route. A seller sets pricing rules in the dashboard. An agent that receives the 402 signs a payment authorization and gets the resource after settlement. Cloudflare's own pages therefore describe 2 dialects of 402: a crawler-price header for Pay Per Crawl and x402 for the gateway.

What do the payment-protocols and mpp-discovery checks detect?

payment-protocols and mpp-discovery are unscored draft checks. They earn no points and never fail. The limits below come from the engine and the published rubric.

• payment-protocols reads UCP and x402. It reports x402 when a path the scan fetched answered 402 with an accepts array whose entries name a scheme. It reads that array in the body or in a base64 Payment-Required header.
• It asks only a shop. The check belongs to the commerce module. The scan asks it only when the homepage shows a commercial signal: Product markup, a priced Offer, an add-to-cart control or a cart link. A site on the publisher or institution site profile is out of scope for it.
• It reads few paths. The scan fetches fixed paths such as /pricing and /docs, sampled product pages, sitemaps, one inner page and a linked policy page. A priced route at /v1/premium-data that nothing links is not requested.
• It does not read an MPP or Pay Per Crawl 402. On 1 November 2026 we ran the check on 2 synthetic answers: a 402 with a WWW-Authenticate: Payment challenge, and a 402 with crawler-price. Neither counted as a payment protocol.
• mpp-discovery reads OpenAPI. It makes no request. It reads x-payment-info on the operations of the OpenAPI JSON that the scan holds: an intent (charge or session), a method and an amount. A YAML description is not parsed.

curl -s https://example.com/openapi.json \
  | jq -c '[.paths | to_entries[] | .key as $p | .value | to_entries[]
      | select(.value | type == "object" and has("x-payment-info"))
      | {operation: ((.key | ascii_upcase) + " " + $p), "x-payment-info": .value["x-payment-info"]}]'

Our 6 stored v0.9 records were measured on 20 and 25 October 2026. In all 6, payment-protocols is out of scope, because no homepage shows a commercial signal. Three records hold an OpenAPI description, and none declares x-payment-info. The OpenAPI checker finds the description a site publishes.

If your homepage answers 402 to the scanner, the whole scan is recorded as not measured. The same holds for 401, 403, 406, 429 and 503. That is a fact about our vantage point, not about your site, and the methodology explains the rule.

Should you answer 402 at all?

Only if you sell something per request. A dataset or an API call fits. A page you want found does not.

Settlement is the cost to weigh. x402 settles in stablecoins, and Cloudflare's gateway uses USDC on Base. Stripe's machine payments page says MPP also takes cards through Shared Payment Tokens, with a 0.50 USD minimum. It says payments settle to your Stripe balance in fiat.

Ask finance what settlement means for your books before you price anything.

The evidence of demand is thin, as the protocol comparison explains. Start with one route, watch what pays, and keep /, /robots.txt and /llms.txt free so that agents can still find what you sell. Scan your domain to see whether payment-protocols or mpp-discovery is asked of it.