Skip to main content

​
Why x402?

There are fundamental issues with payments on the internet:
  • Traditional payments: high card fees (2–3%), minimum charge limits, high integration barrier, not suitable for programmatic calls
  • Web3 payments: fragmented, non-unified interfaces, complex details like gas/RPC to handle, high development and UX costs
We need an open, internet-native payment protocol suitable for both humans and AI.

​
What is x402?

x402 is an open on-chain micropayment protocol based on the HTTP 402 status code. It standardizes the full flow of “request → pay → retry → get resource”:
  1. Client sends an HTTP request
  2. Server returns 402 Payment Required with payment requirements (PaymentRequirements)
  3. Client generates a payment proof (signature or transaction) per the requirements and retries with the X-PAYMENT header
  4. Server verifies and settles the payment
  5. Server returns 200 OK with the resource, and includes on-chain transaction info in the X-PAYMENT-RESPONSE header

​
Core principles

  1. Open standard: never requires dependency on a single party; anyone can implement it
  2. HTTP-native: seamlessly integrates into existing HTTP flows; no extra roundtrips
  3. Chain/Token agnostic: supports any chains and token standards via scheme extensions
  4. Minimal trust: all payment options must ensure funds only move per the buyer’s intent
  5. Easy to use: abstracts crypto complexity (gas, RPC, etc.); client/server in 1–2 lines of code

​
Core concepts

  • Resource: any content on the internet — webpages, files, APIs, RPC services, etc.
  • Client: the entity who wants to pay for a resource (users, AI agents, etc.)
  • Resource Server: an HTTP server that provides resources (merchant)
  • Facilitator Server: a third-party service that helps verify and execute on-chain payments (optional)
  • Scheme: a logical way to transfer value (e.g., exact for exact payments, upto for usage-based)