Skip to main content
This guide walks you through integrating with x402 to enable payments for your API or service. By the end, your API will be able to charge buyers and AI agents for access.
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), Polygon, Arbitrum, World, and Solana networks.
Need help? Join the x402 Discord for the latest updates.

Facilitator URLs

EnvironmentFacilitator URLNetworksAuth
CDP (recommended)https://api.cdp.coinbase.com/platform/v2/x402Base, Base Sepolia, Polygon, Arbitrum, World, World Sepolia, Solana, Solana DevnetCDP API keys required
x402.org (testnet only)https://x402.org/facilitatorBase Sepolia, Solana DevnetNone
We recommend the CDP facilitator for both testnet and mainnet—it supports all networks with a generous free tier. The examples below use the x402.org facilitator for a signup-free quick start; see Running on Mainnet to switch to CDP.

Prerequisites

Before you begin, ensure you have:
  • A crypto wallet to receive funds (any EVM-compatible wallet, e.g., CDP Wallet)
  • A Coinbase Developer Platform (CDP) account and API keys (recommended for production; examples below use x402.org for signup-free testing)
  • Node.js and npm, Go, or Python and pip installed
  • An existing API or server
  • For testnet: Base Sepolia ETH for gas and testnet USDC for payments. Get funds from the CDP Faucet
We have pre-configured examples available in our repo for both Node.js and Go. We also have 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 and EVM mechanism packages:
npm install @x402/express @x402/evm @x402/core

2. Add Payment Middleware

Integrate the payment middleware into your application. You will need to provide:
  • The Facilitator URL or facilitator client. We recommend CDP for both testnet and mainnet (see Running on Mainnet). The examples below use https://x402.org/facilitator for a quick test without signup.
  • The routes you want to protect
  • Your receiving wallet address
The examples below show testnet configuration. When you’re ready to accept real payments, refer to Running on Mainnet for the simple changes needed.
Full example in the repo here.
import express from "express";
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

const app = express();

// Your receiving wallet address
const payTo = "0xYourAddress";

// Create facilitator client (testnet)
const facilitatorClient = new HTTPFacilitatorClient({
  url: "https://x402.org/facilitator"
});

// Create resource server and register EVM scheme
const server = new x402ResourceServer(facilitatorClient)
  .register("eip155:84532", new ExactEvmScheme());

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001", // USDC amount in dollars
            network: "eip155:84532", // Base Sepolia (CAIP-2 format)
            payTo,
          },
        ],
        description: "Get current weather data for any location",
        mimeType: "application/json",
      },
    },
    server,
  ),
);

// Implement your route
app.get("/weather", (req, res) => {
  res.send({
    report: {
      weather: "sunny",
      temperature: 70,
    },
  });
});

app.listen(4021, () => {
  console.log(`Server listening at http://localhost:4021`);
});
Ready to accept real payments? See Running on Mainnet for production setup.
Price format: Use a dollar-prefixed string (e.g. "$0.001" or "$0.10"). Omitting the $ can cause validation errors.
Route Configuration Interface: Route configs are defined as a map where each key is a route pattern string (e.g., "GET /weather", "GET /articles/:slug", "GET /api/*") and the value is a RouteConfig object:
interface RouteConfig {
  accepts: Array<{
    scheme: string; // Payment scheme (e.g., "exact")
    price: string; // Price in dollars (e.g., "$0.01") — must include $ prefix
    network: string; // Network in CAIP-2 format (e.g., "eip155:84532")
    payTo: string; // Your wallet address
  }>;
  description?: string; // Description of the resource
  mimeType?: string; // MIME type of the response
  extensions?: object; // Optional extensions (e.g., Bazaar, gas sponsorship)
}
When a request is made to these routes without payment, your server will respond with the HTTP 402 Payment Required code and payment instructions.

Dynamic Route Patterns

Route keys support dynamic path segments, letting a single route configuration match multiple URLs. Three pattern styles are supported:
PatternExample keyMatches
:param (Express-style)"GET /articles/:slug"/articles/hello-world, /articles/123
[param] (Next.js-style)"GET /articles/[slug]"/articles/hello-world, /articles/123
* (wildcard)"GET /api/*"/api/anything, /api/a/b/c
If no HTTP method is specified in the key, the route matches all HTTP methods.
app.use(
  paymentMiddleware(
    {
      // Named param — matches /articles/any-slug
      "GET /articles/:slug": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.01",
            network: "eip155:84532",
            payTo,
          },
        ],
        description: "Read a premium article by slug",
        mimeType: "application/json",
      },
      // Wildcard — matches /api/v1/anything, /api/v2/other, etc.
      "GET /api/*": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001",
            network: "eip155:84532",
            payTo,
          },
        ],
        description: "Premium API access",
        mimeType: "application/json",
      },
    },
    server,
  ),
);

