What if your AI agent could pay for its own API calls?
Not through a credit card you set up. Not through an API key you provisioned. Not through a subscription you manage. The agent itself—autonomously, instantly, without asking permission—pays a fraction of a cent and gets the data it needs.
This isn’t hypothetical. It’s happening right now, thousands of times a day, through a protocol called x402.
The AI agent revolution has a payment problem. Agents can browse the web, write code, analyze data, and make decisions—but the moment they need to buy something, the entire system breaks down. Traditional payment infrastructure was built for humans: credit cards require identity verification, API keys require account setup, and subscriptions require upfront commitments. None of these work when the “customer” is a Python script running on a server somewhere.
x402 solves this by doing something deceptively simple: it takes an HTTP status code that’s been reserved since 1997 and finally puts it to work. The result is a payment protocol that’s as natural to the web as 200 OK or 404 Not Found.
Here at RobotDomainSearch, we built one of the first production APIs with native x402 support. In this post, we’ll break down exactly how the protocol works, why it matters, and what it means for the future of the internet.
What is x402?
The name comes from HTTP 402 “Payment Required”—a status code defined in the original HTTP specification in 1997. For nearly three decades, it sat unused, marked as “reserved for future use.” The web’s creators knew that someday, machines would need a native way to pay for resources. That someday is now.
x402 is an open protocol that attaches cryptocurrency payments to standard HTTP requests. It’s maintained on GitHub by Coinbase as an open standard, freely accessible and usable by anyone. It’s network-agnostic, transport-native, and designed so that a single line of middleware on the server and a single function call on the client is all you need.
Here’s how it works in five steps:
The x402 Payment Flow
1. Agent makes a request
An AI agent sends a standard HTTP request to an x402-enabled endpoint—just like any normal API call.
GET /v1/valuation/example.com HTTP/1.1
Host: api.robotdomainsearch.com
2. Server responds with 402 Payment Required
Instead of returning data, the server responds with a 402 status code and a PAYMENT-REQUIRED header containing Base64-encoded payment details: how much to pay, where to pay, and which networks/tokens are accepted.
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJwcmljZSI6IjAuMDIiLCJjdXJyZW5jeSI6IlVTREMi...
The decoded payment requirements look like this:
{
"x402Version": 2,
"resource": {
"url": "/v1/valuation/example.com",
"description": "Domain valuation (quick or full tier)"
},
"accepts": [
{
"scheme": "exact",
"network": "eip155:8453",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"amount": "20000",
"payTo": "0x...",
"maxTimeoutSeconds": 60,
"extra": {
"name": "USD Coin",
"version": "2"
}
}
]
}
The network value eip155:8453 is the EIP-155 chain identifier for Base mainnet. The amount is in USDC’s smallest unit (6 decimals), so 20000 = $0.02. The asset is the USDC contract address on Base. The extra field carries token metadata used during payment signing.
3. Agent creates and signs a payment
The agent’s wallet creates a USDC transfer for the specified amount on Base, signs it, and encodes it as a payment payload.
4. Agent retries the request with payment proof
The agent sends the original request again, this time including a PAYMENT-SIGNATURE header with the signed payment payload.
GET /v1/valuation/example.com HTTP/1.1
Host: api.robotdomainsearch.com
PAYMENT-SIGNATURE: eyJ0eXBlIjoiZXhhY3QiLCJuZXR3b3JrIjoiYmFzZSI...
5. Server verifies, settles, and responds
The server (or a facilitator service) verifies the payment is valid, settles it onchain, and returns the requested data with a 200 OK along with a PAYMENT-RESPONSE header containing the settlement receipt.
HTTP/1.1 200 OK
PAYMENT-RESPONSE: eyJ0eEhhc2giOiIweGFiYzEyMyIsInN0YXR1cyI6InN1Y...
Content-Type: application/json
{
"domain": "example.com",
"estimate": { "low": 5000000, "mid": 12000000, "high": 25000000 },
"confidence": 82,
...
}
The entire flow happens in seconds. The agent never needed an account, an API key, or a human to approve the transaction.
Why Base and USDC?
x402 is designed to be network-agnostic—it supports EVM chains (like Base and Ethereum) and Solana, with more networks being added. But Base and USDC have emerged as the default for most x402 services, and for good reason:
- USDC is a regulated stablecoin—$1 USDC always equals $1 USD. No currency volatility for either party.
- Base is an Ethereum L2 with sub-cent transaction fees (~$0.001). A $0.02 API call shouldn’t cost $5 in gas.
- Speed—payments settle in seconds, not minutes.
- Ecosystem—Base has the largest concentration of x402 services and tooling.
Why Existing Payment Methods Don’t Work for Agents
To understand why x402 matters, consider what happens when an AI agent needs to use a paid API today:
Credit Cards
An agent can’t apply for a Visa. Credit cards require human identity, KYC verification, billing addresses, and manual approval. Even if you could give an agent a card number, the fraud detection systems would flag autonomous, high-frequency micropayments as suspicious activity.
API Keys with Billing
This is what most developers use today: sign up for an account, add a payment method, get an API key, and include it in requests. It works for humans building applications, but it breaks down for autonomous agents. Every new service requires account creation, billing setup, and key management. An agent that needs to use 50 different APIs would need 50 different accounts.
Subscriptions
Monthly plans assume predictable, steady usage. An agent that needs one API call today and a thousand tomorrow doesn’t fit this model. You either overpay for capacity you don’t use, or you hit limits at the worst possible time.
OAuth / Delegated Tokens
OAuth still requires a human to authorize access. It’s designed for “this app can act on my behalf,” not for “this agent can spend money autonomously.”
The Comparison
| Feature | Traditional API Billing | x402 Protocol |
|---|---|---|
| Account required | Yes — email, password, KYC | No — just a wallet |
| Setup time | Minutes to days | Instant |
| Payment model | Prepaid credits or subscription | Pay-per-request |
| Minimum commitment | $5–$100+ monthly plans | Fractions of a cent |
| Identity required | Yes — name, address, card | No — pseudonymous |
| Agent-friendly | Partial — still needs human setup | Fully autonomous |
| Cross-service | Separate account per service | One wallet, every service |
| Overpayment risk | High (unused credits/capacity) | Zero — pay only for what you use |
| Settlement speed | Days (credit card processing) | Seconds (onchain) |
| Chargeback risk | Yes | No — payments are final |
The key insight: agents need permissionless, per-request payments. No identity. No accounts. No commitments. Just send money, get data. That’s what x402 provides.
The Technical Architecture
Under the hood, x402 is built on a few elegant abstractions that make it both simple to use and flexible enough to handle diverse payment scenarios.
The Three Roles
Every x402 transaction involves three parties:
- Client — The agent or application making the request and paying for the resource.
- Resource Server — The API or service that provides data in exchange for payment.
- Facilitator — A service that handles payment verification and settlement, abstracting away blockchain complexity from the resource server.
The facilitator is what makes x402 practical. Resource servers don’t need to run blockchain nodes, manage gas, or understand RPC calls. They delegate that complexity to a facilitator and focus on serving data.
Payment Schemes
x402 uses “schemes” to define how money moves. The first and most common scheme is exact—a fixed price for a specific resource. You request a domain valuation, the price is $0.02, you pay $0.02.
A future scheme called upto will support variable pricing—pay up to a maximum based on resources consumed. Think LLM token generation, where the final cost depends on how many tokens the model produces.
This extensibility means x402 can adapt to virtually any pricing model without changing the core protocol.
Wallet Infrastructure for Agents
For an agent to make x402 payments, it needs a wallet. There are several approaches:
Coinbase Agentic Wallet — Purpose-built for autonomous agents. Provides programmatic wallet creation, key management, and transaction signing designed for server-side use.
Embedded Wallets — SDKs like Coinbase CDP let you generate wallets programmatically and manage private keys in secure enclaves.
Self-Managed Wallets — For full control, generate a wallet using any Ethereum library and fund it with USDC on Base. The x402 Python and TypeScript SDKs handle the payment flow from there.
Payment Verification and Settlement
x402 supports two verification models:
-
Facilitator verification — The resource server sends the payment payload to a facilitator’s
/verifyendpoint. The facilitator checks the signature, confirms the payment amount, and validates replay protection. After serving the response, the server calls/settleto execute the payment onchain. -
Local verification — For high-throughput services, the resource server can verify payment signatures locally without calling a facilitator, then settle payments in batches.
Both models include replay protection to ensure a payment proof can’t be reused for multiple requests.
Server-Side Integration
Adding x402 to an existing API is straightforward. Here’s a Node.js Express example:
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();
const myWallet = "0xYourWalletAddress"; // Where your USDC revenue lands
// Set up the facilitator (handles payment verification and settlement)
const facilitator = new HTTPFacilitatorClient({ url: "https://x402.org/facilitator" });
const resourceServer = new x402ResourceServer(facilitator)
.register("eip155:8453", new ExactEvmScheme());
app.use(
paymentMiddleware(
{
"GET /v1/valuation/:domain": {
accepts: [{ scheme: "exact", price: "$0.02", network: "eip155:8453", payTo: myWallet }],
description: "Domain valuation",
},
"GET /v1/intel": {
accepts: [{ scheme: "exact", price: "$0.05", network: "eip155:8453", payTo: myWallet }],
description: "Domain intelligence report",
},
},
resourceServer,
)
);
// Your existing route handlers work exactly as before
app.get("/v1/valuation/:domain", (req, res) => {
// This only runs after payment is verified
res.json({ domain: req.params.domain, estimate: { /* ... */ } });
});
One middleware declaration. Your existing routes don’t change. The middleware intercepts requests, handles the 402 flow, verifies payments through a facilitator, and only calls your handler after payment is confirmed.
x402 also has official SDKs for Python (pip install x402[requests,evm]), Go (go get github.com/coinbase/x402/go), and server frameworks including Hono and Next.js.
x402scan: The Block Explorer for Agent Payments
When agents are making autonomous payments, visibility matters. x402scan.com is a block explorer built specifically for x402 transactions. Think of it as Etherscan, but filtered and formatted for the x402 ecosystem.
With x402scan, you can:
- Monitor your service’s revenue — See every payment your API receives in real time
- Debug payment issues — Trace a specific transaction to verify it settled correctly
- Analyze usage patterns — Understand which agents are using your service and how often
- Explore the ecosystem — See all x402-enabled services and the volume of agent payments flowing through the protocol
The numbers speak for themselves. As of early 2026, the x402 ecosystem has processed over 75 million transactions representing more than $24 million in volume, with over 94,000 unique buyers and 22,000 sellers in the last 30 days alone. The agent economy isn’t theoretical—it’s already here.
Real-World Use Case: RobotDomainSearch
Theory is great, but what does x402 look like in practice? RobotDomainSearch is one of the first production APIs built with native x402 support. Our domain intelligence endpoints let AI agents search for domains, get valuations, analyze name presence, and run deep intel reports—all paid for autonomously via x402.
Endpoint Pricing
| Endpoint | Cost | What It Does |
|---|---|---|
/v1/check |
Free | Domain availability across 500+ TLDs |
/v1/valuation/:domain |
$0.02 | Valuation with comparable sales data |
/v1/name-search-presence |
$0.02 | Online presence scoring |
/v1/intel |
$0.05 | Deep intel — parking detection, screenshots, redirects |
Python Example: Autonomous Domain Research
Here’s a complete, copy-pasteable example of an AI agent using the x402 Python SDK to research a domain:
import requests
from eth_account import Account
from x402 import x402ClientSync
from x402.http.clients import x402_requests
from x402.mechanisms.evm import EthAccountSigner
from x402.mechanisms.evm.exact.register import register_exact_evm_client
# Set up x402 client with your agent's wallet (funded with USDC on Base)
PRIVATE_KEY = "0x..."
client = x402ClientSync()
account = Account.from_key(PRIVATE_KEY)
register_exact_evm_client(client, EthAccountSigner(account))
# Step 1: Check availability (free — no payment needed)
response = requests.get(
"https://api.robotdomainsearch.com/v1/check",
params={"name": "myaiproject", "tld": "com,io,ai,dev"}
)
availability = response.json()
print(f"Available TLDs: {[r['tld'] for r in availability['results'] if r['available']]}")
# Steps 2-4 use the x402 session — payment handling is automatic
with x402_requests(client) as session:
# Step 2: Valuate a taken domain (x402 payment — $0.02)
response = session.get("https://api.robotdomainsearch.com/v1/valuation/myaiproject.com")
valuation = response.json()
print(f"Estimated value: ${valuation['estimate']['mid']:,}")
# Step 3: Check name presence (x402 payment — $0.02)
response = session.get(
"https://api.robotdomainsearch.com/v1/name-search-presence",
params={"name": "myaiproject"}
)
presence = response.json()
print(f"Name presence score: {presence['score']}/100")
# Step 4: Get deep intel on a competitor (x402 payment — $0.05)
response = session.get(
"https://api.robotdomainsearch.com/v1/intel",
params={"domain": "competitor.com"}
)
intel = response.json()
print(f"Parked: {intel['parked']}")
Total cost for this entire workflow: $0.09. The agent checked availability for free, then made three paid calls—each settled onchain in seconds. No API key. No account. No subscription. The wallet is the only credential the agent needs.
For a deeper walkthrough including wallet setup and each endpoint’s full response, see our companion post: How to Set Up an Onchain Wallet and Use RDS to Find Domain Names.
Using RDS via MCP
If your agent supports the Model Context Protocol (MCP), you can connect to RDS without writing any HTTP code:
# Add the RDS MCP server to your agent
npx -y @robotdomainsearch/mcp
The MCP server wraps all RDS endpoints as tools your agent can call directly. See our MCP documentation for setup details.
Building Your Own x402 Service
Interested in adding x402 payments to your own API? The barrier to entry is lower than you might think.
What You Need
- A wallet to receive payments — Any Ethereum wallet on Base will work. This is where your USDC revenue lands.
- x402 middleware — Install the SDK for your framework (
@x402/express,@x402/hono,@x402/next, or the Python/Go equivalents). - Pricing logic — Decide what each endpoint costs. x402 supports per-route pricing, so your free endpoints stay free.
- A facilitator — Use the public facilitator or run your own for high-volume services.
Minimal Example
Here’s how little code it takes to turn a standard Express API into an x402-enabled service:
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";
// Set up the facilitator and resource server
const facilitator = new HTTPFacilitatorClient({ url: "https://x402.org/facilitator" });
const resourceServer = new x402ResourceServer(facilitator)
.register("eip155:8453", new ExactEvmScheme());
// Add this middleware — everything else stays the same
app.use(
paymentMiddleware(
{
"GET /api/data": {
accepts: [{ scheme: "exact", price: "$0.01", network: "eip155:8453", payTo: "0xYourWalletAddress" }],
description: "Premium data endpoint",
},
},
resourceServer,
)
);
The middleware handles 402 responses, payment verification, and settlement. Your route handlers only execute after payment is confirmed.
For a detailed tutorial on building an x402 service from scratch, stay tuned for our upcoming guide: Building Your First x402 API (coming soon).
Why x402 Matters for the Future
We’re at the beginning of the agent economy. By 2027, analysts predict millions of AI agents will be operating autonomously—booking travel, managing infrastructure, analyzing data, and making purchases. Every one of those agents will need a way to pay for services.
x402 is positioned to be the TCP/IP of machine payments: invisible infrastructure that just works. Here’s why:
Permissionless Commerce
Any agent can pay any service, instantly, without setup. This creates a truly open marketplace where the best services win based on quality and price, not on who has the most established billing relationship.
Micropayment Economics
x402 makes transactions that cost fractions of a cent economically viable. A $0.001 API call that would be absurd with credit card processing fees ($0.30 minimum) works perfectly onchain. This unlocks entirely new business models.
Agent-to-Agent Transactions
Today, agents pay APIs. Tomorrow, agents will pay other agents. An orchestrator agent might hire a research agent to gather data, a writing agent to draft content, and a design agent to create visuals—each paid per task via x402. The protocol doesn’t care who the client is, human or machine.
No Platform Lock-In
Because x402 is an open standard with no protocol fees, there’s no platform taking a 30% cut. Creators keep what they earn. Agents pay only for what they use. The internet’s original promise of open, permissionless commerce—finally realized at the payment layer.
The First-Mover Advantage
We built RobotDomainSearch with native x402 support because we believe the agent economy is inevitable. The services that are discoverable and payable by agents today will have a structural advantage as autonomous commerce scales. If your API isn’t x402-enabled, agents simply can’t use it—and they’ll find one that is.
Getting Started
The x402 ecosystem is growing fast. Here’s how to get involved:
- Explore the protocol: github.com/coinbase/x402 — open source, well-documented, with examples in TypeScript, Python, and Go
- Watch agent payments live: x402scan.com — see the agent economy in real time
- Try an x402 API: RobotDomainSearch API docs — start with the free
/v1/checkendpoint, then try a paid call - Learn about x402: x402.org — the protocol’s official site with FAQs and ecosystem links
- Set up a wallet: Follow our wallet setup guide to get your agent transacting in minutes
The internet has had a “Payment Required” status code for almost 30 years. x402 finally gives it meaning. As AI agents become the dominant consumers of web services, the protocols that enable them to transact autonomously will become as fundamental as HTTP itself.
The agent economy doesn’t need better billing dashboards. It needs a payment protocol built for machines. That’s x402.