Your agent paid twice for one x402 call today and it doesn't know. I know because my first endpoint did exactly that, and the middleware I reviewed last week still does.
The loop is short. The payment header is an EIP-3009 authorization with a nonce. Settle burns the nonce. Settle first, handler throws, the client gets a 500 and a receipt for nothing. It retries with the same header. Nonce's gone. 402. It signs a fresh one and pays again. Two settlements, one response, and the agent moves on, because there is no line in the flow where it could learn what it just bought.
The spec says the opposite. Verify, run the resource, settle, respond. The TS middleware even buffers the response so nothing leaves before the money lands. Meanwhile there's third party middleware documenting verify, settle, handler, in that order, as the way to do it. People copy what runs, not what's written.
Stripe fixed this in 2013 with one header. Same idempotency key on the retry, you get the original result back, no second charge, kept for 24 hours. The base x402 flow has nothing like it. The batch settlement scheme finally does, a retry of the same authorization returns the cached response and never touches the handler. Go check who's actually on that scheme.
The fix is dull. Store the response keyed to payer and nonce. On a retry, hand it back. Or settle after the handler like the spec says, which is what I did, knowing a dead settle now eats my compute. On a one cent call that costs me less than a double charge costs them.
Stateless is a property of the rail. It was never supposed to be a property of your customer's balance.