On August 27, 2026 we shipped three HTTP endpoints that sell real growth services for USDC. On August 28 at 12:34 UTC, a wallet we had never seen sent one of them $20 and bought a boost — ten replies from real community members on a real post. No account. No API key. No onboarding call, no invoice, no human on our side. A machine found the endpoint, read the price, paid it, and got the thing.
That's the shortest possible description of what x402 unlocks, and why it deserves a weekend of your time. This post is the build log — written as the guide we wanted while building it. Every trap below cost us real hours; a couple cost us a day. If you ship anything an agent could plausibly want to buy, copying this should save you most of that.
A giant market of tiny payments — and an obvious gap
The headline numbers on x402 are enormous. As of this writing, public trackers count roughly 173 million settled x402 payments across 12 chains and 18 facilitators, moving about $41.5 million in stablecoins. Base carries the overwhelming majority of it.
Now divide. The average x402 payment is worth about 24 cents. Chainalysis' read of the same market found the early spike was largely a pay-to-mint meme mechanic, not commerce. What's actually listed today is what you'd expect at that price: scrapes, searches, single LLM calls, weather, token prices. Machines buying inputs.
Almost nobody is selling an outcome. That's the gap. An agent running growth for a founder doesn't want a scrape of X — it wants the post to actually get engagement. So we listed the outcome, at outcome prices: $20 for a boost, $50 for a content campaign, $19 for a featured product listing. One of our calls is worth roughly eighty average x402 payments.
Agents are getting budgets before they get accounts. The first businesses that price a result — not a token, not a request — in a way a machine can buy unattended will own a revenue stream that has no CAC, no sales cycle, and no signup form.
x402 in sixty seconds
x402 revives HTTP's long-dormant 402 Payment Required status code. There is no SDK lock-in and no account model: the entire handshake is four moves.
You answer 402 with a machine-readable offer: the price, the asset (USDC), the network (Base), the wallet to pay, and a description of what the caller gets.
An EIP-3009 transferWithAuthorization signature over the exact amount — gasless, off-chain, no approval transaction. It retries the same request with the signature in an X-PAYMENT header.
A facilitator (we use Coinbase's CDP one) tells you the signature is valid and funded. Verification moves no money. Then you do the actual job.
Settlement broadcasts the transfer on Base. Your response IS the receipt: the outcome in the body, the on-chain tx hash in the X-PAYMENT-RESPONSE header.
That's it. No webhooks, no redirects, no checkout page, no PCI. About 80 lines of seller-side code for the happy path. The remaining 90% of the work — everything below — is making it survive contact with an actual autonomous buyer.
Build for humans first. Then the dual play is unfair.
The strongest thing we had going in wasn't crypto plumbing — it was a product that already worked for people. ProductClank had spent months getting one thing right: a builder posts a link, and a real community of creators replies, reposts, and creates content around it. Campaign creation, credit billing, fraud checks, reply generation, payout rules — all of it hardened by human usage.
So the x402 endpoints don't reimplement anything. Each one is a thin payment shell around the exact route a logged-in user already hits. That's the whole trick, and it's why this took days instead of a quarter:
Read the X-PAYMENT header, check it with the facilitator, and extract the payer's wallet address. Everything downstream is authorized by that verified address, never by anything in the request body.
Each paying wallet gets a synthetic user + a non-trusted agent record, auto-provisioned on first payment. The wallet address IS the identity — the same model we already use for MCP connector agents.
A UNIQUE constraint on the payment nonce in our Checkouts table. Replaying a signed payment can never buy a second campaign — the database refuses it, not the application logic.
We hand the provisioned account precisely the credit cost of the job and call our normal v1 agent route with its key. The route's own credit check and deduction net to zero. Rate limits, fraud rules, admin surfaces, and analytics all behave exactly as they do for a human customer, because it IS the human customer's code path.
The work succeeded, so we settle. If it failed, we claw back the granted credits, release the nonce, and return an error that says, in words, that no money moved.
Building for humans first isn't the slow path to agent revenue — it's the moat. Anyone can wrap an LLM call in a 402. Almost nobody can deliver a real community of humans doing real work behind one. When the buyer is an agent, the scarce thing is no longer software; it's whatever your software can only do because humans already trust it.
Seven things that will bite you (they bit us)
1 · Verify → work → settle. Never the other order.
The obvious implementation takes the money and then does the job. Don't. Verification is free and moves nothing; settlement is final. Do the work in between, and settle only on success. A failed call must cost the payer exactly zero — because an agent that gets charged for a failure has no human nearby to complain, and it will simply never call you again.
This ordering has a second benefit: it makes retries safe by construction. Failed call → nonce released → the agent can honestly re-pay with the same signature. That property is what makes the next four items possible.
2 · Your description is your storefront — write it for a model
This is the single most underrated part of x402, and the thing we'd tell everyone to spend real time on. Catalogs list your endpoint using the metadata you put in the 402 challenge: a service name, tags, a description capped at 500 characters, a complete JSON Schema for the input, and a realistic example of the output. That metadata isn't documentation — it's the entire sales page, and the reader is a language model deciding whether to spend its owner's money.
So write it the way you'd brief a capable stranger with no context and no ability to ask a follow-up question. Ours names the deliverable ("10 authentic AI-drafted replies posted by real community members, or 30 likes / 10 reposts"), the supported platforms, what to send ("the post URL"), what comes back ("a campaign id and a public tracking URL"), and — crucially — when ("engagement typically lands within 24–48 hours"). Every enum value in the schema carries its own description. An agent that has to guess will either guess wrong or move on.
If a competent human couldn't buy the right thing from your description alone, without opening your docs, an agent definitely can't. Every ambiguity you leave becomes either a wrong purchase, a support ticket you'll never receive, or an abandoned call.
3 · Every response must say whether money moved
Human checkout has a UI to reassure you. An agent has one string. So we made every terminal response state the money fact in plain language. A validation error reads: "Missing required field: post_url. Your payment was NOT settled — retry with a valid body." A downstream failure appends "Your payment was NOT settled." A success carries the settled flag, the on-chain transaction hash, the amount, and the network.
It looks redundant. It isn't. An agent reading a bare 400 after signing a payment has no way to know whether it just lost $20, and its two options are both bad: assume it paid (and never retry a call that never charged it) or assume it didn't (and risk paying twice). Tell it. One sentence removes the entire class of problem.
4 · The response is the only receipt — so make it unmissable
This is the failure that actually happened to us, on the very first live paid call. x402 has no out-of-band notification: there is no webhook to the buyer, no email, no dashboard they can log into. If the HTTP connection drops, the buyer has paid and has no idea what it bought. Our first call generated ten replies, which takes minutes — the client timed out, and the payer came within a whisker of paying a second time for a boost it had already successfully bought.
We shipped three layers the same day, and we'd build all three from the start next time:
The paid call now commits the campaign and returns immediately with generation: "processing". The slow part (drafting replies) runs in a background task after the response is sent. Never hold an agent's connection open for minutes; its client will give up long before your job finishes.
GET /api/x402/purchases?nonce=… answers 'did my payment settle, and what did it create'. It needs no key, because the nonce is the secret. The URL is advertised in three places: the 402 challenge itself (so the agent knows the escape hatch before it pays), the success response, and the 'payment already used' rejection. found:false means it never settled, so re-paying is safe.
Send one and we POST the finished result when background work completes. SSRF-guarded, one attempt, best-effort — a convenience on top of the recovery endpoint, never a substitute for it.
Design the dropped-connection path before the happy path. With a human buyer that's an edge case. With an agent buyer it is the first thing that happens to you.
5 · Your resource URL must not redirect. At all.
We lost most of a day to this one. Our apex domain 307-redirects to www. Harmless in a browser; fatal here. Catalog validators and x402 clients probe the exact resource URL you advertise, and a redirect fails the probe — the endpoint simply doesn't list. Pin one canonical, redirect-free host in code, and never derive it from a generic app-URL environment variable that might point at the apex, a preview deployment, or a legacy subdomain.
6 · Keep returning 402 forever
An unpaid call must always get a 402 with the full offer. Put auth, a rate-limit redirect, or a maintenance page in front of it and you get delisted from the catalogs entirely. Related: no settlements for 30 days removes you from the Bazaar catalog, so we run a small self-purchase as a monthly heartbeat. Health probes also hit the endpoint continuously — sustained failures down-rank you before they drop you.
7 · Remember the human behind the agent
Our sharpest product surprise. Campaigns bought over x402 are owned by the payer wallet's synthetic account — which means the founder whose agent just spent $20 couldn't see the campaign anywhere in their own dashboard. Technically correct, completely useless.
The fix is a self-serve claim page: the human signs in, proves control of the payer wallet with a signature, and gets delegation over that wallet's campaigns — deliberately not ownership, so the wallet keeps working for future autonomous payments, and several teammates can claim the same shared agent wallet. Three details we got wrong first:
Our first version was a pretty multi-line SIWE-style message. It gets mangled the moment a human copies it into a chat window to ask their agent to sign it — and then the signature never verifies. One line, plain ASCII, survives every relay path.
Every paid response carries a note aimed at the agent: use personal_sign / signMessage (EIP-191) with the same key you paid with — not signTypedData, not a transaction. Without that sentence, agents confidently produce the wrong signature type and blame your endpoint.
Agent wallets are increasingly smart accounts. Verify signatures through a path that supports ERC-1271 and ERC-6492 alongside plain EOAs, or you'll reject exactly the sophisticated buyers you most want.
How agents actually find you (two registries, not one)
Shipping the endpoint is half the job. Discovery is the other half, and it works differently than anyone expects — there are two independent registries and they do not talk to each other.
Registry 1 — the Coinbase x402 Bazaar
You don't submit a form. You get indexed by making a real payment. The discovery metadata you attach to your 402 challenge rides along inside the payment payload the client echoes back to you; when you settle that payment through the facilitator, the facilitator sees your resource and its metadata and catalogs it.
Coinbase exposes a validate endpoint that fetches your URL and simulates a purchase. You want valid: true and an 'accepted' simulation outcome. This is where a redirecting host or a broken schema shows up.
Any x402 client with a funded Base wallet. We wrote a small seed script and kept it as our monthly heartbeat. This settled payment is the listing event.
Re-run validate and read the index block. Ours reports active: true with a lastCrawledAt of 2026-08-27T17:51:36Z — the same second our first payment settled. Indexing is not a queue; the settlement IS the trigger.
Registry 2 — x402scan, and the discovery document everyone forgets
Here's the part that cost us the most confusion: x402scan does not mirror the Coinbase Bazaar. It runs its own registry, and it finds you a completely different way — its scanner crawls GET {your-origin}/openapi.json. Be listed in the Bazaar, be live, be settling payments, and still be invisible on x402scan, because you never served that file.
So we generate one from the same endpoint configs that build the 402 challenges — one source of truth, no drift. Two details matter: every paid operation needs its price declared in decimal USD plus a documented 402 response, and any free endpoint (our purchases lookup) must declare empty security so the scanner doesn't probe it for a payment challenge and mark it broken. Then register the origin once on x402scan and it re-scans from there.
1. One canonical, redirect-free host. 2. 402 on every unpaid call, forever. 3. Description ≤500 chars, complete input schema, realistic output example. 4. One real settled mainnet payment to trigger Bazaar indexing. 5. Serve /openapi.json and register on x402scan separately. 6. A monthly heartbeat purchase so you don't age out after 30 quiet days.
Three transactions, all on-chain
We tested the way we think everyone should: we pointed our own agent at our own public endpoints and made it pay real money, before asking anyone else to. Every one of these is a settled USDC transfer on Base — transferWithAuthorization, gasless for the payer, confirmed in under two seconds.
Our own agent · 0xa68431dd…7293
Our own agent · 0x58b9492f…89de
Someone else's wallet · 0x0e3db622…63df
Our own agent · 0xa68431dd…7293
Our own agent · 0x58b9492f…89de
Someone else's wallet · 0x0e3db622…63df
We wrote up the launch in real time on X — the thread on shipping it, and then the first purchase from outside. The second one is the milestone worth internalizing: the moment a business has a buyer it never spoke to, in a channel where nobody was competing for the shelf space.
x402 is one rail. It isn't the only one.
Be clear-eyed: x402 is stablecoin-only. If an agent doesn't hold USDC, it cannot buy from you — which is fine for crypto-native buyers and a hard ceiling everywhere else. And the volume charts flatter the market; a lot of those 173 million settlements are tests, infrastructure traffic, and self-directed usage rather than distinct paying customers.
Meanwhile the same idea is being built on other rails. MPP (Stripe and Tempo) revives the identical 402 status code but is multi-rail from day one — an agent can pay in fiat with a shared payment token or in stablecoins, and its "sessions" model lets an agent pre-authorize a spending limit and stream micropayments against it. Google's AP2 takes a mandate-based approach to delegated spending authority, and ACP standardizes agent-to-merchant checkout. Visa and Mastercard are moving too.
We're implementing MPP next, on the same endpoints, and we'll publish that build log the same way — including an honest comparison of which rail actually brings buyers. Follow along if that's useful to you.
The work isn't the payment code — that's an afternoon. The work is making your service legible and safe to an autonomous buyer: a description precise enough to buy from, a price attached to an outcome, an explicit statement of whether money moved, a way to recover a lost response, and a path back to the human who owns the agent. Do those five things and you have a sales channel that runs while you sleep.
Our three endpoints are live and documented at productclank.com/developers — call one with no payment and read the 402 you get back; it's the fastest way to see the whole shape of this. If you're building something an agent should be able to buy, we'd genuinely like to hear about it.