The purpose of this article is to familiarize merchant services industry players with the mechanisms implemented in payment gateway software for the cases when transaction processing becomes impossible due to temporary loss of connection with the “back end” (for instance, a bank) or due to some other errors.
Problems with transaction processing might be caused by one of the two conceptually different reasons: timeouts and errors.
The first potential reason is a so-called timeout. Essentially, timeout means that there is a connection problem.
There are two types of timeouts sometimes referred to as ‘socket timeout (or connection timeout)’ and ‘read timeout’.
The key differences are as follows.
Connection timeout
Connection timeout usually occurs within 5 seconds. Connection timeout indicates that connection with the back end is impossible, and the server, to which the data needs to be transferred, cannot be reached. Issues with connection can be caused by DNS problems, server failure, Firewall rules blocking specific port, or some other reasons. In such cases the, a backup (or secondary) URL can be used (if available). If no connection can be established through either URL of a given service, further processing of transactions is impossible. It is important to note that no information is communicated to the host server when connection timeout occurs.
Read timeout
Read timeout usually occurs within 40 to 60 seconds. Read timeout occurs when the socket is open, connection to the host server is established, the request is sent, but the response from the server is not received on time, and cannot be read. Since the authorization request has already been sent, the transaction may have been processed (and approved), but, possibly, some error has occurred on the way back from the host server. As there is no clear response, there is a risk of charging the customer for the second time (if transaction is reattempted).
There are two approaches that are used by integrators to deal with situations like the one described above. These approaches are, generally, referred to as ‘authorization and capture’ (explicit or implicit capture) and ‘timeout reversal’.
Authorization-and-capture
The basic premise of authorization-and-capture approach is that any authorization processed has to be subsequently captured (confirmed) by an additional request. If timeout occurs, the submitting system does not send out the confirmation (since it never got the response), and, consequently, the host system reverses the authorization (because it has not been confirmed).
The capture operation can be executed in one of two ways: explicitly or implicitly. In case of explicit capture a separate ‘capture’ request is sent to the host server to confirm a previously successful authorization. In case of implicit capture, the reference number of the previously successful authorization that needs to be captured, is included as part of the subsequent authorization, or as part of the final settlement call.
In other words, in case of explicit capture the authorization request is submitted as one message and capture is sent as another separate message, while in case of implicit capture, authorization request is submitted as one message, while capture message (reference number of the successful authorization) is included in the authorization request of the next transaction. The final (end-of-the-day) message includes reference number of the last transaction which needs to be captured (confirmed).
Implicit capture is not recommended when time-initiated host capture is used.
Timeout reversal
Another approach is to explicitly reverse transaction with a host if a timeout has occurred. When a read timeout occurs, one or more attempts to reverse (or ‘void’) the authorization that timed out is made. When a transaction is submitted, and timeout occurs, it is assumed that the problem is temporary. In some cases up to three reversal attempts are made, each 40 seconds apart. It is assumed that within the next 160 seconds (40 seconds – initial waiting, plus 3 reversals) the problem of connection with the server will be resolved. If authorization is successful, subsequent reversals will void it (so that the customer will not be accidentally charged).
Conclusions
When a company integrates with some payment system (especially, if it plans to submit large transaction volumes in real time), it needs to consider and test the system’s processing strategy, keeping in mind the issues, related to read and connection timeouts.
Recommended to you
