Zero-Dependency x402 Micropayment API: Pay-Per-Call for AI Agents

Why the 402 Status Code Suddenly Matters

HTTP 402 "Payment Required" has been in the spec since 1997, but it wasn't until the x402 protocol emerged that it was actually put to use. A developer recently built a genuinely functional pay-per-call API on the Cloudflare Pages free plan, using a single _worker.js and zero npm dependencies. When an AI agent calls the endpoint, it receives a 402 with machine-readable payment terms, signs an authorization, retries, and immediately gets the data. No registration, no API key, no Stripe account.

This article breaks down the implementation logic and explores its infrastructure significance for the AI agent economy.

Breaking Down the x402 Payment Flow

Three-Step Handshake

The entire flow has three steps:

1. The agent sends a request GET /api/apis/search?q=weather without payment information, and the server returns 402 with a base64-encoded PAYMENT-REQUIRED header (x402 v2), while the response body also provides payment requirements in JSON format (x402 v1, for older clients). The terms are clear: pay 5000 USDC atomic units — $0.005 — on the Base chain, to a specified recipient address.
2. The client signs an EIP-3009 transferWithAuthorization and retries with a PAYMENT-SIGNATURE header.
3. The Worker POSTs the signed payload to the facilitator's /verify endpoint for validation, and once verified, executes the business logic, then calls /settle to settle. The facilitator broadcasts the transfer and pays gas, with USDC going directly into the author's wallet.

The key to this flow is: payment and business logic are decoupled. The Worker itself never touches private keys or manages funds — it only verifies signatures and triggers settlement.

EIP-3009 and transferWithAuthorization: EIP-3009 is a "gasless transfer authorization" standard on Ethereum for ERC-20 tokens like USDC. It allows token holders to sign a transferWithAuthorization message offline, specifying from, to, value, validAfter, validBefore, and nonce, and any third party (such as a facilitator) can use this signature to initiate an on-chain transfer on the holder's behalf. Since the signature itself consumes no gas, the holder doesn't need to hold native tokens to complete payment; gas is borne by the broadcaster. x402 leverages this mechanism so AI agents only need to sign an authorization with their private key, without managing on-chain gas or pre-converting USDC into the chain's native token.

Facilitator: In the x402 protocol, a facilitator is an independent intermediary service responsible for two things: /verify checks whether the payment signature submitted by the client is valid (amount, recipient, validity period, nonce, etc.), and /settle broadcasts the signed transaction on-chain and pays gas after verification passes, completing the actual USDC transfer. The service provider (Worker) doesn't touch private keys, manage funds, or run blockchain nodes — it only forwards the signed payload to the facilitator, so the payment layer can be completely stateless.

A Facilitator That Doesn't Need API Keys

The original author found that Coinbase's facilitator requires CDP keys on mainnet, but some public facilitators require no authentication at all. He used PayAI (facilitator.payai.network) as his primary and xpay (facilitator.xpay.sh) as a backup. The code is simple: iterate through the facilitator list, POST the payload, and treat a result containing isValid or success as success. This lowers the barrier to building a paid API — you don't need to open a Coinbase account or apply for keys, just a wallet address.

PAYMENT-REQUIRED and PAYMENT-SIGNATURE headers: These two custom HTTP headers are the data carriers of the x402 protocol. The server returns PAYMENT-REQUIRED in the 402 response, base64-encoded, containing machine-readable terms such as x402 version, payment network (e.g., Base), asset contract address, amount (in atomic units), recipient address, and validity period. The client parses this, constructs and signs an EIP-3009 authorization, then puts the signed result in the PAYMENT-SIGNATURE request header and retries. Because these headers are custom, ordinary browsers or unadapted clients will only see the 402 and JSON response body and won't accidentally trigger payment; only agents that understand x402 will continue the handshake.

Zero-Cost Testing and Pay-for-Results Design

Verifying Signature Correctness with an Empty Wallet

The author used a brand-new empty wallet generated by viem to sign correct authorization information and send it to the live API. The facilitator returned an invalid_exact_evm_insufficient_balance error. This error actually confirms that the signature format, EIP-712 domain (USD Coin, version 2, chain ID 8453), amount, and recipient were all accepted — the only thing missing was balance. This is a zero-cost end-to-end check — without spending a cent, you can confirm the integrity of the payment channel.

Execute First, Settle Later

The code logic is verify → execute → settle. If the execution step fails (e.g., bad parameters, invalid URL), it returns 400 directly and never calls settle, so the agent pays nothing. This detail matters because AI agents retry frequently; if you charge before executing, failed requests also incur fees, which erodes trust.

