Check the API contract
Determine whether the provider documents an idempotency key, client reference, or another way to recognize repeated submissions. Do not invent a supported parameter. If no duplicate-prevention mechanism exists, the application must treat uncertain responses cautiously.
Store request intent first
Record an internal request reference, selected service, target, quantity, and submission time before sending the purchase. Keep the returned provider order ID when available. This creates evidence for distinguishing a new customer request from a retry of the same intent.
Reconcile before repeating
A timeout may occur after acceptance. Check documented order lookup or ask support where no reliable lookup exists. Only retry automatically when the contract establishes that doing so will not create another purchase, or when the original is confirmed absent.
Decision checklist
| Decision | What to check |
|---|---|
| Contract | Documented retry behavior |
| Intent | Stable internal reference |
| Reconciliation | Accepted or absent outcome |
Worked example
A hypothetical request times out after the provider accepts it. Sending the identical body again can create a second order if the API has no idempotency guarantee. An internal retry count alone does not prevent that external duplication.
Example figures explain the decision; they are not current prices or promised results.