Timeout Processes
Timeouts and You
All transactional events over the internet have the potential to fail due to network conditions and subsequently timeout. When dealing with payment cards and live traffic, this is particularly troublesome and — if handled incorrectly — an operational pain point.
This article provides a guide on how the platform handles timeouts and how you, as an integrator, should consider timeouts in your design.
What Happens When a Timeout Is Received?
With the approach outlined in this article, nothing is required from you. The merchant or integrator can treat the transaction as a failed transaction and immediately retry. The platform will handle the back-office processing and work to prevent any double charges. Should there be any issue with this process, Connected Payments will reach out to make you aware and resolve it directly.
More Information
Timeout Definition
Within the platform, a timeout is defined as any transaction where an adequate response is not received within the pre-defined timeout period (currently 60 seconds).
Once a timeout has occurred, a transactional record will be created with all associated transactional data and one of the following response codes:
| Response Code | Description |
|---|---|
99 | Standard timeout |
797 | Timeout variant |
798 | Unknown exception (timeout-like) |
799 | Unknown exception (timeout-like) |
Causes
A traditional timeout is caused by the lack of a response from a downstream gateway or link within the pre-defined timeout period. This may result from:
- No response within the timeout period
- Partial response within the timeout period
- Unintelligible response within the timeout period
All causes above are defined as a "gateway timeout" as an intelligible response was not received within the pre-defined period.
Transactional State
When a timeout occurs, one of 3 transactional states may be found within the downstream service's records:
| State | Description |
|---|---|
| Approved | Transaction was approved downstream before the timeout was recorded |
| Declined | Transaction was declined downstream |
| No Record | No downstream transactional record found |
In all cases, the platform will look to handle these events to the best of its ability to allow for re-processing without the risk of double charges.
How We Fix a Timeout
Once a timeout occurs, it is added to the Connected Payments timeout queue. Within this queue, each timeout will be queried and a reversal submitted on repeat until one of the following events occurs:
- Settlement date for the original transaction passes
- Retry attempts are exhausted
- The transaction is confirmed as declined
- The transaction is successfully voided
Each retry attempt begins with a query of the originally timed-out transaction:
- If the query reveals the transaction is declined or approved but voided/cancelled, no further attempts are made
- If the transaction is found in an approved state, a void request is sent to cancel it and prevent any financial action from taking place