Visa, Mastercard and American Express now sit in the top governance tier of x402, the standard AI agents use to pay for things online. According to a CoinDesk column by Albert Castellana, co-founder and CEO of GenLayer Labs, that standard has no dispute process. His argument is that payment finality is not commercial finality. An agent can pay in milliseconds and still end up holding something wrong, half-delivered or useless. The take here: the interesting gap in agent payments is no longer *can an agent pay*. It's *what happens after it does*.
One caveat first. This is an opinion column, and the views are the author's, not CoinDesk's. Castellana runs a company working on this problem space, so read the framing with that in mind. The facts he cites are worth looking at on their own.
What the column says is on the table
- ▸In July, the Linux Foundation launched the x402 Foundation. Visa, Mastercard and American Express are among its 17 premier members, per the column.
- ▸Coinbase published the x402 protocol in May 2025. Payments settle in hundreds of milliseconds and cost a fraction of a cent.
- ▸Once a stablecoin payment settles onchain, the column notes, there is no issuer to call and no network chargeback to file.
- ▸The column says 97% of observed x402 transactions run on Base and Solana, where stablecoin payments are final. x402 can also run on card rails, which keep card protections.
Why cards have disputes and x402 doesn't
The column traces card trust back to the U.S. Fair Credit Billing Act of 1974, which gave consumers the right to dispute charges. Castellana says that right helped people feel comfortable buying from strangers online.
Card safeguards assume a person who notices a problem and complains. In x402, the buyer is often software, and software doesn't read statements. Castellana calls skipping disputes a sound trade-off while usage was sparse. At machine scale, he argues, the trade-off changes.
The plumbing has its own gaps
The column cites a July study by researchers at EPFL and Zhejiang University, described as the first systematic security study of live x402 deployments. Per the column:
- ▸They tested 15 facilitators, the intermediaries that verify payments and push them onchain. Every one broke at least one of eight safety rules the researchers defined.
- ▸On Base, close to 2% of settlement attempts reverted in late 2025, about 1.9 million payments.
- ▸All seven of Coinbase's official seller reference kits lack a way to undo server actions when settlement fails.
- ▸The Flask kit (up to v0.2.1) releases goods once a payment proof verifies, before settlement is confirmed. If settlement then fails, the seller has delivered and won't be paid.
We haven't re-run that study, so treat these as the researchers' reported findings, relayed through the column. They describe how verify, settle and deliver can come apart. They are not a verdict on any one team, and early infrastructure has bugs. That's what early infrastructure is for.
The harder problem: paid correctly, delivered wrongly
The settlement bugs are fixable. The reverse case is stranger. The payment settles correctly, and the agent receives wrong data, an incomplete answer or nothing useful. A blockchain can prove money moved. It cannot prove the data was correct or that either side kept its end of the deal.
Castellana lists the questions a dispute system has to answer: who absorbs the loss, who decides whether a service arrived, how long a buyer has to complain, and what counts as evidence. Card networks took five decades to build those answers, and each one cost someone money. At a tenth of a cent per call, he says, none of this can involve a lawyer, and most of it can't involve a human.
His closing line is the quotable one: *"We spent the last few years making money programmable. Now we need to make recourse programmable too."*
What a builder does with this today
Nobody has shipped machine-native recourse yet, so the practical move is to design around its absence.
- ▸Order of operations. If you run a seller endpoint, check whether your stack delivers on proof verification or on confirmed settlement. The Flask kit behavior above is the example.
- ▸Spend limits on the buyer side. If an agent can pay, cap what a wrong answer can cost it. A wallet with limits is a recourse substitute.
- ▸Know your facilitator. The facilitator is part of your payment path. Check which one you're using and what it does when settlement fails.
- ▸Log what was paid for and what came back. When a dispute standard does arrive, evidence will be the price of entry.
This is the layer Sato maps: wallets, payment rails, skills and MCPs, so a builder sees the stack before wiring money to it. Describe the agent at satohub.ai/build and see which rails and wallet controls fit.
What to watch
- ▸Whether the x402 Foundation's premier members publish a dispute or recourse proposal. Castellana says they hold most of the institutional knowledge about dispute costs. Whether they build a machine-native version before losses force the issue is the open question.
- ▸Whether facilitators and reference kits change delivery order, so goods ship only after confirmed settlement.
- ▸Whether any card-rail x402 flows become the default for higher-value agent purchases, since those keep card protections.
Agent payment volumes are still small, so a bad month would be survivable, as the column puts it. That window is the time to build the plumbing.