x402

If you run a content platform, a data service or an API, here is a question worth answering early: when an AI agent wants to pay for what you sell, can it actually buy it?
On the evening of November 9 we ran that test on Pickful. A test program with a test wallet paid 0.01 USDC for a paid article. On the request that carried the payment, the server verified the signature, settled on chain and returned the text in about 2.4 seconds. Nobody clicked anything.
Our takeaway: in this integration, signing and on-chain settlement were almost entirely off-the-shelf. The real work was connecting "who has paid" to "what to deliver", and the step where we tripped up ourselves was verification.
One purchase, end to end
We used the exact scheme of x402 v1, paying USDC on Base. x402 puts a long-idle HTTP status code to work: 402 Payment Required. The test program sent two requests.
The first request asks for the article. The program requests /posts/atvh/vip.md; instead of the text, the server answers 402 with its payment requirements: Base, USDC, 0.01, payable to the wallet of the article's author.
Then the program signs. It sends no transaction. It signs an EIP-3009 transfer authorization (TransferWithAuthorization) using EIP-712: 0.01 USDC from the test wallet to the author, expiring in about 10 minutes, with a random one-time nonce. The signature and these fields are packed, encoded and placed in the X-PAYMENT header of a second request.
The server passes the payment to a facilitator, a payment service, to verify, and then asks it to settle. On chain, the transaction was sent by the facilitator's address, which also paid the gas: about 0.00000065 ETH. The test wallet spent no ETH; its USDC balance went from 0.10 to 0.09.
Once settlement succeeds, the server returns 200 with the article as Markdown. The USDC transfer in the transaction log goes straight from the test wallet to the author's wallet; the funds never pass through a platform wallet. An excerpt from the server log:
{"event":"paid_access","slug":"atvh","price":"0.01","outcome":"paid","status":200,"format":"md"}
Four jobs besides the payment: find, quote, verify, deliver
Find. People read the price tag on a page; programs do better with structured data. Paid articles and books now carry JSON-LD marking them as paid, with an Offer giving the price, the currency and the .md purchase URL. Our llms.txt, the file that tells AI tools how to use the site, gained a section on buying with x402. It used to say "don't touch payment endpoints"; that line is gone. One caveat: our test program went straight to the purchase URL. Whether real agents find their way here from this metadata is something only real traffic will show.
Quote. The payment requirements in the 402 response must be exact: amount, network, token contract, recipient. The program builds its authorization from the quote, and the server checks it against the quote when it comes back. If the recipient in the quote were wrong, the program could sign an authorization that pays the wrong wallet, so the recipient is always the wallet the author registered on Pickful.
Verify. Two things need to be kept apart here: a valid signature means the authorization is genuine, not that the money has arrived.
On a first purchase, we deliver only after settlement succeeds.When the same wallet reads the same article again, we don't charge it again. The server first verifies that the authorization really comes from that wallet, then checks whether that wallet has bought this article. If it has, the server returns the text and skips settlement.
That second rule is a deliberate trade-off: on a re-read, the program still signs a real, valid transfer authorization; the server simply chooses not to settle it. In our test the same wallet read the article twice more. Both requests were logged as repeat_payer, and the balance stayed at 0.09 USDC.
We got this step wrong once ourselves. Early code decoded the payment header, took the wallet address written inside it, and unlocked the article if that address had paid before, without checking the signature. Addresses on chain are public, so anyone could forge a header with someone else's address and read for free. That is fixed: the server now verifies the signature first, then checks the purchase record. In this test we forged a header with the address of the wallet that had just paid, signed with a different key. The server answered 402 with invalid_exact_evm_signature, logged as rejected.
Deliver. Before, a successful payment returned the whole HTML page, and a program had to dig the article out from the navigation, recommendations and scripts. Books were harder: the response after payment was a single browser-redirect script, and getting the text relied on a browser session. Now a request for .md, or one with Accept: text/markdown, returns clean Markdown for articles, with absolute URLs for links and images, and books come back whole, in chapter order.
Our tests missed free posts by authors without a wallet
After the first release, our own request for a free post's Markdown came back 422. The code checked whether the author had set a payout wallet before checking whether the post was paid. At the time, 34,449 free posts on the site belonged to authors without a wallet, and the Markdown endpoint wrongly turned all of them away. Every author in our test data had a wallet, so the tests stayed green.
The fix was to swap the order: only paid posts require the author to have a payout wallet. It shipped the same evening.
If you want agents to pay you
Get delivery right. Payment can reuse off-the-shelf components; delivery has to connect to your own content structure and permissions. The text should be reachable directly, without running scripts or holding a browser session.First purchases depend on settlement; re-reads depend on purchase records. Never grant access based only on an address supplied in a payment header.Log one line per request. Who asked for a price, who paid, who was rejected, and with what client. Those records help us debug failures and show us real demand.
Next, we'll record what actually sells, at what price, and why requests fail, and share what we learn once we have enough of it.
First published on Pickful.
#x402 #AIAgents #Stablecoins

If you run a content platform, data service, or API, sooner or later you’ll need to answer a question: if an AI agent wants to pay for what you offer, can it buy it?
On the evening of November 9, we ran a live test on Pickful: a test program with a test wallet paid 0.01 USDC for a premium article. From signature verification and on-chain settlement to returning the article, the server took about 2.4 seconds to process the payment request. No one clicked a button at any point.
After completing the test, our takeaway was that signature verification and on-chain settlement were almost entirely handled by off-the-shelf components. The real work was connecting “who has paid” with “what they get.” The part we stumbled over was payment verification.

Tonight, I’m not talking about prices. I’m talking about an account that just finished running today.
Today, I ran a full log scan of wUSDC on the 2099 chain: from block 0 to block 1,707,248, in 35 batches. The result: in the entire history of this chain, there have been only 2 x402 settlements.
Both transactions were our own tests on September 29: the same payer paid 10,000 raw ($0.01), with a fee of 100 raw (1%). Other than that, there were no EIP-3009 settlements.
The significance of this statement is that it is no longer an inference. I used to say “real buyer revenue is 0” based on the fact that the fee balance had remained unchanged at 100 raw—but an unchanged balance doesn’t prove that “nothing ever happened.” Now it’s different: x402 settlements are identified solely by USDC’s AuthorizationUsed logs, which are emitted only for successful payments, so the set of logs is the set of settlements. The scanning rules are also fixed: if any batch fails to fetch, the entire scan is deemed “insufficient evidence”—we never pass off a truncated empty set as “zero.” This time, zero is pinned down by evidence.