HTTP 402 • REVIVED

How x402
Works

Internet-native payments over HTTP.
Perfect for AI agents, APIs, and content.

What is x402?

x402 is an open standard that brings native payments to the web by activating the long-dormant HTTP 402 Payment Required status code.

Instead of accounts, logins, or complex APIs, clients (browsers, AI agents, scripts) can automatically pay for resources using stablecoins or other on-chain assets in a single request-response cycle.

EVM + Solana + more

Stablecoins (USDC)

AI Agent Friendly

Key Innovation

01 Payment requirements sent in HTTP headers
02 Cryptographic proof of payment in request header
03 Optional payment facilitators handle verification & settlement
04 Works with existing HTTP clients (with small middleware)

Key Participants

Client

Browser • AI Agent • App

Initiates requests and handles payment logic (signing with wallet, retrying with payment header).

Resource Server

API • Website • Service

Protects resources. Returns 402 when payment is needed. Verifies and settles payments before delivering content.

Facilitator

Optional but recommended

Handles payment verification and on-chain settlement. Reduces complexity for resource servers.

Sequence Diagram

sequenceDiagram
    autonumber
    participant C as Client
    participant RS as Resource Server
    participant F as Facilitator

    C->>RS: GET /premium-resource
    activate RS
    RS-->>C: 402 Payment Required
PAYMENT-REQUIRED: base64(...)
    deactivate RS

    Note over C: Parses requirements
Signs PaymentPayload with wallet

    C->>RS: GET /premium-resource
PAYMENT-SIGNATURE: base64(PaymentPayload)
    activate RS

    RS->>F: POST /verify
    activate F
    F-->>RS: VerificationResponse (valid)
    deactivate F

    RS->>F: POST /settle
    activate F
    F->>Blockchain: Submit transaction
    Blockchain-->>F: Confirmed
    F-->>RS: SettlementResponse
    deactivate F

    RS-->>C: 200 OK
PAYMENT-RESPONSE: base64(...)
[Resource Content]
    deactivate RS

High-level flow. Facilitator is optional — servers can verify/settle directly.

Detailed Step-by-Step Flow

1

Client requests resource

Standard HTTP GET request to a protected endpoint.

2

Server responds with 402 + Payment Requirements

Returns 402 Payment Required + PAYMENT-REQUIRED header containing base64-encoded JSON with accepted payment options (scheme, network, amount, payTo address, etc.).

3

Client creates & signs Payment Payload

Selects a supported payment option and creates a cryptographically signed payload (using wallet signature or permit).

4

Client retries request with payment

Sends the original request again, now including the PAYMENT-SIGNATURE header with the signed payload.

5

Server verifies the payment

Either locally or by calling the Facilitator’s /verify endpoint.

6

Server settles the payment

Calls Facilitator’s /settle endpoint (or settles directly on-chain).

7

Server delivers the resource

Returns 200 OK with the requested content + optional PAYMENT-RESPONSE header containing settlement receipt.

Interactive Simulation

Client

Resource Server + Facilitator

Server log will appear here...

Step 2 Response Header

(Waiting for request...)

Step 4 Request Header

(Waiting for payment...)

Final Response

(Waiting for completion...)