Give the intended operation a stable identity
A customer order may lead to a payment invoice, but the order and the HTTP request are not the same object. One business intention can involve several network attempts. Store an internal reference for the intention and connect it to the provider’s request or invoice identifiers as they become available.
The WATADCASH payment example shows an idempotency header when creating an invoice. Follow the current API contract for how that header should be used. Do not invent assumptions about retention periods, identical responses or unsupported endpoints. The important application decision is to distinguish retrying the same operation from asking for a different operation.
Treat an unknown response as unknown
If a request times out, your application may not yet know its outcome. That is different from a confirmed failure. Give your operations team and customer interface a state that reflects the uncertainty rather than labelling every missing response as a rejected payment.
Before making another financial instruction, review the documented status or lookup route available for the operation. Keep the original reference and any provider identifier you received. A support request that includes those references gives the provider something specific to investigate; a series of newly created instructions can make it harder to determine which one belongs to the customer’s order.
Separate request retries from webhook duplicates
An outgoing request retry and an incoming repeated webhook happen on opposite sides of the integration. Both need identifiers, but they should not share a vague “duplicate” flag. The outgoing record tracks what your system intended to ask. The incoming record tracks which provider event your system has already processed.
WATADCASH’s webhook documentation describes storing an event once and avoiding repeated financial effects. Apply that guidance to the order transition as well. A repeated authentic event should not trigger another product delivery just because it reaches a different application worker. Keep the decision in durable application state that all workers consult consistently.
Do not let retries change the request silently
A retry should not quietly acquire a different amount, recipient or order reference. If the customer edits an order while its payment outcome is unresolved, make that change explicit in your workflow. Otherwise the same screen can conceal two different business intentions.
Keep the amount and relevant order details associated with the request you created. When a meaningful change requires a new operation, record the relationship to the earlier one. This helps support explain why two records exist without treating them as accidental duplicates. The exact handling depends on the payment product and its documented capabilities, so avoid a universal retry function that ignores the operation type.
Review the complete recovery path
Test the path where an operation succeeds but the response is interrupted, not just the path where the API returns an error. Also consider repeated event delivery and a service restart between receiving an event and completing order fulfilment. These scenarios reveal whether your identifiers describe real business state.
The goal is not to promise that a network never fails. It is to make failures recoverable without guessing and without repeating a financial action blindly. Read the WATADCASH payment, webhook and error documentation together, then document the recovery steps your own team should follow for each enabled service.
Frequently asked questions
Is every repeated request safe automatically?
No. Use the idempotency behaviour documented for the specific operation and preserve the same business intention. Do not assume that every endpoint or every changed payload has the same retry semantics.
Should a timeout immediately create another invoice?
Not without checking the existing operation and following the documented recovery process. A timeout describes a missing response, not necessarily a failed remote operation. Keep the original references so the outcome can be resolved.
Why is webhook deduplication separate?
Webhook deduplication prevents your application from repeating the effect of an event it has already handled. Request idempotency addresses outgoing attempts. A reliable workflow considers both rather than treating one mechanism as a substitute for the other.
Sources and verification
- WATADCASH invoice and payment examplesReviewed 2026-10-18
- WATADCASH webhook handlingReviewed 2026-10-18
- WATADCASH error and retry guideReviewed 2026-10-18
