Skip to main content
This guide walks through monetizing an API endpoint with x402. The server adds a payment handler, the client pays per request, and settlement happens within the HTTP lifecycle.
Concept: For the x402 protocol and why it fits Stable, see x402. For the high-level use case model, see Pay-per-call APIs.
The Semantic facilitator currently operates on mainnet only. The examples in this guide use Stable mainnet. Use small amounts when testing.

What you’ll build

A paid HTTP API where the server responds with 402 Payment Required, the client pays per request, and the facilitator settles USDT0 on-chain within the HTTP lifecycle.

Demo

Overview

Seller (server):
Buyer (client):

Seller: set up paid endpoints

The seller adds x402 middleware to define which routes require payment. When a request arrives without payment, the middleware responds with 402 Payment Required and the payment terms. When a valid payment header is present, the middleware forwards it to a facilitator that verifies the signature and settles the payment on-chain. The seller only configures the price and the receiving address; the facilitator handles verification and settlement.

Pricing

Each route specifies the payment amount in USDT0 base units (6 decimals), the network, and the address to receive funds. For example, "1000" equals $0.001 and "50000" equals $0.05.
The extra fields (name, version, decimals) are used by the buyer’s client for EIP-712 signature construction and must match the on-chain USDT0 contract.

Route configuration

Routes are mapped using the METHOD /path format. Each route specifies the accepted payment scheme, network, price, and the address to receive funds (payTo). The description and mimeType fields help buyers and AI agents discover what the endpoint provides. Routes not listed in the config are not gated and behave like normal Express routes.
x402 also provides middleware for Hono (@x402/hono) and Next.js (@x402/next). The pattern is the same: create a facilitator client, register the EVM scheme, and apply middleware.

Buyer: make paid requests

The buyer accesses paid endpoints without going through manual payment flows. The buyer does not pay gas. The facilitator settles on-chain, and the buyer only pays the exact amount specified in the payment requirements.

Create a wallet and check balance

Connect to x402 and make a paid request

WalletAccountEvm satisfies the signer interface that x402 expects, so it can be registered directly as the signer for the x402 client. Once registered, requests sent through the x402-enabled client handle 402 payment flows automatically.
Under the hood, fetchWithPayment intercepts the 402 response, parses the payment requirements (amount, token, network, recipient), signs an ERC-3009 transferWithAuthorization with the WDK wallet, and retries the request with the PAYMENT-SIGNATURE header.
If you prefer Axios, use @x402/axios with wrapAxiosWithPayment for the same automatic payment handling.

Test the payment flow

Start the server and verify both the paid and free routes.
This test flow runs on Stable mainnet. Each successful paid request settles a real USDT0 payment through the hosted facilitator. Use a dedicated wallet and small amounts only.

1. Confirm the 402 response

The response should be 402 Payment Required with a PAYMENT-REQUIRED header containing the price, asset, and network.

2. Run the client

The client handles the full cycle: receives the 402, signs the authorization, retries with payment, and prints the response.

3. Read the receipt

After a successful paid request, the buyer can read the PAYMENT-SETTLE-RESPONSE header from the server response and parse the settlement receipt.

Test without the live facilitator

Because the Semantic facilitator is mainnet-only, you can’t point your server at a testnet facilitator today. To iterate on server logic, route handlers, and middleware behavior without settling real payments, stub the facilitator client.
Run unit tests against the stub to validate:
  • 402 responses include the correct PAYMENT-REQUIRED payload.
  • Requests with a valid PAYMENT-SIGNATURE header reach the handler.
  • Requests with a missing or malformed header get rejected before the handler runs.
When you’re ready to exercise real settlement, swap back to HTTPFacilitatorClient and run on mainnet with small amounts.
Stubbed settlement only verifies middleware behavior. It doesn’t prove your route handler is idempotent under real network latency or concurrent payments. Always finish with a live mainnet test against small amounts before shipping.

Advanced: lifecycle hooks

x402 provides hooks to intercept and customize payment processing at key points in the flow. For example, the server can run logic before verification (e.g., checking API keys or subscriber status) to bypass payment for authorized requests, and the client can enforce spending limits before signing. For the full hook reference and examples, see x402 Lifecycle Hooks.

x402 concept

Understand the protocol and where it fits.

ERC-3009

Review the settlement standard x402 uses.

Paying with MCP server

Wrap this API as an MCP tool so AI clients can call it through prompts.
Last modified on April 23, 2026