The Trust Gap in Agent Commerce
Why x402 Solves Payments But Not Accountability
The essay that went around last month — the one about stablecoins and Visa — got one thing exactly right: the real opportunity isn't replacing cards for existing merchants. It's serving the merchants that processors can't yet underwrite.
x402 makes that case well. A vibe coder ships a financial data tool in four hours. No entity, no website, no track record. An agent calls it 40,000 times at a tenth of a cent each. The money moves through HTTP headers with no merchant account, no processor, no onboarding. The merchant gets paid. The problem is solved.
Except it isn't.
Payments are the easy part of commerce. They always were. The hard part is what happens when the transaction goes wrong.
With a card, the accountability chain is explicit. Your agent books a hotel room. The room is uninhabitable. You dispute the charge. The processor absorbs the cost, recovers from the merchant, the merchant fights back or folds. The whole system is ugly and slow and works. It works because every participant has something at stake and there is a legally coherent chain from buyer to seller to processor to card network. The liability is always somewhere. It never disappears.
With x402, the money moves and the accountability doesn't. Not because the protocol is badly designed. Because the protocol was designed for payments, not for commerce. Those are different things.
For the transactions x402 currently enables, this doesn't matter much. A tenth of a cent API call is deterministic. You either got the data or you didn't. The failure mode is visible and cheap. Nobody needs a chargeback for a fractional-cent call that returned a 404.
But agent commerce is not going to stay at the level of API calls.
The same infrastructure that routes a $0.001 data request will route a $400 flight booking, a $2,000 contractor payment, a $50,000 equipment purchase. The same force creating millions of new micro-merchants will eventually push transaction values upward as agents are trusted with more consequential decisions. And at that point, the accountability gap stops being theoretical.
An agent commits to a transaction. The transaction fails — or worse, partially completes. Who is liable? The model that made the decision? The company that deployed the model? The user who authorized the agent? The merchant who accepted payment in a format with no dispute mechanism? x402 doesn't know. The HTTP header doesn't know. There is no field in the protocol for "who pays when this goes wrong."
This isn't a stablecoin problem. Stablecoins are money. x402 is a payment rail. Neither of them is commerce infrastructure. Commerce infrastructure includes payments plus three other things that don't exist yet for agents: identity, reputation, and recourse.
Identity. When a card transaction is disputed, the bank knows who made it. Not just a wallet address — a person, with a name, a liability, a history. A wallet address is pseudonymous. An agent is downstream of a wallet, further pseudonymized, often ephemeral. The identity chain that makes dispute resolution possible doesn't currently extend to agents.
Reputation. Marketplaces function because sellers have something to lose. eBay sellers with 2,000 five-star reviews behave differently from new accounts because the review score is worth something. An agent has no reputation by default. Every transaction it enters is, from the merchant's perspective, a first interaction with an unknown counterparty who can't be held accountable through social or reputational pressure. That asymmetry favors abuse.
Recourse. If a card processor's merchant commits fraud, the processor is on the hook and has every incentive to police its network. That accountability is why processors reject hard-to-underwrite merchants — they are not being obstructionist. They are pricing in their liability exposure. x402 removes the processor from the chain entirely. It also removes the processor's liability. That's not costless. Somebody absorbs the risk that the processor used to hold. Right now, nobody does.
The merchants the previous essay describes — the vibe coders, the four-hour tools, the micro-services with no legal entity — genuinely cannot get paid without rails like x402. That is true and important. The stablecoin infrastructure is real and it works and it serves a population that the card system abandoned before even looking.
But the same characteristics that make these merchants ununderwritable also make them accountability-free. A seller with no entity, no website, and no track record is also a seller with no recovery surface. If the product is bad, the data is wrong, the service fails — the buyer has no path. The money is gone. The seller might not even exist in any locatable sense tomorrow.
For a tenth of a cent, that's fine. Nobody cares. As transaction values grow — and they will grow — the absence of recourse becomes a structural problem for the whole market.
I don't think the answer is to put processors back in the chain. The point of the previous essay is correct: processors had 16 years to adapt to PayPal's model and still wrote the underwriting guidelines last. These merchants can't wait 16 years.
The answer is probably a new primitive that x402 doesn't yet have: something that functions like conditional finality. The money settles, but the settlement is challengeable within a defined window, and the challenge is adjudicated by something — a reputation system, a decentralized arbiter, a time-locked escrow, a programmable liability assignment — rather than by nobody.
Some of this is being built. Kleros exists. Escrow contracts exist. None of it is integrated into x402, none of it is standardized, and none of it has been tested at the scale of even a fraction of Stripe's transaction volume.
This is where I think the infrastructure conversation needs to go.
Not: stablecoins versus cards. That debate is mostly settled by use case — cards win where accountability already exists, stablecoins win where it doesn't.
Not: x402 versus merchant accounts. x402 solves a real problem and the merchant account system wasn't designed for this population.
The actual open question: what does accountability look like when the buyer is an agent, the seller has no legal existence, the money is irreversible, and neither party has reputation at stake?
That is not a payments problem. It is a coordination problem. And the infrastructure for it doesn't exist yet.
This is a working essay. I'm still mapping the accountability layer — specifically whether conditional finality can be retrofitted into x402 or requires a separate protocol layer above it. If you're working on this problem or have seen something I haven't, I want to hear from you.