Why duplicates happen
Most duplicate payouts come from a single misreading: a request that times out is assumed to have failed. In reality a timeout means the outcome is unknown. The transfer may have been accepted and may already be in flight.
The rest usually come from an operator re-uploading a batch after a partial error, or from two people processing the same approval queue without a lock.
Use an idempotency key on every transfer
Generate a unique key for each intended payout and send it with the request. If the same key is retried, the provider returns the original result rather than creating a second transfer. This is the single most effective control available.
Derive the key from something stable and specific, such as the invoice or payout-batch line identifier, rather than a timestamp. A key that changes on retry provides no protection.
Query status before retrying
After a timeout or an ambiguous error, query the transfer using your own reference before doing anything else. Retry only when the provider confirms the transfer does not exist or has reached a final failed state.
Treat pending as pending. A pending transfer that is retried is the classic duplicate.
- Timeout or unclear error, so the outcome is unknown.
- Query by your own unique reference.
- Final failure confirmed, so retry with the same idempotency key.
- Success or pending, so do not retry; record and monitor.
Add controls around the batch
Separate batch preparation from batch approval so one person cannot both create and release a payment. Lock a batch once it is submitted so it cannot be uploaded again. Validate the file for repeated beneficiary and amount combinations before release.
Reconcile daily against the provider's report rather than your own submission log, since only their record shows what actually moved.
If a duplicate does go out
Act quickly, but understand the constraint: a successful bank transfer generally cannot be unilaterally recalled. Recovery depends on the beneficiary agreeing to return the funds, or on a recall request the partner may be able to attempt.
Document the reference, the timeline and the cause, then fix the control that failed. Prevention is far cheaper than recovery here.
Key takeaways
- A timeout means unknown, not failed.
- Send a stable idempotency key with every transfer request.
- Always query final status before retrying.
- Use maker-checker separation and lock submitted batches.
This article is general information and not financial, legal or tax advice. DIGIWAY PAYMENT PRIVATE LIMITED provides financial-technology, onboarding and integration support. Payment, banking and other regulated services are delivered by the relevant authorised service partner, subject to eligibility, KYC, risk review and applicable terms.