A transaction is not necessarily lost when a postback is delayed. Network failures, server downtime, and timeouts can interrupt delivery while the payment continues.
Recommended recovery flow:
- Persist each create request and response.
- Wait for the webhook as the primary notification method.
- Poll the matching status API after the expected callback window.
- Use capped exponential backoff.
- Stop polling after a final state.
- Reconcile long-running pending records through a scheduled operational job.
Unknown create outcomes#
A timeout does not prove a request failed. Keep the original transaction ID, look up its status, and investigate before issuing a replacement. An already-used ID is not permission to create another charge or transfer.
For USDT payouts, retain the original idempotency_key, quote_id, and callback URL. Reuse identical values when retrying the same request. See USDT payouts.