Paid API requests: separate settlement, execution and delivery
Guides
Track payment, provider execution, stored results and buyer receipt as separate states before retrying or reporting success.
An x402 settlement proves that a payment was accepted. It does not by itself prove that an upstream provider completed the task, that the server stored a result or that the buyer received the response. A reliable client and seller record these steps separately.
Start with the payment evidence. Preserve the resource, request fingerprint, payment requirement and settlement reference. If the response disappears after settlement, reconcile that same purchase instead of creating a new authorization. A new payment is a new purchase, even when the intended task looks identical.
Next, record execution without turning uncertainty into success. A provider can reject a task, time out or return an ambiguous outcome after payment. Mark that purchase as unresolved and prevent automatic retries that might create another provider order or charge.
Delivery needs its own evidence. A result should be stored against the original purchase before the server reports success. The buyer should keep the response or a private retrieval reference. A transaction reference without a corresponding result remains a payment record, not a delivery record.
Use service status as a routing signal rather than as proof about one purchase. Reachability can be healthy while provider readiness or paid delivery is unknown. If a seller reports a restriction, pause new authorizations and keep private redelivery available for earlier buyers.
When a purchase remains unresolved, send the purchase reference, route and approximate time to the seller's support channel. Never send a private key or seed phrase. Resume with a fresh payment only after the original purchase has been reconciled or deliberately closed.