Skip to main content

Migrating from V1 to V2

This page provides you with the necessary information to ensure a smooth transition to V2.

fiskaly focuses on a purely cloud-based implementation of the TSE and the entire KassenSichV. This has several advantages:

  • Only one integration is needed - there is no hardware rollout, since everything is software based
  • Software updates are automatic and invisible
  • You always have semi-live access to your data. The data is also always imported in close to real time via the dashboard.
  • Performance is monitored by fiskaly

Here is an overview of the changes. There is also a detailed changelog.

The SDK is replaced by an API#

There is no longer any need to integrate an SDK, since V2 now uses a new API together with a web-based management dashboard, and can be addressed conveniently with a HTTP client of your choice.

Your V1 environment will continue to work during the transition#

While integrating V2, you can continue to use your existing V1 setup. A test environment is available for V2, allowing you to try out certified technical security systems, exports, clients, users, etc.

All API keys and organisations created in the productive environment remain in place and are fully functional. No new organisations need to be created.

To disable a V1 TSS after commissioning the V2, you can perform a PUT request on the V1 TSS with state = "DISABLED".

For a multi-stage rollout, both V1 and V2 integrations can operated in parallel in the cash register. The changeover to V2 can be activated centrally or by the end customer.

Data migration is not necessary#

No manual data migration needs to be carried out. Due to technical and legal requirements, data from V1 can't be transitioned to V2, so all resources will have to be created again using V2.

Your V1 data is retained. Existing transactions and exports will still be accessible from V1 but not from V2, and updating them will not be possible.

You will need to re-register your clients accordingly at the new TSS; data signing will be carried out from there exclusively from that point on.

SMAERS rollouts are managed by fiskaly#

fiskaly operates and manages the operation, rollout and update of the SMAERS server instances. Commissioning, updates, etc. are coordinated with the respective customers.


The most obvious changes to the API concern authentication.

A PIN/PUK is used for initial setup of the Admin user. This is included in the process of creating the first TSS.

The following maintenance operations require administrator authentication:

Other notes#

All POS devices must be registered as clients of the TSS. Multiple clients can (and should) be assigned to a single TSS.

It is strongly recommended to use only one TSS per location. This spares your end-user from having to export, report, and archive data of multiple TSS. From a performance perspective, a single TSS is also preferred, as frequently-used TSS are allocated more resources.

Overview of steps#

To migrate your system to V2, you must deactivate your V1 system, and then carry out some initial requests to set up the Administrator and the first TSS on V2. This should be done using a HTTP client; you cannot use the dashboard.

The following diagram illustrates the process:


This sequence of requests can be integrated into a 'one-click' solution, which does not require any user interaction. The details of the implementation are up to you, the customer.

The next page takes you step by step through an example.

Subscribe to the Dev-Newsletter