Choosing a Middleware Architecture
After reading this, you can decide where the fiskaltrust.Middleware runs for your POS system, which signature device it uses, and what each choice means for operation, maintenance and market rollout.
Your integration of the fiskaltrust.Middleware API is the same for every architecture. What changes is where the Middleware runs and where the signature is created. Make this decision before you set up your first CashBox, because it determines which platform you install on, which products your PosDealers order, and how your POS system reaches the Middleware.
Four questions decide the architecture:
- Which operating system does the POS system run on?
- Does the market require an additional signature device?
- Is the signature device hardware-based or software-based (cloud)?
- Does the Middleware run locally or in the cloud, and what are the consequences?
Building blocks
Every architecture uses the same components. For details, see Middleware Components.
| Component | What it does |
|---|---|
| CashBox | The configuration container in the fiskaltrust.Portal. It links one or more Queues and SCUs into one Middleware configuration. |
| Queue | The receipt chain. The POS system sends its requests to the Queue, which numbers, chains and stores the receipts. |
| SCU (Signature Creation Unit) | The component that connects the Queue to the market-specific signature device or service, for example a TSE in Germany. |
| Signature device | The hardware device, cloud service or certificate that creates the signature required by the market. In some markets, no separate device is needed. |
| Launcher | The program that starts the CashBox on a local device (Windows, Linux, macOS or Android). A Middleware hosted by fiskaltrust needs no Launcher. |
Table 1. Components that make up every Middleware architecture.
The three architecture models
Local: Middleware and signature device on site
The Launcher runs on the POS device or on a server at the location. The CashBox with the Queue and the SCU runs there, and the SCU talks to a signature device that is also on site, for example a hardware TSE on a USB port or microSD card.
Figure 1. Local model: Middleware and signature device run at the location.
- Signing does not depend on an internet connection, so the POS system can keep fiscalizing while offline. An internet connection is still recommended for configuration, updates and data services.
- The fiskaltrust.Middleware itself is free of charge and open source.
- You or your PosDealers install, update and maintain the Launcher and the signature device on every site.
Hybrid: Middleware on site, signature in the cloud
The Launcher and the CashBox run on site as in the local model, but the SCU connects to a cloud signature service instead of a hardware device, for example a cloud TSE in Germany.
Figure 2. Hybrid model: local Middleware with a cloud signature service.
- No signature hardware has to be shipped, plugged in or replaced.
- Signing needs an internet connection. If the signature service cannot be reached, the Middleware switches to failed mode. Whether the POS system may continue to issue receipts in this state depends on the market. For more information, see Failure Scenarios and the pages of your market.
- You still install and maintain the Launcher on every site.
Cloud: Middleware hosted by fiskaltrust
fiskaltrust hosts the CashBox, including the Queue and the SCU, as the CloudCashbox. The POS system reaches the Middleware via a URL and authenticates with the CashBox ID and access token. No Middleware is installed at the location. In some markets, the SCU still connects to a signature device on site, for example an RT printer or RT server in Italy.
Figure 3. Cloud model: the CloudCashbox hosted by fiskaltrust.
- No Middleware installation and no Launcher on site. fiskaltrust operates and updates the Middleware.
- Every request needs an internet connection. What the POS system may do while the Middleware cannot be reached depends on the market: in some markets it re-sends the receipts later in late-signing mode, in others it cannot issue a fiscal receipt until the connection is back, for example in Spain. For more information, see When the fiskaltrust.Middleware is not reachable and the pages of your market.
- The CloudCashbox is a paid product, while the locally installed Middleware is free of charge.
- The CloudCashbox is fiskaltrust's target architecture. Some features are only available with it, for example eInvoicing. For more information, see eInvoicing — Overview.
For more information, see CloudCashbox.
If your POS system runs in your own data center and you need the Middleware there, Germany also offers Bring your own Data Center (Docker and Helm chart). fiskaltrust recommends the CloudCashbox over this setup. For more information, see Custom data center.
Comparison
Where the Middleware runs and which signature device it uses are separate choices. The market decides which combinations are possible; see Availability by market.
| Local | Hybrid | Cloud | |
|---|---|---|---|
| Where the Middleware runs | POS device or local server | POS device or local server | fiskaltrust cloud |
| Signature device | Hardware on site, or none where the market requires no device | Cloud service | Depends on the market: managed by fiskaltrust, or a device on site (for example an RT printer or RT server in Italy) |
| Installation on site | Launcher, and signature hardware where required | Launcher | None, except a signature device where the market requires one on site |
| Internet for signing | Not required | Required | Required |
| Updates | Through the Launcher on each site; on Android through an app update | Through the Launcher on each site; on Android through an app update | Done by fiskaltrust |
| Middleware cost | Free of charge | Free of charge | Paid product (CloudCashbox) |
| Features only in the cloud | Not available, for example eInvoicing | Not available, for example eInvoicing | Available |
Table 2. Comparison of the three architecture models.
SCU models
Independently of where the Queue runs, you decide where the SCU runs and how many Queues use it.
Local or managed SCU
- Local SCU: The SCU runs in a CashBox that you operate, usually together with the Queue on the POS device or on a local server. It connects to the signature device, either a hardware device on site (local model) or a cloud signature service (hybrid model). You configure the connection in the SCU, for example the drive of a hardware TSE or the credentials of a cloud TSE.
- Managed SCU: fiskaltrust operates the SCU as a signing service, for example the Austrian signing service at
signing.fiskaltrust.at. The Middleware reaches it over the internet. You install and configure no SCU and no signature device yourself.
Figure 4. Managed SCU: the Queue uses a signing service operated by fiskaltrust.
Dedicated or shared SCU
- Dedicated SCU: Each Queue has its own SCU and signature device. This is the simplest and most reliable setup: a failing SCU affects one Queue only. You need one signature device per Queue.
- Shared SCU: Several Queues use the same SCU. The Queues can run in the same CashBox, or in several Middleware instances that reach the SCU over the network, for example several POS devices that use one SCU on a back-office server. You need fewer signature devices, but the shared SCU becomes a single point of failure and a possible performance bottleneck, and the network between the instances has to be set up and maintained.
Figure 5. Shared SCU: two Middleware instances use one SCU on a local server.
Sharing an SCU has limits:
- An SCU and its signature device can only be shared within one location, never between locations.
- The signature device limits the number of Queues. Some German cloud TSEs accept only one Queue and cannot be shared at all. For the limit of each device, see the SCU/characteristics & platform support matrix for Germany.
- Sharing one external signature service between several CashBoxes is only available with cloud signing in Austria or with the fiskaly cloud TSE in Germany.
- In Germany, only on-premise fiskaltrust.Middleware instances can share a TSE. A CloudCashBox needs its own TSE per installation. For more information, see fiskaltrust.Middleware, terminals and the TSE.
| Dedicated | Shared | |
|---|---|---|
| Local SCU | One SCU and signature device per Queue, on the same device as the Queue. Simplest setup, no network dependency between devices. | One SCU and signature device for several Queues of a location, for example on a back-office server or the main POS device. Fewer devices, but a single point of failure. |
| Managed SCU | A signing service operated by fiskaltrust, used by one Queue. Nothing to install, but needs internet. | A signing service operated by fiskaltrust, used by several Queues. Nothing to install, but needs internet, and the market must allow sharing the service. |
Table 3. SCU models by location and sharing.
For example layouts of dedicated and shared SCUs with pros and cons, see Rollout Scenarios.
Decision factors
1. Operating system
The operating system of the POS device decides whether a local Launcher can run on it at all.
- Windows: Launcher available in every market that supports a local Middleware.
- Linux and macOS: Launcher available, but with restrictions per market and signature device. For example, SOAP/WCF is not available, and some German cloud TSEs support only specific Linux distributions.
- Android: Android Launcher available in some markets only, with a fixed set of preconfigured signature devices. Queue and SCU versions are bundled into the app, so updates are rolled out as app updates, ideally through a mobile device management solution.
- iOS, web browsers or any other platform: no local Launcher. Use the cloud model.
For more information, see Supported Environments and Launcher for Android.
2. Is an additional signature device needed?
The market decides this, not you:
- A signature device is required in some markets, for example a TSE in Germany, a smart card or online signing service in Austria, an RT printer or RT server in Italy, or a fiscal printer in Poland.
- No separate device is required in other markets, for example France, Spain, Greece and Portugal. The signature is created with a certificate or key managed by the Middleware or by fiskaltrust.
See Availability by market for each market.
3. Hardware or cloud signature device
Where a signature device is required, the type limits your options:
| Hardware device | Cloud service | |
|---|---|---|
| Examples | Hardware TSE (USB, SD, microSD) in Germany, smart card in Austria, RT printer or RT server in Italy | Cloud TSE in Germany, online signing in Austria |
| Fits architecture | Local; in Italy also cloud (RT printer or RT server) | Hybrid or cloud |
| Works offline | Yes | No |
| On site | Device must be connected, protected and replaced when defective | Nothing to install |
| Sharing | One device can serve several Queues in the same location, up to the device limit | Depends on the service; some cloud TSEs accept only one Queue |
| Platform | Needs a supported port and driver on the device | Needs network access; some services need an additional local component |
Table 4. Hardware compared with cloud signature devices.
Check the limits of each device before you decide. For Germany, see the SCU/characteristics & platform support matrix. For Italy, see the SCU/characteristics & platform support matrix.
4. Local or cloud Middleware
Ask yourself the following questions:
- Must the POS system keep fiscalizing without internet? Only the local model with a hardware signature device signs without a connection.
- Is the POS system itself cloud-based? If your POS system already depends on the internet, the cloud model adds no new dependency and removes all on-site installation.
- Who maintains the sites? Every local or hybrid installation has to be installed, updated and monitored. With the cloud model, fiskaltrust does this.
- Which features do you need? Features such as eInvoicing are only available with the CloudCashbox.
- Which API do you integrate? The POS System API is available in the cloud in every market. A local POS System API needs Launcher 2.0 and the LocalPosSystemApi Helper, which is not available in every market. For more information, see POS System API platforms.
Availability by market
Not every model is available in every market, for legal or technical reasons. The table gives an overview; the linked market pages are authoritative.
| Market | Signature device | Local / hybrid Middleware | Cloud Middleware | Details |
|---|---|---|---|---|
| Austria | Smart card (hardware) or online signing service | Windows, Linux, macOS | Yes | Austria |
| Belgium | Fiscal Data Module (FDM), connected over HTTPS | Windows, Linux, Android | Yes | Go-to-Market in Belgium |
| France | None (certificate in the Middleware) | Windows, Linux, macOS (Middleware 1.2) | Yes | Operation modes for France |
| Germany | TSE: hardware (USB, SD, microSD) or cloud | Windows, Linux, macOS, Android (Swissbit hardware TSE or fiskaly cloud TSE) | Yes; Bring your own Data Center also available | On-Premise Installation |
| Greece | None (connector to the myDATA API) | Not available | Yes, cloud only | Route 1 |
| Italy | RT printer or RT server (hardware), or IVA Servizi (government web service, CloudCashbox only) | Windows, Linux, macOS, Android | Yes | Installation for Italy |
| Poland (preview) | Fiscal printer (POSNET, hardware), connected over TCP | Not yet documented | Not yet documented | Available SCUs |
| Portugal | None (key held by fiskaltrust) | Only with your own certificate (route 2) | Yes; cloud only with the fiskaltrust certificate (route 1) | The two routes |
| Spain | None (qualified certificate held in the fiskaltrust cloud) | Not available | Yes, cloud only | Go-to-Market in Spain |
Table 5. Signature devices and available architecture models per market.
The hybrid model needs a cloud signature service, so it applies to markets where such a service is offered, for example Germany (cloud TSE) and Austria (online signing).
Decision diagram
Figure 6. Decision diagram for choosing a Middleware architecture.
Different locations of the same POS system can use different models. For example, a cloud POS system can use the CloudCashbox by default and a local installation only for locations that must work offline.
Planning fiskaltrust.Middleware instances per location
The fiskaltrust.Middleware (Queue) is the cash register in the regulatory sense, and the POS terminals connected to it are input devices that share its number series, closings and exports. You need at least one fiskaltrust.Middleware per location, and more if you need separate number series or closings, or for performance. This applies to every architecture model. For more information, see fiskaltrust.Middleware, Terminals and Locations.
The architecture adds one decision on top: in the local and hybrid models, several fiskaltrust.Middleware instances of a location can share one SCU and signature device, up to the limit of the device. For more information, see Dedicated or shared SCU.
For example layouts with pros and cons, see Rollout Scenarios.
Checklist
Use this checklist to document your decision before you start the integration:
| Check item | Your answer |
|---|---|
| Markets in which the POS system will be sold | |
| Operating systems of the POS devices (Windows, Linux, macOS, Android, iOS, web) | |
| Local Middleware available in each of these markets on these operating systems | |
| Signature device required in each market, and which one | |
| Hardware or cloud signature device, and its limits (platforms, number of Queues) | |
| Offline operation required: yes or no | |
| Who installs and maintains the Middleware on site: you, your PosDealers, or nobody (cloud) | |
| Cloud-only features required, for example eInvoicing | |
| API: POS System API or classic Middleware API, and whether it is available locally in your markets | |
| Number of fiskaltrust.Middleware instances per location, based on number series, closings and load | |
| SCU model: local or managed, dedicated or shared | |
| Chosen model per market: local, hybrid or cloud |
Table 6. Checklist for documenting the architecture decision.
When the decision is made, continue with the Integration Steps and the Integration Checklist.