Terminal loses interface

See the description of causes and solutions in the The full-service time-out trap section.

Mobile POS or EFT terminal (WLAN) loses interface

The Hypersoft POS solution offers unique functionality for the operation of POS or EFT terminals (i.F. POS terminals) within a WLAN. See Hypersoft Pay powered by Adyen or all solutions at Hypersoft Pay.

If the checkout station loses the connection to the POS terminal during a transaction, a so-called time-out occurs on your side. In this situation, the pay station does not know whether the transaction was successful in the data center or not. It is therefore urgently necessary to check the retailer document POS terminals. Under certain circumstances, a WLAN failure only affected the POS station, but not the POS terminal, so that the POS terminal could carry out the transaction but not inform the POS.

In order to inform the operator about the occurrence of a communication interruption between the POS station and the POS terminal, a dialog appears on the corresponding POS station.

For security reasons, a receipt is also created on the printer provided for this purpose.

The transaction, which was originally intended to be completed with the help of cashless payment transactions, is marked in blue and parked. It can be called up again and concluded again with the same or a different payment type.

If a parked transaction is subsequently completed due to a communication interruption between the POS terminal and the POS station BAR, a security note appears which is intended to make it clear to the operator that an attempt has been made to complete this transaction with a cashless payment. In this case, the operator should always check whether the POS terminal has made the payment. There is a danger of the transaction being settled twice.

elPAY Adjustment posting

If you select such an operation, the multi-payment starts automatically.

Before you continue, please check whether the merchant receipt (from the terminal) states that the cashless payment has been made.

For this exception an additional key with the name elPAY correctionis offered. If the cashless payment by tip is higher, you can bookthe tip directly in the multi-payment - but before the transaction is completed.

When corrected, the transaction is completed without a new payment request to the terminal with the selected payment method. When activating the elPAY correction, the previously known elPAY payment methods are offered, so that you can choose, for example, between ec International, Diners, Visa, Amex, Mastercard and MAESTRO.

The transaction can now be booked by you by simply selecting the correct key (we required congruent).

Further correction

If you have made a mistake with the correction described above, you can return to the multi-payment dialog using the Edit transaction and Change payment method function.

This new correction is only possible for operations that were canceled and corrected manually as described above. Normal cashless payments still require the re-reading of the card.

In this context, note the control of payments to prevent manipulation. Review your reports on a timely and regular basis and reconcile incoming payments from data centers.

reporting

To enable you to track elPAY correction postings, these are not only listed together with the other payments in the operator settlement, but are also listed separately again.

Payment type report (No. 22)...

Financial Report (Report 11)...

Further reports on this can be found in the Report Manager.

Alternative possibilities

From our point of view, manual target-oriented locking is the best solution. But there are other possibilities to make corrections before the closing of the day:

  • For example, create a payment type "BZV unclear" to quickly post such transactions.
  • Or you disconnect the terminal from the cash register (setting in the terminal), then cancel the payment with the terminal, then reconnect the terminal with the cash register and repeat the cashless payment.

Administrators and Installers BZV Connection Verification

The interface to the EC terminals is ensured by optimized algorithms. If you experience any problems, you can use this note:

  1. The interface is checked before the transaction file (IN file) is processed. If this exists, the transaction is executed. The same applies if the interface is re-established within the cash register processing time (timeout of 3 minutes by default).
  2. The interface check takes place in idle mode every 15 seconds, whereby a ping to the IP address is executed first. If the ping is successful, an additional interface to the port of the EC terminal is established.
  3. If both checks are successful, then a "Connect" is reported, but if one of the two checks is missing, then "Disconnect" for the terminal is displayed in the client window. After a successful "re-connect", this is also repeated if there is no terminal login.

The log files in the BZV-ZVT directory (ZVT, TRN, CSV) contain an additional ".TCP" file in which the network errors are logged.

Example 1...

BZVExtTerm.exe is started but the terminal is not ready. No IP address is displayed and "Disconnect" is highlighted in red. "CL" stands for "Connection lost" and counts 1 higher for each further check (15 seconds). With a "Connect" this goes back to "0".

Example 2...

Terminal is connected, IP address is displayed, "CL" is set to "0" and "Connect" is displayed with a green background. This state occurs after a "Connect" or "Reconnect".

Example 3...

Intermediate disconnection (terminal out of range, battery empty, etc.). The IP address is displayed, but the terminal displays "Disconnect" until the interface is restored.

Example 4...

Current interface check. During a interface check, the background of "Disconnect" or "Connect" is displayed in orange.

Example 5...

The additional log file (for example 20190826_Term0001.TCP).

Back to the parent page: Payment terminals with the POS