Build a pay-per-request API at the edge. A Cloudflare Worker returns HTTP 402, verifies the payment, and serves USDC-paid responses — no servers to manage.
x402 is pure HTTP, so it drops naturally into a Cloudflare Worker\u2019s fetch handler. AI agents make small, frequent payments; running the paywall at the edge means low latency worldwide and no idle servers. Cloudflare\u2019s own pay per crawl uses the same HTTP 402 mechanism to charge AI crawlers — a sign that 402 is becoming the default way machines pay for web resources.
In your Worker’s fetch handler, when a request has no valid payment, respond with HTTP 402 and a JSON body describing the price (USDC amount) and where to pay.
The client (an AI agent) pays and retries with an X-PAYMENT header. Your Worker forwards it to a facilitator to verify and settle the payment.
Once the facilitator confirms settlement, the Worker returns the real response. The whole exchange happens at the edge in a single round-trip.
Tip: read API keys from the Worker runtime per request (not process.env at module load), and use D1/KV for usage records.
Yes — Workers are a great fit. x402 is just HTTP: your Worker returns a 402 with payment terms, then verifies the X-PAYMENT header against a facilitator before serving the response. Because Workers run at the edge with no cold servers to manage, they suit the small, frequent payments AI agents make. (This very site runs on Cloudflare.)
Cloudflare introduced pay per crawl, which uses the HTTP 402 status code to let publishers charge AI crawlers for access instead of blocking them outright. It is the same 402-based idea x402 formalizes: a server asks to be paid before returning content. The two reflect a broader shift toward 402 as the way machines pay for web resources.
No special product is required — a standard Worker plus a facilitator and a wallet is enough. Cloudflare’s platform (Workers, KV/D1 for state, queues) simply makes it convenient to deploy and scale an x402 endpoint globally.
It does not need to touch the chain. The Worker passes the payment proof to an x402 facilitator, which verifies and settles on-chain, then returns a confirmation. Your Worker only branches on "paid / not paid". See our facilitators page.
Use Workers secrets/environment bindings for keys (never process.env at module load — read them per request from the runtime), and D1 or KV for any usage records. This mirrors how a production x402 endpoint on Cloudflare is structured.
See also: x402 tutorial · x402 with Next.js · Facilitators · x402 & Coinbase