Retry an x402 request without paying twice
Guides
Keep one logical request, one payment identifier and the original payment evidence together before retrying after a timeout.
A timeout leaves an important question unanswered: did the server fail before settlement, or was the payment accepted while the response was lost? Do not create a fresh payment authorization simply because the first response is missing. Preserve the original request and reconcile it first.
Record the HTTP method, resource URL, normalized input, payment requirement, payment signature, request time and any PAYMENT-RESPONSE or transaction reference. These values let a client distinguish a retry of the same logical operation from a new purchase. Changing the body, route, amount, asset, recipient or network means it is no longer the same request.
If the server advertises the official payment-identifier extension, generate one unique identifier for the logical request and persist it before sending the payment. Reuse that identifier for retries of the same request, including after a client restart. Never reuse it for another operation.
The extension works only when the server declares support. The x402 documentation says a server should bind the identifier to a request fingerprint and return a cached response for the same identifier and same request. The same identifier with a different fingerprint should be rejected instead of exposing an earlier result or processing another payment.
After any ambiguous response, check the existing payment and delivery evidence before signing again. A settlement reference proves the payment side; the returned result still needs its own content and completeness checks. A reachable status page can show known limitations, but it cannot prove that a particular paid request was delivered.
If the server cannot recover or reconcile the original purchase, keep the evidence and contact its payment support. State the resource, time and purchase reference without sending private keys or seed phrases. A second authorization should be a deliberate new purchase, not an automatic timeout retry.