Interfaces

Integration into the POS system

The integration of the TSS into a POS system is done via a SDK (Software Development Kit).

An SDK represents a programming interface for a concrete programming language or runtime environment. Consequently, the system integrator selects the SDK that is suitable for the respective POS system in order to integrate the functionality of the TSS (example: for a POS system implemented in Java, the Java SDK must be selected).

Since an SDK is always specific to a particular programming language, fiskaly will provide several reference implementations for the most common languages and runtime environments open source at github.com/fiskaly. Due to the permissive MIT license, the SDKs can be modified, extended and distributed at will.

Conceptually, an SDK represents an HTTP client, which was explicitly optimized for communication with our REST API (KassenSichV-API). In the first stage the SDK provides the following functionalities:

  • All concerns around authentication, i.e. the collection as well as the regular and in case of error necessary renewal of the JWT Authentication Token required for the communication with our REST API is completely abstracted. In concrete terms, this means that the integrator only has to specify an API key and the corresponding API secret.
  • n case of server errors on the part of our REST API as well as possible connection problems (e.g. timeout), the SDK uses the idempotency property of our REST API to send the failed requests (including "exponential backoff") again or to trigger appropriate compensation mechanisms.
  • Serializing and deserializing the requests and responses into the used JSON format happens automatically.
  • In case of offline scenarios (i.e. branch is offline or the fiskaly REST API is offline) the SDK takes care automatically and autonomously (i.e. no manual intervention is necessary) of the logging of the facts as provided for in the application decree to § 146a AO in this situation and now regulated. This includes the local persistence and subsequent transfer or synchronization of the offline persisted logs to the fiskaly REST API. This means that all logged faults are also stored centrally at a later point in time (as soon as the system is back online) and can thus be read out again from a central location in a traceable manner.
  • Conformity with the requirements of BSI CC-PP-0105-2019 The Protection Profile specified by BSI requires that a local SMA component executed in the operational environment of the POS system takes over the incrementation of the transaction counter and the establishment of the trusted channel to the remotely connected CSP component. The task of the SDK is to address the SMA component, which is available in binary or executable form, and to abstract the use of the required functionality as completely as possible for the user of the SDK (=developer).

Github overview

Last updated on