Hypersoft procedure for payment terminals
Payment terminals are also called credit card terminals or EC terminals, for example. It is about cashless payment transactions (BZV for short) via corresponding devices. The documentation describes different procedures and possibilities under the heading Hypersoft Pay
Data flow diagrams for payment terminal connections
This chapter refers to the variants described in the chapter Payment in the foreground or background.
Notes on the document obligation and transaction file for the different methods...
In Germany, there is a document requirement. In simple terms, this means that you must offer a receipt for handing over and that the receipt must be produced at the time of settlement. Hypersoft always signs the information in the TSE before a document is created. This means that when you issue a receipt, you can be sure that the data is signed. This is also communicated by the signature on the receipt.
With the integrated optional digital invoice NoCOO - Digital Billing you can digitise the receipt and establish further simplifications. When issuing a NoCOO voucher, the TSE signatures are created first and then the digital invoice voucher.
-
With background payments, the payment is first signed, then the payment receipt is created and then the payment is initiated at the payment terminal. A special feature here is that, unlike usual, the transaction file is retained until the terminal confirms the payment. Only then is the transaction file transferred to the booking journal. If the payment cannot be made, the transaction remains "still open" and can be called up again for payment. When this happens (i.e. when the transaction is opened again), offsetting entries are then created in the TSE and in the Hypersoft payment journal for the non-cash payment that has not been completed.
-
With payment in the foreground, the payment is first transmitted to the payment terminal and the POS system waits for the status of the payment order. If the cashless payment is not made, the transaction remains open. If the payment is made, the entries and the payment are signed and the payment voucher is created. If the payment transaction is cancelled at the payment terminal, the open transaction remains in the POS.
Depending on the workflow and the interpretation of the document requirement, a payment request to the customer without prior signing and document creation may not meet the legal requirements. Coordinate the use of the payment in the foreground with your tax advisor and note it in your procedure description (in lived practice in Germany, payments in the foreground are also used as standard in other sectors).
Further documentation: Accounting journal, logic and filing from a fiscal point of view
Data flow diagram for cashless payment in the foreground...
The cash registers create a request file for the payment terminal selected at the POS and wait for the payment confirmation by the BZV APP. Further use of the cash register through which a payment was requested is blocked until the payment is completed and cannot be operated.
-
The BZV APP responds to the request file (File Watcher) and executes the payment.
-
The payment processing is carried out optionally, or depending on the system, via TCP / serial.
-
The BZV APP writes the result to the In / Out directory.
-
The cash register that requested the payment reacts to the result file (File Watcher) and evaluates it.
-
After successful payment, the transaction is transferred from the cash register via Business Logic Hypersoft Business Logic is a program for performing tasks that are assigned to the accounting journal by cash register systems and other modules. to the Hypersoft database and the cash register is unlocked.
-
If the payment is unsuccessful, a message is displayed at the checkout indicating why the payment was unsuccessful. The process remains open and must be repeated. The cash register is unlocked.
Data flow diagram for BZV payment in the background...
Data flow diagram for BZV payment - the cash register waits in the background for a payment confirmation and can continue working in front.
-
The cash registers create a request file for the payment terminal selected at the POS.
-
The BZV APP responds to the request file (File Watcher).
-
The payment processing is carried out optionally or, depending on the system, via TCP / serial.
-
After successful payment, the transaction is transferred to the Hypersoft database via Business Logic Hypersoft Business Logic is a program for performing tasks that are assigned to the accounting journal by cash register systems and other modules..
Data flow diagram for BZV payment - the cash register waits in the background for a payment confirmation and the operator can continue to work in cashier mode (no lock).
-
The Cash registers create a request file for the payment terminal selected at the POS.
-
The BZV APP responds to the request file (File Watcher) and executes the payment.
-
The payment processing is carried out optionally or, depending on the system, via TCP / serial.
-
The BZV-APP writes the result to the In / Out directory.
-
The BZV APP reacts to the result file (File Watcher) and evaluates it.
-
After successful payment, the transaction is transferred from the BZV APP via the Business Logic Hypersoft Business Logic is a program for performing tasks that are assigned to the accounting journal by cash register systems and other modules. into the Hypersoft database.
-
If the payment is unsuccessful, a message is displayed at the checkout indicating why the payment was unsuccessful. The process remains open and must be repeated.
Flowchart Hypersoft Pay powered by Adyen Pay @ Table (older procedure with mobile Verifone terminals from Adyen)...
Special feature Correction in case of disconnection with Adyen...
Further documentation: Communication security between Adyen and Hypersoft
Special feature for cashless multiple payments...
If a transaction at the cash register or mobile device has been split into several payments (for example 3 payments) and a cancellation occurs during the first or second payment, the last payment checked in the transaction is completed and a message appears for the operator at the cash register or mobile device where the payment was initiated. The message alerts him to the fact that there are other outstanding payments for this transaction:
In this case, the process must be opened again in order to execute the further payment(s).
The partial payment (split) at the Adyen terminal directly (only at Adyen!) is different; here the payment is also checked after a cancellation and completed if necessary. The special feature, however, is that the next payment (if available) is also resumed and continued at the terminal.
Further documentation: Payment terminals with the POS
Back to the parent page: Fiscal Law on the Application Decree on Section 146a AO