Skip to main content
x402 is a payment protocol built on the HTTP 402 Payment Required status code. It enables programmatic payments between any HTTP client and server without accounts, sessions, or custom authentication.

​
The payment flow

1. Client sends a normal HTTP request
2. Server responds with 402 + payment requirements
3. Client signs a payment locally
4. Client retries the request with X-PAYMENT header
5. Server verifies payment via a facilitator
6. Server returns the requested resource

​
Step by step

1. Initial request The client makes a standard HTTP request to a protected resource. 
GET /api/data HTTP/1.1
Host: api.example.com
2. Payment required The server responds with 402 Payment Required and includes payment requirements in the response body: 
{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "exact",
      "network": "solana-devnet",
      "asset": "USDC",
      "maxAmountRequired": "10000",
      "payTo": "7xKX...",
      "resource": "https://api.example.com/api/data",
      "description": "API access",
      "mimeType": "application/json",
      "maxTimeoutSeconds": 60
    }
  ]
}
3. Payment construction The client inspects the requirements, selects a compatible payment method, and constructs a payment payload. The payload is signed locally using the client’s wallet. 4. Retry with payment The client retries the original request with the payment proof attached: 
GET /api/data HTTP/1.1
Host: api.example.com
X-PAYMENT: eyJ4NDAyVmVyc2lvbiI6MSwi...
The X-PAYMENT header contains a base64-encoded JSON payload with the payment proof. 5. Verification and settlement The server forwards the payment to a facilitator, which verifies the signature and settles the transaction on-chain. The facilitator returns a confirmation. 6. Resource delivery Once the payment is confirmed, the server returns the requested resource with a 200 OK response.
If a payment settles but the client loses the connection before receiving the full response, retrying the request would trigger a second charge. To avoid this, design your server to grant time-limited access upon payment rather than delivering the resource in a single response. This lets the client retry or resume without paying again.

​
Payment requirements

A payment requirement describes what the server accepts. Key fields:
FieldDescription
schemePayment method (e.g., "exact")
networkBlockchain network identifier on the wire (e.g., "solana-devnet", "base-sepolia"). The @faremeter/info helpers accept shorter cluster names like "devnet" and expand them automatically.
assetToken to pay with (e.g., "USDC")
maxAmountRequiredMaximum payment amount (in smallest unit)
payToRecipient address
resourceThe URL being paid for
maxTimeoutSecondsHow long the payment proof is valid
A server can accept multiple payment methods simultaneously. The client chooses one it can fulfill.

​
Payment payload

The X-PAYMENT header contains a base64-encoded JSON object:
FieldDescription
x402VersionProtocol version (1 or 2)
schemeWhich scheme was used
networkWhich network was used
payloadScheme-specific proof (signatures, transaction data)

​
Protocol versions

x402 version 1 sends the payment proof in the X-PAYMENT header as a base64-encoded JSON payload. Version 2 uses the PAYMENT-SIGNATURE header instead, aligning with the evolving x402 specification. Faremeter supports both versions. See the x402 v2 types API reference for the v2 payload format.

​
Further reading