app.get("/articles/:slug", (req, res) => {
  res.json({ slug: req.params.slug, content: "Article content..." });
});

app.get("/api/*", (req, res) => {
  res.json({ message: "API response" });
});
When using dynamic routes with Bazaar discovery, prefer named params (:param or [param]) over wildcards (*). Named params generate cleaner discovery metadata with descriptive parameter names; wildcards auto-generate names like var1, var2.

Payment Schemes: Exact vs Upto

x402 supports two payment schemes that control how charges are calculated: exact (default) — The client pays the exact advertised price. This is the simplest scheme and works across all networks (EVM, SVM) and all SDKs (TypeScript, Go, Python). 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.). Currently available on EVM networks only, in TypeScript and Go SDKs. 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
import express from "express";
import { paymentMiddleware, setSettlementOverrides, x402ResourceServer } from "@x402/express";
import { UptoEvmScheme } from "@x402/evm/upto/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

const app = express();
const payTo = "0xYourAddress";

const facilitatorClient = new HTTPFacilitatorClient({
  url: "https://x402.org/facilitator"
});

const maxPrice = "$0.10"; // Maximum the client authorizes (10 cents)

app.use(
  paymentMiddleware(
    {
      "GET /api/generate": {
        accepts: [
          {
            scheme: "upto",
            price: maxPrice,
            network: "eip155:84532", // Base Sepolia
            payTo,
          },
        ],
        description: "AI text generation — billed by token usage",
        mimeType: "application/json",
      },
    },
    new x402ResourceServer(facilitatorClient)
      .register("eip155:84532", new UptoEvmScheme()),
  ),
);

app.get("/api/generate", (req, res) => {
  const maxAmountAtomic = 100000; // 10 cents in 6-decimal USDC atomic units
  const actualUsage = Math.floor(Math.random() * (maxAmountAtomic + 1));

  // Settle only the actual usage — the client is never charged more than this
  setSettlementOverrides(res, { amount: String(actualUsage) });

  res.json({
    result: "Here is your generated text...",
    usage: {
      authorizedMaxAtomic: String(maxAmountAtomic),
      actualChargedAtomic: String(actualUsage),
    },
  });
});

app.listen(4021, () => {
  console.log("Server listening at http://localhost:4021");
});
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 the authorized 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").
The resolved amount must always be <= the authorized maximum. If the amount is "0", no on-chain transaction occurs and the client is not charged.
The upto scheme is currently available on EVM networks only (TypeScript and Go SDKs). Python does not yet support upto.

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 the CDP facilitator, your endpoints can be listed in the x402 Bazaar, our discovery layer that helps buyers and AI agents find services. To enable discovery and improve visibility:
Include descriptive metadata in your route configuration:
  • description: Clear explanation of what your endpoint does
  • mimeType: MIME type of your response format
  • extensions.bazaar: Enable Bazaar discovery
This metadata helps:
  • AI agents automatically understand how to use your API
  • Developers quickly find services that meet their needs
  • Improve your ranking in discovery results
How Bazaar indexes your resource: When the CDP Bazaar crawls your endpoint for discovery, it sends a request with no body. Your server must respond with a 402 Payment Required status to that empty request, confirming the resource is x402-enabled. If your server returns any other status code (e.g. 400 Bad Request), the resource will not be indexed and will not appear in Bazaar search results. Other discovery layers or bazaars may use a different indexing mechanism.
Example with Bazaar extension:
{
  "GET /weather": {
    accepts: [
      {
        scheme: "exact",
        price: "$0.001",
        network: "eip155:8453",
        payTo: "0xYourAddress",
      },
    ],
    description: "Get real-time weather data including temperature, conditions, and humidity",
    mimeType: "application/json",
    extensions: {
      bazaar: {
        discoverable: true,
        category: "weather",
        tags: ["forecast", "real-time"],
      },
    },
  },
}
Learn more about the discovery layer in the x402 Bazaar documentation.

5. Accept Any ERC-20 Token with Permit2 (Optional, EVM)

By default, the quickstart above uses USDC via EIP-3009 (Transfer With Authorization), which requires no on-chain approval from buyers. To accept any ERC-20 token, you can use Permit2 as the transfer method.
The official TypeScript, Go, and Python SDKs all have built-in support for both EIP-3009 and Permit2.

How It Works

  • Set extra.assetTransferMethod: "permit2" in your route’s price configuration
  • Optionally declare a gas sponsorship extension so the facilitator can sponsor the buyer’s one-time Permit2 approval on-chain (no gas cost to the buyer)
  • Without gas sponsorship, buyers must manually approve the Permit2 contract before their first payment

Gas Sponsorship Extensions

