x402 Documentation

A payments protocol for the internet. Built on HTTP.

6,038 stars TypeScript TypeScript 1 file · ~3,156 tokens
RAW Doc

File: README.md

x402

x402 is an open standard for internet native payments. It aims to support all networks (both crypto & fiat) and forms of value (stablecoins, tokens, fiat).

typescript
app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [...],                 // As many networks / schemes as you want to support
      },
    },
  ),
);
// That's it! See examples/ for full details

Installation

Typescript

See all the packages available in the Typescript SDK, including chain implementations of x402, code examples and integration guides.

shell
# All available reference sdks
npm install @x402/core \
  @x402/evm @x402/svm @x402/avm @x402/aptos @x402/stellar @x402/tvm @x402/hedera @x402/keeta \
  @x402/axios @x402/fastify @x402/fetch @x402/express @x402/hono @x402/next @x402/paywall @x402/extensions @x402/mcp
shell
# Minimal Fetch client
npm install @x402/core @x402/evm @x402/svm @x402/fetch
shell
# Minimal express Server
npm install @x402/core @x402/evm @x402/svm @x402/express

Python

See the python/x402 folder for code examples and integration guides.

shell
pip install x402

Go

See the go/ folder for code examples and integration guides.

shell
go get github.com/x402-foundation/x402/go/v2

Principles

  • Open standard: x402 is an open standard, freely accessible and usable by anyone. It will never force reliance on a single party.
  • HTTP / Transport Native: x402 is meant to seamlessly complement existing data transportation. It should whenever possible not mandate additional requests outside the scope of a typical client / server flow.
  • Network, token, and currency agnostic: we welcome contributions that add support for new networks (both crypto and fiat), signing standards, or schemes, so long as they meet our acceptance criteria laid out in CONTRIBUTING.md. x402 may extend support to fiat based networks, but will never deprioritize onchain payments in favor of fiat payments.
  • Backwards Compatible: x402 will not deprecate support for any existing networks unless such removal is deemed necessary for the security of the standard. Whenever possible, x402 will aim for backwards compatibility for non-major version changes.
  • Trust minimizing: all payment schemes must not allow for the facilitator or resource server to move funds, other than in accordance with client intentions
  • Easy to use: It is the goal of the x402 community to improve ease of use relative to other forms of payment on the Internet. This means abstracting as many details of crypto as possible away from the client and resource server, and into the facilitator. This means the client/server should not need to think about gas, rpc, etc.

Ecosystem

Community: join the x402 Slack to ask questions, discuss ideas, and share what you're building.

Curated third-party SDKs, extensions, and facilitators are listed in the Developer Tools docs. For broader discovery of x402 services and integrations, see community-maintained directories such as x402scan.com, Agentic.Market, Pay.sh, app.ampersend.ai/discover, and x402-list.com.

Roadmap: see ROADMAP.md

Documentation: see docs/ for the published documentation source (Mintlify). Payment schemes include exact, upto, and batch-settlement; specifications live under specs/schemes/.

Choosing a Production Path

For testnet development and quickstarts, the public x402 facilitator is the easiest way to get started. For production mainnet routes, decide on your facilitator model explicitly:

  • use a production facilitator provider that supports your target network,
  • run your own facilitator,
  • or self-facilitate inside your resource server.

Do not assume the public x402.org facilitator is the default production path for mainnet EVM routes. See the Facilitator docs, Facilitators directory, and Networks & Token Support for operator guidance.

Terms:

  • resource: Something on the internet. This could be a webpage, file server, RPC service, API, any resource on the internet that accepts HTTP / HTTPS requests.
  • client: An entity wanting to pay for a resource.
  • facilitator: A server that facilitates verification and execution of payments for one or many networks.
  • resource server: An HTTP server that provides an API or other resource for a client.

Technical Goals:

  • Permissionless and secure for clients, servers, and facilitators
  • Minimal friction to adopt for both client and resource servers
  • Minimal integration for the resource server and client (1 line for the server, 1 function for the client)
  • Ability to trade off speed of response for guarantee of payment
  • Extensible to different payment flows and networks

Specification

See specs/ for full documentation of the x402 standard/

Typical x402 flow

x402 payments typically adhere to the following flow, but servers have a lot of flexibility. See advanced folders in examples/.

