HTTP 402 Payment Required: Meaning, Uses, and x402 (2026)

HTTP 402 means Payment Required. The HTTP standard reserves the code for future use. It does not define a universal payment method or tell your client how to pay. An API that returns 402 needs its own payment contract.

Correction, September 8, 2026: I mixed x402 V1 and V2 details in the original walkthrough. I also described an old payment error too broadly. This revision separates the current protocol from my original build account.

What does HTTP 402 tell you?

RFC 9110, section 15.5.3 reserves 402 for future use. A 402 response alone does not establish that a server uses x402. Read that API's documentation and response before deciding what to do next.

I removed the unsupported claim that the code had been reserved since 1991. The earlier description of RFC 7231 as calling it experimental was also wrong. Its section 6.5.2 says it is reserved for future use.

How x402 V2 uses the status code

x402 defines a payment exchange around HTTP 402. In the documented V2 flow:

1. The client requests a paid resource.
2. The server returns 402 with payment requirements in the PAYMENT-REQUIRED header.
3. The client selects a supported option and creates the payment payload for that scheme.
4. The client retries with that payload in PAYMENT-SIGNATURE.
5. The server verifies the payment, performs the work and settles payment. It returns the result with settlement information in PAYMENT-RESPONSE.

The official facilitator guide describes these headers and the verification and settlement steps. A facilitator can handle payment verification and blockchain settlement for the server. It is optional. A server can implement those responsibilities itself.

That still requires payment infrastructure. Returning a 402 by itself does not collect money.

Check the version before copying a request

These differences come from the official V1 to V2 migration guide. The examples in the network row refer to Base Sepolia, a test network. My original walkthrough combined a V1 payment header with V2 network notation. Do not copy that combination into a new integration.

What remains of my original build account

The April 27 post described a paid memory API using Coinbase CDP on Base. It reported a three-second round trip and an invalid_payload error that stopped after a price change.

Those were claims in the original account. I have not reproduced the timing or established a current facilitator minimum for this correction. They are not a benchmark, a protocol guarantee or a recommended price. I have removed the advice to raise the amount first when that error appears.

What I would check before retrying

Start by recording the HTTP status, error body, client package version and protocol version. Then compare the request with the documentation for the exact server and facilitator you use.

Check the selected network, asset, amount units and payment scheme. Keep the failure response with the request record. A generic error is not enough evidence to change the price or authorize another payment.

For an agent integration, I would also set a spending limit before testing repeated calls. A successful payment request tells you that one request worked. It does not tell you that a repeated job will stay within budget.

Inspect AgentGuard's runtime limits before adding paid calls to an agent loop.