Gas sponsorship extensions require facilitator support. Before declaring a gas sponsorship extension on your endpoint, verify that your facilitator supports it by calling its /supported endpoint and inspecting the extensions property in the response. Look for:
  • eip2612-gas-sponsoring — indicates EIP-2612 gas sponsorship support
  • erc20-approval-gas-sponsoring — indicates ERC-20 approval gas sponsorship support
If these fields are not present, the facilitator does not support the corresponding extension and you should not declare it on your routes. There are two gas sponsorship extensions, depending on the token:
ExtensionWhen to UseFacilitator Extension KeyImport
declareEip2612GasSponsoringExtensionToken implements EIP-2612 permit() (e.g., USDC)eip2612-gas-sponsoring@x402/extensions
declareErc20ApprovalGasSponsoringExtensionGeneric ERC-20 token without EIP-2612erc20-approval-gas-sponsoring@x402/extensions

Example: Permit2 with EIP-2612 Gas Sponsoring (e.g., USDC)

For tokens that support EIP-2612 (like USDC), declare the EIP-2612 gas sponsoring extension. The facilitator uses a signed permit() to approve Permit2 on the buyer’s behalf — fully gasless for the buyer.
npm install @x402/extensions
import { declareEip2612GasSponsoringExtension } from "@x402/extensions";
import { declareDiscoveryExtension } from "@x402/extensions/bazaar";

// In your route configuration:
"GET /protected": {
  accepts: {
    payTo: "0xYourAddress",
    scheme: "exact",
    network: "eip155:84532",
    price: "$0.001",
    extra: { assetTransferMethod: "permit2" },
  },
  extensions: {
    ...declareDiscoveryExtension({ /* ... */ }),
    ...declareEip2612GasSponsoringExtension(),
  },
},

Example: Permit2 with ERC-20 Gas Sponsoring (Generic Token)

For tokens that do not support EIP-2612, use the ERC-20 approval gas sponsoring extension. The facilitator broadcasts a pre-signed approve() transaction on the buyer’s behalf.
import { declareErc20ApprovalGasSponsoringExtension } from "@x402/extensions";

// In your route configuration:
"GET /protected": {
  accepts: {
    payTo: "0xYourAddress",
    scheme: "exact",
    network: "eip155:84532",
    price: {
      amount: "1000",
      asset: "0xYourTokenAddress",
      extra: {
        assetTransferMethod: "permit2",
      },
    },
  },
  extensions: {
    ...declareErc20ApprovalGasSponsoringExtension(),
  },
},
For full details on EVM transfer methods and gas sponsorship, see Network Support.

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

Running on Mainnet

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

Setting Up CDP Facilitator for Production

CDP’s facilitator provides enterprise-grade payment processing with compliance features:

1. Set up CDP API Keys

To use the mainnet facilitator, you’ll need a Coinbase Developer Platform account:
  1. Sign up at cdp.coinbase.com
  2. Create a new project
  3. Generate API credentials
  4. Set the following environment variables:
    CDP_API_KEY_ID=your-api-key-id
    CDP_API_KEY_SECRET=your-api-key-secret
    

2. Update Your Code

Replace the testnet configuration with mainnet settings:
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";
import { facilitator } from "@coinbase/x402";

const facilitatorClient = new HTTPFacilitatorClient(facilitator);

const server = new x402ResourceServer(facilitatorClient)
  .register("eip155:8453", new ExactEvmScheme()); // Base mainnet

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001",
            network: "eip155:8453", // Base mainnet (CAIP-2)
            payTo: "0xYourAddress",
          },
        ],
        description: "Weather data",
        mimeType: "application/json",
      },
    },
    server,
  ),
);

3. Update Your Wallet

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

4. 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
Mainnet transactions involve real money. Always test thoroughly on testnet first and start with small amounts on mainnet.

Using Different Networks

CDP facilitator supports multiple networks. Simply change the network parameter using CAIP-2 format:
// Base mainnet
{
  scheme: "exact",
  price: "$0.001",
  network: "eip155:8453", // Base mainnet
  payTo: "0xYourAddress",
}

// Base Sepolia testnet
{
  scheme: "exact",
  price: "$0.001",
  network: "eip155:84532", // Base Sepolia
  payTo: "0xYourAddress",
}
Need support for additional networks like Avalanche? You can run your own facilitator or contact CDP support to request new network additions.

Network Identifiers (CAIP-2)

x402 v2 uses CAIP-2 format for network identifiers:
NetworkCAIP-2 Identifier
Base Mainneteip155:8453
Base Sepoliaeip155:84532
Polygoneip155:137
Arbitrumeip155:42161
Worldeip155:480
Solana Mainnetsolana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
Solana Devnetsolana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1
See Network Support for the full list.

Next Steps

For questions or support, join our Discord.

Summary

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