Network Timeout Decline
A network timeout decline occurs when the communication between the payment processor and the issuing bank fails to complete within the allotted time. The transaction wasn't actually declined by the bank — the message never got through or the response never came back. This is a soft decline with one of the highest recovery rates (95%+) because the issue is entirely infrastructure-related and has nothing to do with the customer's card or account.
Affected Percentage
~5% of all declines
Recovery Rate
95%+ recoverable
Recommended Action
Retry with strategy
Common Causes
Issuer bank server overload
The issuing bank's servers are under heavy load (often during peak shopping periods like Black Friday) and can't respond before the connection times out.
Network routing issues
The transaction data takes a complex path through multiple intermediaries (payment processor, card network, acquiring bank, issuing bank). A bottleneck at any hop can cause a timeout.
Regional infrastructure outages
Localized internet or telecommunications outages in the region where the issuing bank is located can prevent transactions from completing.
Payment processor rate limiting
If you're processing a high volume of transactions simultaneously, the payment processor or card network may throttle connections, causing some to time out.
Recommended Retry Strategy
Timing
Retry immediately or after 15-30 minutes. If that fails, retry again after 2-4 hours. Infrastructure issues are usually resolved within hours.
Max Retries
3-4 retries within 24 hours
Reasoning
Network timeouts are transient infrastructure problems. They almost always resolve quickly. Retrying within minutes or hours has an extremely high success rate because you're simply waiting for the network to recover.
Best Practices
- 1
Retry quickly — unlike other soft declines, network timeouts benefit from immediate or near-immediate retries since the issue is infrastructure, not financial.
- 2
Check the payment processor's status page before retrying. If there's a known outage, wait for the all-clear rather than burning through retry attempts.
- 3
Implement exponential backoff: first retry after 5 minutes, second after 30 minutes, third after 2 hours.
- 4
Monitor for patterns — if you see a spike in network timeouts, it likely indicates a widespread infrastructure issue. Pause retries and wait for resolution.
- 5
Never notify the customer about a network timeout. This is not their problem and contacting them would cause unnecessary confusion.
How Rezoki Handles This Automatically
Rezoki identifies network timeout declines as infrastructure issues and applies a rapid retry schedule rather than the longer dunning-style timing used for other soft declines. The first retry fires within 15 minutes, followed by retries at 1 hour and 4 hours if needed. Rezoki also monitors for timeout patterns across your customer base — if many transactions are timing out simultaneously, it recognizes a systemic issue and intelligently pauses retries until the infrastructure recovers, then bulk-retries all affected transactions. No customer communication is triggered for network timeouts.