HTTP 402 is a status code. x402 is the payment protocol.
The two names are often collapsed into one idea. Keeping them separate makes payment integrations easier to reason about—and easier to audit.
What HTTP actually standardizes
RFC 9110 registers 402 as “Payment Required,” but leaves the status code reserved for future use. HTTP therefore gives servers and clients a shared signal, not a complete payment system.
The RFC does not choose a currency, chain, settlement provider, proof format, refund policy or confirmation threshold. Any product that implies those decisions come from HTTP alone is skipping the important part.
What x402 adds
The x402 specification turns the reserved status into a usable exchange. A resource server returns a structured payment requirement; the client selects an accepted option, creates a payment payload and retries the request with that payload. The server verifies and settles the payment itself or through a facilitator before returning the resource.
x402 adds:
- A machine-readable description of acceptable payment options.
- Headers for carrying the payment requirement, proof and settlement response.
- A defined client–server sequence that works with ordinary HTTP requests.
- Room for different networks, assets, schemes and facilitators.
What an implementation must still decide
A protocol-compatible response can still be unsafe or operationally weak. Implementers need explicit policies for accepted assets and networks, signature verification, authorization expiry, replay resistance, settlement confirmation, duplicate requests, refunds and failure recovery.
That is why a useful integration guide should show the full requirement and validation path, not only the happy-path 402 response.
GenesisPay design note: GenesisPay uses one URL for browser checkout and agent-readable payment requirements. The payer experience can differ, but the amount and destination remain properties of the same seller-created payment object.
A review checklist
When evaluating an x402 implementation, inspect the boundaries:
- Can the client see exactly what it will sign?
- Does the server bind the proof to the requested resource?
- Are amount, destination, asset, network, validity window and signature all checked?
- Is a failed settlement distinguishable from a paid response?
Those answers reveal more than a protocol badge.
Primary sources
Check the original sources.
- 01RFC 9110: HTTP Semantics, §15.5.3IETF
- 02x402 protocol specification and reference flowx402 Foundation
Last source review: Jul 22, 2026. This is technical education, not financial or legal advice.
