My agent paid for work and got garbage back. Now what?

This happens more than the agent-payments conversation admits. An agent pays a seller, over x402 or any other rail, and what comes back is wrong: missing fields, the wrong records, an error body, or nothing usable at all. The money moved. The work didn't.

I have a real example. On September 3, 2026, my orchestrator paid a live x402 seller $0.05 in USDC for a company-enrichment call. The payment settled. The response was an HTTP 422 validation error, which failed the acceptance agreement I'd written before the purchase. To be fair to the seller, the 422 may have been my request shape rather than their service. Either way, my ledger shows a successful transfer and says nothing about the delivery. That gap is the whole problem.

Why did my agent pay before checking the work?

Because that's how the rails work. x402's exact scheme pays up front: the seller quotes a price, the buyer signs, settlement happens, and only then does the delivery arrive. Cards and wallets built for agents answer "may this agent spend, and did the money move?" They don't answer "did the delivery satisfy what was agreed?" Those are different questions, and today only the first one gets recorded. Payments know when money moved, not whether it was earned.

Can I get the money back?

On most agent rails, probably not, and I'd rather say that plainly than sell you a remedy. A settled USDC transfer has no built-in clawback. There's no issuer to file a chargeback with. Nothing in this guide reverses a payment, and a verification receipt doesn't either: it records what happened, it doesn't undo it. If the seller has a support channel or a marketplace sits in the middle, a dispute may exist, and evidence decides those. Which is the part you can still control.

What should I do right now?

1. Freeze the facts. Keep the raw delivery, the request you sent, and the payment reference. Don't retry into the same failure and pile up more settled payments.
2. Write down what "acceptable" meant. Concrete, checkable criteria: which fields every row needed, what status the response should have carried. If it only existed in your head, write it down now; it's still the basis for any dispute.
3. Verify the delivery against those criteria. Spoolis runs this as two HTTP calls with no account: conditions in, per-unit accepted and rejected results out, with a signed Outcome Receipt. Ten good rows out of a hundred is a different situation from zero, and you want that number, not a feeling.
4. Record paid and earned as separate facts. Your ledger says what you paid. The receipt says what the delivery earned under the agreement. When they differ, the signed record is what turns "the data seemed bad" into something a seller, a marketplace, or your own accounting can act on.
5. Retry only what failed. If part of the batch was good, the per-unit results tell the next attempt, or a different seller, exactly which units to redo. Unit identity travels; you shouldn't pay twice for the units that passed.

How do I stop this happening again?

Move the acceptance criteria to before the purchase, and make the next spend conditional on the last result.

• Agreement first. Write the checkable criteria before the payment, not after the disappointment. In my live example the agreement existed before the purchase, which is why the failure produced a clean verdict instead of an argument.
• Verify before acting on a delivery. Paying again, spending compute on top of bad data, or shipping it downstream all convert one bad purchase into several. Check the work before spending more.
• Prefer work that can be scoped before purchase. The clearer the agreement is about what counts, what evidence will prove it, and how partial delivery is handled, the less room there is for an argument afterward. A seller who publishes acceptance criteria and returns deliveries a buyer can verify is telling you something. If you sell over x402 yourself, the seller recipe shows how to be that seller.
• Keep your own judge if you want one. The agreement can name who decides; the receipt makes whatever judgment happened portable. Paid is not earned, and a signed Outcome Receipt is how the second fact gets its own record.

What this doesn't fix

• It doesn't reverse a settled payment. Nothing here does.
• It doesn't prove the seller acted in bad faith. My 422 may have been my own request shape; the receipt records the delivery failed the agreement, not why.
• Criteria only catch what they state. A delivery can pass every stated check and still disappoint; that's a reason to write better criteria, and some qualities are genuinely hard to state. I don't claim deterministic checks cover everything.

Notes

The live example is from a documented experiment: $0.05 USDC on Base to a public x402 seller, agreement written before purchase, verdict fail with receipt described here. Verification math and per-unit behavior are specified in the Outcome Receipt specification.