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

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

Installation

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

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

# Minimal Fetch client
npm install @x402/core @x402/evm @x402/svm @x402/fetch

# Minimal express Server
npm install @x402/core @x402/evm @x402/svm @x402/express

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

pip install x402

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

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.

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.

This is the beginning of the README. Read the rest at the original. Read the full README ↗