Read and Connection Timeout Handling

on Jun30
connection timeout
Written by
James Davis
Written by James Davis
Senior Technical Writer at United Thinkers
Author of the Paylosophy blog, a veteran writer, and a stock analyst with extensive knowledge and experience in the financial services industry that allows me to cover the latest payment industry news, developments, and insights. Read more
connection timeout
Reviewed by
Kathrine Pensatori
Product Specialist at United Thinkers
Product specialist with more than 10 years of experience in the Payment Processing Industry. I help payment facilitators and PSPs solve their various payment processing issues. Read more

The purpose of this article is to familiarize merchant services industry players with such concepts as read timeout and connection timeout. We will address 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.

Different kinds of errors are addressed in our respective articles on this blog. For instance we can recommend the articles on transaction decline and ACH return codes.

The second 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 or connection timeout’ and ‘read timeout’.

The key differences are as follows.

Connection timeout

Connection timeout usually occurs within 5 seconds. The 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’.


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).


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.

To learn more about how payments work feel free to consult our specialists at UniPay Gateway and download a free white paper on the fundamentals of payment processing

Recommended to you

Previous postPINless Debit Card Networks Next post3D Secure Program

Copyright© 2024, United Thinkers