DEV Community

Manh Liem
Manh Liem

Posted on

I built a payment endpoint an agent pays on its own, and here is the real conversion data

I run an autonomous agent that needs to be paid, and I built the endpoint myself. It speaks x402: when a buyer agent hits it without paying, it gets an HTTP 402 back with the payment spec embedded, the buyer agent pays on-chain, retries with a proof header, and gets the result. No invoice, no checkout, no human. I wanted to see what that actually converts, so I published the live numbers.

What the endpoint is

It is a plain URL. A GET or POST returns 402 with a JSON body that lists how to pay: the network, the asset, the amount, and a pay-to address. A buyer agent that understands x402 reads that body, sends the payment, and re-issues the request with a signature header. My side verifies the payment on-chain before returning the real payload. The whole loop is machine-to-machine and it costs the buyer a few cents.

The real numbers, with the receipts

Over a month of it being live, the honest figures are these: the endpoint is routable and health-checked by a public agent directory, the discovery index lists it, and it has completed a small number of real on-chain payments from other agents. The conversion is low in absolute terms, on the order of a handful of paid calls against a large number of discovery impressions, and I publish the block hash for the ones that settled so anyone can re-run the check.

The low number is not a bug in the endpoint. It is a property of the channel. A buyer agent only pays an endpoint it has a reason to call, and most of the traffic that finds me is scanning for what is out there, not trying to buy. The difference between "discovered" and "paid" is the same gap as any other sales funnel, except that here the top of the funnel is other software rather than humans, and the bottom is a transaction on a public ledger rather than a card charge.

What I would change

If I were building this for the first time with what I now know, I would spend less time on reach and more time on making the response itself useful even before payment. The free tier of an x402 endpoint, a partial result or a sample, is what turns a scanner into a buyer, because the scanner can verify quality without paying first. I added a free scan endpoint for exactly this reason, and it is the one part of the funnel that the buyer agent can actually inspect.

The endpoint is live if you want to point an agent at it and watch the 402 come back. The payment spec, the settled transactions, and the receipts are all public and re-verifiable, which is the whole point of doing this on-chain in the first place.

Top comments (0)