Skip to main content

Integration into the POS system


Sign API v2#

The SDK is no longer necessary for API v2. Integrators are recommended to use any HTTP client of their choice. Details about API v2 are contained in the developer documentation and API Notes.

API v1 and earlier#

The system integrator should select the SDK that is appropriate for the POS system. For example, for a POS system implemented in Java, the Java SDK must be selected.

Technical requirements#

Response times50 - 250ms, depending on the network latency
Process flowAsynchronous. Start and update transactions therefore do not cause a delay in the recording system. Waiting for a response is required only for a Finish transaction.
Service functionsIdempotent. A process can be repeated as often as required. However, the expected side effect occurs only once.
Simultaneously opened transactions per TSSunlimited
Supported operating systemsLinux, Windows, etc. (platform independent)

Data volume for a transaction#

The data volume for a transaction depends on the payload to be signed, but it is very low across the board.

Assuming an absolute minimum of data to be secured, the data volume per transaction is << 1 kilobyte. If a larger volume of data needs to be secured, for example, to completely record POSLog transactions, the data volume also increases. The maximum amount of data that can be backed up is theoretically unlimited.

The complete protection of POSLog transactions has the advantage that other services such as archiving or accounting can process the transaction data.

Example of a payload: Minimum data of the attribute processData for a processType "cash voucher" according to the field specification of DSFinV-K Beleg^123.45_67.89_0.00_0.00_0.00^111.11:Bar_80.23:Unbar. It can be assumed that 1 kB - 256 kB of data are transferred per transaction, depending on whether it is a cash voucher, a purchase order (long-lasting transaction) or another transaction.

Due to our asynchronous architecture, the bandwidth can be very low, e.g., comparable to ISDN. To complete a transaction, however, you must wait for our system to respond. Here, the network latency is the limiting factor, since the data to be transmitted takes up a minimal volume.

Response times#

The response times of the fiskaly cloud are significantly influenced by the latency of the network connection. Within the fiskaly cloud, response times average 64 ms in our test system for KassenSichV. Please note that the test system is not yet optimized for performance. Response times of less than 50 ms can be expected in our production system.

Postman Worfklow and Performance (Screenshot of a fiskaly Cloud-TSS test run)

The latency of the network connection of the integrator to the data centers of the fiskaly cloud must be taken into account. The current location of the fiskaly cloud infrastructure is Frankfurt am Main (redundant). Further locations can be provided if required, for example in Düsseldorf and Munich.

Simultaneously opened transactions#

The number of simultaneously opened transactions per TSS is not limited in the fiskaly cloud. Any number of transactions can be kept open.

Subscribe to the Dev-Newsletter