> ## Documentation Index
> Fetch the complete documentation index at: https://docs.x402x.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# What is X402

> Standardizing internet-native payments with 402 Payment Required

## 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

<img src="https://mintcdn.com/wtf-db2dc414/gvVhFZKzzT5KuRcD/images/flow.png?fit=max&auto=format&n=gvVhFZKzzT5KuRcD&q=85&s=60309b4b72a74d649f1d919000ec1a15" alt="" width="2909" height="1725" data-path="images/flow.png" />

## 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)