How Do You Handle Payment Retries and Stuck Payments?

Retries are unavoidable in payments: networks time out, endpoints go down and batch windows are missed. The difference between a resilient integration and a dangerous one is whether retries are safe, deliberate and informed by the actual status of the original attempt.

A stuck payment is one that has been in an interim state longer than expected. Since many South African payment outcomes are asynchronous by design, the first question is always whether a payment is genuinely stuck or simply still within its normal processing window.

When is it safe to retry a payment?

Distinguish between technical failures and business outcomes:

• Safe to retry: connection failures, timeouts before submission was confirmed, HTTP 5xx responses, and rejected requests where the error clearly indicates the instruction was never accepted.
• Retry only after querying: timeouts after submission may mean the instruction was processed even though you never received the response. Query the status by your unique reference before resubmitting, and always reuse the same reference or idempotency key so a duplicate cannot slip through. See idempotency and duplicates.
• Do not blindly retry: validation errors will fail identically every time, and definitive business outcomes such as insufficient funds, account closed or authentication declined are results, not errors. Resubmitting a failed debit order collection is a business decision governed by the mandate, not an automatic technical retry. See collections, tracking and retries for how DebiCheck handles re-presentment.

What does a good retry strategy look like?

• Exponential backoff with jitter: space retries out increasingly, with randomness so a recovering system is not hammered by synchronised retries.
• A retry limit: after a defined number of attempts, stop and raise the item for investigation rather than retrying forever.
• Idempotent submissions: the same key or client reference on every attempt.
• Classification before retry: map the error or reason code to retryable or non-retryable before acting.
• Respect cut-offs: a retry after the processing cut-off may land in the next cycle with a later action date, as covered in cut-off times and value dates.

How do you identify a stuck payment?

Define an expected-outcome window per flow, then alert on anything that exceeds it:

• A DebiCheck real-time authentication still pending well beyond its short window.
• A delayed authentication with no result after end of the next business day.
• A batch file submitted with no acknowledgement file by the expected time.
• A collection with no response or unpaid outcome after the normal cycle.
• A card payment authorised but never captured or settled.

An operations dashboard listing every transaction pending beyond its window, ordered by age, turns stuck payments from month-end surprises into same-day investigations.

How do you investigate a stuck payment?

1. Check your own pipeline first: was the instruction actually submitted, acknowledged and recorded? Logs and audit trails answer this quickly if they are structured well, as described in logging, masking and audit trails.
2. Check for missed events: a webhook may have failed delivery while the payment completed normally. Query the provider's status API by your reference.
3. Check acknowledgement and response files for batch submissions: a missing acknowledgement means the file may never have arrived; a rejection in the acknowledgement explains why nothing followed.
4. Escalate with details: when querying the provider or bank, supply your unique reference, submission timestamp, file name or message ID and the last known status. Precise references shorten investigations dramatically.

What should you never do with a stuck payment?

• Resubmit it without confirming the status of the original.
• Mark it as failed in your system while the rail may still deliver a success.
• Refund a customer for a payment that may still settle, without recording the linkage.

Back to the Payment Operations hub.