Why the verify → execute → settle order matters: In traditional payments, charging usually happens before service delivery to avoid bad debt. But AI agents' calling patterns are different: agents make exploratory requests based on incomplete information, and failed retries are extremely frequent. If you settle before executing, any parameter error, timeout, or upstream data source failure means the agent pays for a service it didn't receive — and this accumulates quickly, eroding the agent's trust in the endpoint, potentially causing the agent to blacklist the API in its discovery layer. x402 recommends verifying first (only checking signature validity and balance, without broadcasting the transaction), then executing business logic, and only calling settle if execution succeeds. This way failed requests cost nothing, agents can retry confidently, and service providers don't lose gas to failed executions.

Making Your Paid API Discoverable to AI Agents

If nobody can find your paid API, your revenue is zero. The author lists several effective discovery channels:

• Bazaar metadata: Embed extensions.bazaar in the 402 response, providing input/output JSON schemas so agent marketplaces can index it.
• OpenAPI spec: Attach x-payment-info to each paid operation and provide a /.well-known/x402 endpoint.
• x402dash: POST each endpoint once to https://api.x402dash.com/v1/register, and it probes the 402 response in real time.
• x402scan: Requires wallet signature (Sign-In-With-X), handled by @x402/extensions.

The author emphasizes that discovery is where the real work lies — don't put all your effort into the code.

Bazaar and the x402 discovery layer: Bazaar is a metadata mechanism in the x402 ecosystem for indexing paid endpoints. The server declares each endpoint's input/output JSON schema, price, and description in the extensions.bazaar field of the 402 response, which agent marketplaces or crawlers can use to automatically discover and call APIs. Working alongside it is the /.well-known/x402 endpoint, which returns the OpenAPI spec for the entire service, where each paid operation carries an x-payment-info extension describing the price and payment network. x402dash and x402scan are third-party directories: the former indexes endpoints by actively probing 402 responses, while the latter requires a wallet signature (Sign-In-With-X) to prove endpoint ownership. Together these mechanisms form the "search engine" of the agent economy, but it's still early days — the registration process is fragmented and requires manual steps.

What Does This API Sell?

The author's live API offers four paid endpoints, each priced at $0.001:

• /api/apis/search: Searches 2,230 link-checked public and free-tier APIs, with filters like auth=none&alive=yes.
• /api/free-tiers: Current free quotas for developer services and LLM APIs.
• /api/robots-check: Checks whether a given user-agent is allowed to crawl a specified URL.
• /api/page-meta: Extracts the title, OG tags, and heading structure of public pages (respecting robots.txt).

Free endpoints include /api/apis/sample, /openapi.json, and /health. The product idea is clear: sell data, not compute. For an agent, the $0.001 cost per call is negligible, but it saves the hassle of scraping and cleaning data yourself.

Implications for the AI Agent Economy

The core contribution of this project isn't its technical complexity, but that it proves several key points:

1. x402 can run on free edge runtimes. No server, database, or API keys needed. The Cloudflare Workers free plan is sufficient.
2. The payment layer can be completely stateless. Signature verification and settlement are delegated to the facilitator; the service provider only cares about business logic.
3. Agent-native payments are viable. With no human interaction, agents autonomously make payment decisions and sign — a structural change in the API economy, shifting from "subscription-based" to "pay-per-call."
4. The discovery layer is the bottleneck. The ecosystem is still early, and listing an API requires manual work across multiple registries.

The author recommends returning both v1 and v2 challenge formats, because real-world clients use both. This detail shows x402 is still in a transition period, and compatibility must be handled manually.

For developers who want to try it, you can directly read the live API's 402 response, understand the format, and implement it yourself. The author also offers a paid starter kit that includes testing and listing steps.

Conclusion

x402 finally gives the 402 status code from 1997 a real purpose. A zero-dependency Worker, a public facilitator, and a wallet address are all you need to build a pay-per-call API for AI agents. The technical barrier is already low — the real barrier is discovery and traffic, which is typical of any API economy in its early days.

One-line Summary

x402 revives HTTP 402: a zero-dependency Worker is all you need to build a pay-per-call API for AI agents.

Paragraph Summary

The article breaks down a pay-per-call API running on the Cloudflare Pages free plan: the developer used just one _worker.js and zero npm dependencies to implement the x402 payment flow. AI agents receive a 402 with machine-readable payment terms on request, sign an EIP-3009 authorization, and retry; the Worker hands the signature to a public facilitator for verification and settlement, with USDC going directly into the author's wallet. The key design is verify → execute → settle — failed executions don't settle, avoiding invalid charges from agent retries. The author used an empty-wallet signature to verify payment channel integrity at zero cost. The article also discusses the discovery-layer bottleneck, requiring registration across channels like Bazaar, OpenAPI, x402dash, and x402scan, and sees this as a structural shift in the API economy from subscriptions to pay-per-call.