---

Connection lost link

In the case of a connection issue it’s possible to miss a transaction response from the terminal. It’s very important to be able to retrieve this response to avoid causing financial loss or reputational damage for your merchants.

Depending on the type of call (Synchronous vs. Asynchronous) the risks and remedies are slightly different. More on the individual connection models here.

Every time you make a call to the terminal you should expect a response of some kind. If for any reason that response is never returned you can assume there was a connection issue. One way of doing this is to keep some sort of “open” flag in your journal, and whenever a response is returned you “close” that flag. Before starting a new operation always check if you have open flags, this should help you get ahead of problems like these.

Synchronous link

This connection type is most at-risk to be affected by connection drops as it holds the connection open for the entirety of the transaction lifecycle. Once an operation has been initiated in the terminal, it can be finalized without the ECR’s involvement, meaning if your application is disconnected by the time the response is returned it will be lost.

Calling the /latest endpoint will return the response of the last operation of that type. You can then compare the response with known values to make sure it is the same response that you are missing. One way this can be done is to supply CustomData in your requests containing a unique identifier for each operation, that way when the response is returned you can compare these identifiers. Please note that /latest does not take transactionOutcome into consideration, it will return the last operation regardless if it was approved or denied.

Asynchronous link

While the risk is greatly reduced due to the nature of this model it’s still possible that an individual call is dropped. Most of the time you can get away by just calling {operationType}/{operationId}/status again and the terminal will re-send the response. However if terminal is restarted for whatever reason then status will be unavailable and you will need to use the /latest endpoint like during Synchronous operation.

Certification link

During certification we will make sure that your application handles this. The intention of the test case is for you to explain what steps you take in your application to recover from this.

Consider the following scenario:

A payment is initiated successfully. The ECR is disconnected before a response is returned. The cardholder finalizes the transaction in the terminal. No receipt is printed.

How does the operator proceed? If they attempt to process the transaction again without verifying the outcome they risk debiting the cardholder twice.

To pass the test case take the following statements into consideration and fill in the blanks, or if they do not apply please state your own explanation.

1. The application knows that there was a connection issue because …
2. The application informs the operator of the following …
3. The application then attempts to recover the missing receipt by …
4. Returned receipt has it’s outcome validated to make sure if it was approved or denied
5. Receipt is printed or payment is reversed if customer chose another payment method.