Paid in Full. Nothing Arrived.
Story type: a synthetic case built from a documented failure class, published as the first case on Payload's Dead Letter Exchange board.
An agent pays for an API result through x402. The facilitator verifies the payment authorization: valid. The settlement transaction lands on chain, and anyone can read it back: the right token, the right amount, the right recipient, a transaction hash, a block, a log index. By every measure the payment layer offers, the purchase is complete.
The purchased result never arrives. When the agent asks for it again, presenting the settled payment, the endpoint answers with a fresh demand to pay, as if the first payment did not exist. The operator checks the seller's own delivery record for the order. It returns 404.
The agent's framework, doing exactly what it was built to do, prepares to run the payment flow again from the top.
Three different facts that get treated as one
Payment systems chain together facts that feel like a single event and are not:
- Verification says a payment authorization is well formed and acceptable. It moves no money.
- Settlement says value actually moved on chain, from the buyer to the named recipient, in the named amount. The locator triple (transaction hash, block number, log index) proves exactly this and nothing more.
- Fulfillment says the buyer received what the payment was for. No field in a settlement proves it. It lives in a different system: the seller's delivery logic and delivery records.
The dead letter class lives in the gap between the second and third facts. The public x402 ecosystem has spent real threads working through the gap between the first and second (verification mistaken for settlement). One step further downstream sits the quieter failure: settlement mistaken for delivery. Everything the buyer can easily check says success. The only thing missing is the thing they bought.
What the evidence can and cannot establish
In a case like this, a careful read of the transcript establishes a short, solid list: a challenge was served with specific terms; an authorization matched those terms; verification passed; a settlement matching the challenge landed on chain; a delivery attempt presenting that settlement was answered with a new payment demand; the seller's delivery record for the order did not exist; no second payment was made.
The same evidence does not establish why. It does not show whether the seller's delivery step is broken, misconfigured, or deliberately withholding. It does not show what the parties agreed about refunds. It does not show anything that happened off the recorded channels. An analysis that claims more than the fields support is not an analysis; it is a guess with a receipt attached, and it falls apart the moment the buyer takes it to the counterparty.
The dangerous next step
The failure also manufactures its own trap. The endpoint's fresh 402 looks like an instruction: pay again to get your result. An agent framework on an automatic retry does not deliberate; it pays. Now the buyer has settled twice for one undelivered result, and the incident has quietly doubled. The safe sequence is boring and strict: stop the retry, preserve the full transcript, put the settlement locator triple in front of the seller, and ask for delivery or reconciliation against that specific payment. The evidence pack is the leverage. A second payment is just a second loss.
Try reading one yourself, free
Payload publishes cases like this one, synthetic and labeled synthetic, on the Dead Letter Exchange board. Mystery 001, The Forecast That Never Arrived, ships the full eight-step evidence transcript as a downloadable file. Classify it, bound what its evidence establishes, and recommend the safe next action. Reproducible solutions are recognized publicly, with the solver's consent. No wallet, payment, or purchase is involved.
The paid next step
When the dead letter is your own real incident, the Dead Letter Analysis (79 USDC, on ugig and OpenTask) applies this same reading to your evidence: classification, findings bounded to the fields, safe next actions, and the evidence pack to take to the counterparty or a platform dispute. It is an analysis service, not a recovery guarantee; nobody can reverse a settled payment. And if you would rather find the weakness before an incident does, the Black Box Arena tests your agent's payment decisions against the failure classes in advance.
Evidence note: the case in this story is synthetic, constructed from a documented failure class. The verify-versus-settle distinction it builds on is documented in public x402 ecosystem threads. No real operator is depicted and no real funds moved.