The following outlines the flow of a payment using the x402 protocol. Note that steps (1) and (2) are optional if the client already knows the payment details accepted for a resource.

  1. Client makes an HTTP request to a resource server.

  2. Resource server responds with a 402 Payment Required status and a PaymentRequired b64 object return as a PAYMENT-REQUIRED header.

  3. Client selects one of the PaymentRequirements returned by the server response and creates a PaymentPayload based on the scheme & network of the PaymentRequirements they have selected.

  4. Client sends the HTTP request with the PAYMENT-SIGNATURE header containing the PaymentPayload to the resource server.

  5. Resource server verifies the PaymentPayload is valid either via local verification or by POSTing the PaymentPayload and PaymentRequirements to the /verify endpoint of a facilitator.

  6. Facilitator performs verification of the object based on the scheme and network of the PaymentPayload and returns a Verification Response.

  7. If the Verification Response is valid, the resource server performs the work to fulfill the request. If the Verification Response is invalid, the resource server returns a 402 Payment Required status and a Payment Required Response JSON object in the response body.

  8. Resource server either settles the payment by interacting with a blockchain directly, or by POSTing the Payment Payload and Payment PaymentRequirements to the /settle endpoint of a facilitator server.

  9. Facilitator server submits the payment to the blockchain based on the scheme and network of the Payment Payload.

  10. Facilitator server waits for the payment to be confirmed on the blockchain.

  11. Facilitator server returns a Payment Execution Response to the resource server.

  12. Resource server returns a 200 OK response to the Client with the resource they requested as the body of the HTTP response, and a PAYMENT-RESPONSE header containing the Settlement Response as Base64 encoded JSON if the payment was executed successfully.

Schemes

A scheme is a logical way of moving money.

Blockchains allow for a large number of flexible ways to move money. To help facilitate an expanding number of payment use cases, the x402 protocol is extensible to different ways of settling payments via its scheme field.

Each payment scheme may have different operational functionality depending on what actions are necessary to fulfill the payment.
For example, exact transfers a specific amount (for example, pay $1 to read an article). upto authorizes up to a maximum per request; the seller settles the actual usage, up to that cap. batch-settlement (EVM) uses escrow and off-chain vouchers so sellers can redeem many small charges onchain in batches instead of settling every HTTP request separately.

See specs/schemes for full scheme specifications; specs/schemes/exact/scheme_exact_evm.md describes exact payments on EVM chains.

Schemes vs Networks

Because a scheme is a logical way of moving money, the way a scheme is implemented can be different for different blockchains. (ex: the way you need to implement exact on Ethereum is very different from the way you need to implement exact on Solana).

Clients and facilitators must explicitly support different (scheme, network) pairs in order to be able to create proper payloads and verify / settle payments.

File: docs/introduction.md

title: "Welcome to x402" This guide will help you understand x402, the open payment standard, and help you get started building or integrating services with x402.

x402 is the open payment standard that enables services to charge for access to their APIs and content directly over HTTP. It is built around the HTTP 402 Payment Required status code and allows clients to programmatically pay for resources without accounts, sessions, or credential management.

With x402, any web service can require payment before serving a response, using crypto-native payments for speed, privacy, and efficiency.

Want to contribute to our docs? The documentation source in this repository is open to PRs. Our only ask is that you keep these docs as a neutral resource, with no branded content other than linking out to other resources where appropriate.

Note about the docs: These docs are the credibly neutral source of truth for x402, as x402 is a completely open standard under the Apache-2.0 license.

Why Use x402?

x402 offers:

  • No fees and minimal friction x402 as a standard has 0 fees built in.
  • Native support for machine-to-machine payments, enabling seamless use by AI agents
  • Built-in micropayment support, making it easy to monetize usage-based services (including batch settlement on EVM for high-volume, batched onchain redemption)

Who is x402 for?

  • Sellers: Service providers who want to monetize their APIs or content. x402 enables direct, programmatic payments from clients with minimal setup.
  • Buyers: Human developers and AI agents seeking to access paid services without accounts or manual payment flows.

Both sellers and buyers interact directly through HTTP requests, with payment handled transparently through the protocol.

What Can You Build?

x402 enables a range of use cases, including:

  • API services paid per request
  • AI agents that autonomously pay for API access
  • Paywalls for digital content
  • Microservices and tooling monetized via microtransactions
  • Proxy services that aggregate and resell API capabilities

How Does It Work?

At a high level, the flow is simple:

  1. A buyer requests a resource from a server.
  2. If payment is required, the server responds with 402 Payment Required, including payment instructions.
  3. The buyer prepares and submits a payment payload.
  4. The server verifies and settles the payment independently, or by leveraging an x402 facilitator's /verify and /settle endpoints.
  5. If payment is valid, the server provides the requested resource.

For more detail, see:

The goal is to make programmatic commerce accessible, permissionless, and developer-friendly.

Get Started

Ready to build? Start here:

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →