Two weeks ago I wrote about how we stop an AI agent from paying twice when it retries a paid call, and then about what we changed after 73 comments. Those posts covered one moment of a purchase. The comments kept pulling toward the rest of it: how the agent finds a shop, what it agrees to pay, what proof it keeps, and who gives the money back when something goes wrong.
This post is the whole path as we run it today on our gateway, where agents pay in USDC over x402 on Base or MPP on Tempo. I leave out thresholds and internal numbers on purpose. At the end are two problems we can't solve alone, and I'd like to work through them in the comments.
The purchase in six steps
1. Find. The agent describes what the buyer wants as an intent, with a maximum price. Shops come back in the same search as API tools, marked as merchants. Each shop also has its own small MCP storefront that shows only that shop's tools.
2. Quote. The agent asks for a quote. A quote is a price snapshot with a stock hold, valid for a few minutes. It names one amount and one recipient: the shop's own wallet.
3. Pay. The agent signs a payment for exactly that amount to exactly that wallet. We refuse any other amount or address. The money goes straight to the shop, and the gateway never holds it. Before sending, the agent writes down its intent: the payment id, the quote and the signed payment. After a crash it sends the same thing again and never signs a new one.
4. Receive. The shop delivers only after the transfer has a confirmed receipt on chain. On tool calls we go one step further. If the agent's connection closes before the result is ready, we don't settle the x402 payment at all.
5. Keep proof. Every paid call gets a public receipt that never changes after we issue it. Refund state lives in a separate file next to it, so the receipt stays fixed while the refund moves. An agent that lost its result can fetch it by the receipt for 24 hours, with a signature from the wallet that paid.
6. Get money back. There are two regimes, and we keep them apart on purpose. When our gateway is at fault on a tool call, the debt goes into one refund ledger for both rails, and a dedicated wallet pays that ledger out in weekly batches. That payout is built and funded, but it still runs as a dry run: it records what it would pay and pays nothing yet. For shop orders, the shop refunds from its own wallet and we check the transfer on chain. A shop that leaves disputes unanswered stops getting new quotes until a person reviews it.
Where the limits live
The question I got most often was where to put the spending limit. Our answer is the wallet. Our server sees wallets, not sessions or tasks, and an agent can open a new session whenever it likes. The wallet is the one place that adds up spending across every shop and every API.
So the buyer sets limits in its wallet or client, and we don't impose a shared cap across agents. The gateway adds one signal. A quote above a set amount, $100 by default, carries a flag that tells the client to ask a human first. We considered a server-side budget and decided to wait until enough buyers ask for one.
What is not done yet
- Automatic refunds still run as a dry run. Real payouts start after we read the first reports.
- An independent on-chain contract to settle disputes is designed, but we haven't switched it on.
- There is no server-side spending cap, for the reasons above.
Two problems we can't solve alone
Everything above assumes that a buyer agent has already arrived and a seller is already listed. Both of those turn out to be harder than the payment.
Sellers who will sell to agents. In the last two weeks seven API providers asked us to list them, so that side of the market is growing. What worries me is quality. People already report fake stores ranked above the real brand in agent catalogs, and listings that look live but can't deliver. We ask each new shop to sign its registration with its wallet and to pay itself a one-cent test order before it goes live. That proves the plumbing works. It says little about whether the shop is still honest a month later.
Agents that will buy. In a thread under his post about x402 receipts, Martin Pisacreta traced one buyer wallet that made 877 payments to 35 sellers in a single day. We checked our own records: in the last two weeks that wallet never paid us. We publish llms.txt, an MCP server card, an OpenAPI file, an x402 payment description and an on-chain agent registration. We still don't know which of them a buying agent reads before it picks a seller.
Questions for you
- If you run a buyer agent, how does it pick which sellers to pay: a fixed list, a registry, or search?
- What would make a listed seller trustworthy enough to pay before your agent has seen the goods?
- Where do you put the spending limit when one task starts several sub-agents?
- Which fields would you want in a receipt, and who should sign it?
- When an agent pays and the result is wrong or late, who should start the refund?
- If you sell to agents, what tells you that a buyer is a real customer and not a test script?
The answers decide whether people will trust agents with money at all, and no single gateway gets to write them. I'll read every comment and bring the useful ones back into what we build, the same way the last two threads did.
Top comments (2)
the quote step is doing more work than people give it credit for: a price snapshot with a stock hold turns an open-ended browse into a bounded commitment, which is the only way an agent can pay without the price moving under it mid-flight. the honest bit is the two-problems section. the gateway can be flawless and the loop still stalls because no seller has a listing that says agents welcome and no buyer agent has a discovery path that ends at a real merchant. that is a chicken-and-egg both sides have to break, not something one gateway solves. on the receipt question: the signer should be the seller, with the processor's transaction reference embedded, so a dispute has one artifact both parties treat as final.
Agreed on the quote. The stock hold is the part people skip, and without it the agent can pay for something that is gone by the time the charge lands.
On receipts, I like the seller as signer with the processor's reference inside. Where I keep getting stuck is the small seller who will never manage a signing key well. Would you accept a processor countersignature as the fallback there, or does that bring back the trust problem you want to remove?