During transaction processing, a disconnect may occur for the following reasons:
- Connection timeout (error code E12) - the cloud doesn't receive a response from the terminal within 5 minutes while processing the transaction.
- The terminal is unreachable (error code E22) - the connectivity issues between the terminal and the cloud may occur in the following cases:
1) The terminal was disconnected when the cloud was attempting to send a message to the terminal.
2) The channel between the terminal and cloud is inactive during a time period specified as one-minute timeout due to a bad connection.
3) The terminal disconnected and reregistered while processing the transaction (occurs when the terminal submits repeated registration request without interrupting the connection with cloud established before).
When using the HTTPS protocol, which is used in the communication architecture between a POS system and the gateway, the gateway cannot determine whether the disconnect has occurred. Thus, when the POS submits a request to the gateway, the gateway cannot determine that the connection has failed, and the POS has been disconnected. Therefore, in some cases, the transaction response may not be delivered to the final recipient, i.e. to the POS. In such cases, there is a possibility that the transaction has been approved but the gateway has marked it as a decline due to the disconnect.
If you look at the Transaction Processing Flow for Cloud
diagram, you can see the following communication areas, which use the HTTPS protocol:
- area between a POS and cloud;
- area between a terminal and the gateway;
- area between the gateway and a processor.
In these areas, the following instances are responsible for identifying if a disconnect is present:
- area between a POS and cloud - the POS;
- area between a terminal and the gateway - the terminal;
- area between the gateway and a processor - the gateway.
If there is a disconnect, responsible instances must execute the void operation. In the first case, when the POS is the responsible instance, make sure that the void is executed by the POS. In the second and third cases, when the terminal or the gateway is responsible correspondingly, the void is executed automatically.
Note that when a terminal is disconnected from the gateway after a transaction request has been submitted, the terminal attempts to make a void on the transaction up to three times. If the connection is not restored, no void is made. Therefore, we recommend the POS to make three void attempts to ensure that the transaction is processed, the result is obtained, and the original transaction does not remain within the gateway.