Skip to main content
Note: This quickstart begins with testnet configuration for safe testing. When you’re ready for production, see Running on Mainnet for the simple changes needed to accept real payments on Base (EVM) and Solana networks.

Prerequisites

Before you begin, ensure you have:
  • A crypto wallet to receive funds (any EVM or SVM compatible wallet)
  • Node.js and npm, Go, or Python and pip installed
  • An existing API or server
Note
There are pre-configured examples available in the x402 repo for both Node.js and Go. There is also an advanced example that shows how to use the x402 SDKs to build a more complex payment flow.

1. Install Dependencies

Install the x402 Express middleware package.

2. Add Payment Middleware

Integrate the payment middleware into your application. You will need to provide:
  • The Facilitator URL or facilitator client. For testing, use https://x402.org/facilitator which works on Base Sepolia and Solana devnet.
  • The routes you want to protect.
  • Your receiving wallet address.
Full example in the repo here.
Route Configuration Interface:
When a request is made to these routes without payment, your server will respond with the HTTP 402 Payment Required code and payment instructions.

Payment Schemes: Exact, Upto, and Batch Settlement

x402 supports several payment schemes that control how charges are calculated: exact (default) — The client pays the exact advertised price. This is the simplest scheme and works on all supported networks — see Networks & Token Support. TypeScript supports every network; Go and Python support a subset — see SDK Features. Best for fixed-price endpoints where the cost is known upfront. upto — The client authorizes a maximum amount, but the server settles only what was actually used. This enables usage-based billing where the final charge depends on work performed (LLM token count, compute time, bytes served, etc.). Available on EVM networks (Permit2) in TypeScript, Go, and Python SDKs, and on Solana (SVM) in TypeScript and Go SDKs. batch-settlement — For high-frequency or repeated micropayment traffic, the buyer funds a channel once, signs off-chain vouchers per request, and the seller settles onchain in batches (not every request). Each call still advertises a per-request maximum (price); you can charge actual usage up to that cap using the same setSettlementOverrides pattern as upto. See Batch settlement and the Payment Schemes overview. The examples in step 2 above all use the exact scheme. To use upto instead, there are two key differences:
  1. Set scheme: "upto" in your route config, where price becomes the maximum the client authorizes
  2. Call setSettlementOverrides in your handler to specify the actual amount to charge
Full example in the repo here.
The setSettlementOverrides amount supports three formats:
  • Raw atomic units — e.g., "1000" settles exactly 1,000 atomic units of the token (for USDC with 6 decimals, "1000" = $0.001)
  • Percentage of authorized maximum — e.g., "50%" settles 50% of PaymentRequirements.amount. Supports up to two decimal places (e.g., "33.33%"). The result is floored to the nearest atomic unit.
  • Dollar price — e.g., "$0.05" converts a USD-denominated price to atomic units. This format works when you configured your route with $-prefixed pricing (e.g., price: "$0.10"). Token decimals are determined from the registered scheme. The result is rounded to the nearest atomic unit.
The resolved amount must always be <= the authorized maximum. If the amount is "0", no onchain transaction occurs and the client is not charged.

3. Test Your Integration

To verify:
  1. Make a request to your endpoint (e.g., curl http://localhost:4021/weather).
  2. The server responds with a 402 Payment Required, including payment instructions in the PAYMENT-REQUIRED header.
  3. Complete the payment using a compatible client, wallet, or automated agent. This typically involves signing a payment payload, which is handled by the client SDK detailed in the Quickstart for Buyers.
  4. Retry the request, this time including the PAYMENT-SIGNATURE header containing the cryptographic proof of payment.
  5. The server verifies the payment via the facilitator and, if valid, returns your actual API response (e.g., { "data": "Your paid API response." }).
When using a facilitator that supports the Bazaar extension, your endpoints can be listed in the x402 Bazaar, the discovery layer that helps buyers and AI agents find services. For HTTP endpoints, add the discovery extension to your route config:
For MCP tools, pass the discovery extension in your payment wrapper config:
Learn more about the discovery layer in the Bazaar documentation.

5. Error Handling

  • If you run into trouble, check out the examples in the repo for more context and full code.
  • Run npm install or go mod tidy to install dependencies

6. Enable Signed Offers & Receipts

The Signed Offers & Receipts extension adds cryptographic proof-of-interaction to your payment flows. When enabled, your server automatically signs offers on every 402 response (committing to payment terms) and a receipt on every 200 response (confirming service delivery). This creates portable, verifiable artifacts that clients and third parties can use for auditing, dispute resolution, and increasing the reputation of your service. See the full setup guide for installation, configuration, and signer authorization options.

Running on Mainnet

Once you’ve tested your integration on testnet, you’re ready to accept real payments on mainnet.

1. Update the Facilitator URL

For mainnet, use a production facilitator. See Facilitators for selected options. Example using one facilitator:
Do not reuse https://x402.org/facilitator for mainnet routes. The default x402.org facilitator is intended for testnet development only.

2. Update Your Network Identifier

Change from testnet to mainnet network identifiers:

3. Register Multiple Schemes (Multi-Network)

For multi-network support, register both EVM and SVM schemes:

4. Update Your Wallet

Make sure your receiving wallet address is a real mainnet address where you want to receive USDC payments.

5. Test with Real Payments

Before going live:
  1. Test with small amounts first
  2. Verify payments are arriving in your wallet
  3. Monitor the facilitator for any issues
Warning: Mainnet transactions involve real money. Always test thoroughly on testnet first and start with small amounts on mainnet.

Network Identifiers (CAIP-2)

x402 v2 uses CAIP-2 format for network identifiers: See Network Support for the full list.

Next Steps

For questions or support, join our Slack.

Summary

This quickstart covered:
  • Installing the x402 SDK and relevant middleware
  • Adding payment middleware to your API and configuring it
  • Choosing between exact (fixed-price), upto (usage-based per settlement), and batch-settlement (EVM micropayments with batched redemption) payment schemes
  • Testing your integration
  • Deploying to mainnet with CAIP-2 network identifiers
Your API is now ready to accept crypto payments through x402.