Modernising a business does not automatically mean replacing the POS, terminals and operating processes at once. If the existing parts still do their job, a better step may be a layer that connects them and unifies communication.
This is not a universal shortcut. You first need to understand which components must communicate, what the operation expects from them, and where responsibility for an error sits.
Why POS integration is more complex than it looks
A “POS solution” often includes several independent systems:
The POS application manages the sales flow, items, prices, orders and operator interface.
A payment terminal or SoftPOS accepts cashless payments. SoftPOS uses a supported mobile or POS device instead of a separate terminal.
Acquiring is the service that processes card payments between the merchant, provider and banking infrastructure.
The fiscal layer prepares the data and steps needed to issue and record a receipt in the relevant environment.
eKasa and VRP belong to Slovakia's fiscal environment; they are not names for the entire POS system.
Printing may use a printer built into the device or separate hardware.
Cloud management covers configuration, device status, monitoring and remote operational tasks.
External APIs connect the checkout flow to other services and systems.
Each component can have its own interface, rules, versions and lifecycle. A payment-app update may not be aligned with a POS or printer-driver update.
The problem: every system speaks a different language
A REST API lets systems exchange requests over a network. An SDK is a vendor's package embedded directly in an application. Local communication takes place on one device or network, while cloud communication goes through a remote service.
In an Android integration, the POS may call another app or its SDK. A hardware protocol defines communication with a printer, terminal or device. Real solutions combine these methods according to provider capabilities. Not every Ignition project uses every method listed here.
The integration layer
An integration or fiscal layer translates a POS request into the form expected by the payment, fiscal or hardware component. The POS does not need to implement every provider separately if it can rely on a stable interface to that layer.
This design can enable simpler integrations, clearer separation of responsibilities, more controlled changes, multiple POS connections and central management. These outcomes are not guaranteed by every architecture; they depend on interface quality, system boundaries and error handling.
A real example: Ignition Cloud
At Ignition, we operate a similar cloud and integration layer in a real environment. The solution currently serves hundreds of clients.
Ignition Cloud connects the POS and fiscal layers and supports central device management, deployment, monitoring and recovery. Its verified scope includes fiscal documents, transaction records and the payment flow from order to receipt. Its public product site is cloud.ignition.sk.
This proves that the Ignition team works with cloud operations, devices and integration flows. It does not mean that the same architecture or scope suits every POS project.
What must be solved for production
A production integration needs more than one successful API call:
Device identity: the system must know which device it is talking to and who it belongs to.
Configuration: changes must be traceable and assigned correctly.
Reliable communication: the design must expect network outages, delays and unavailable services.
Error handling: users and support need to know what failed and which next step is safe.
Retries: retry logic must not create a duplicate payment or receipt. Where relevant, idempotency ensures the same request does not produce a second result.
Monitoring and logs: operations need visibility and a way to explain failures afterwards.
Safe updates: releases need controlled deployment and a response path when something goes wrong.
Offline scenarios: where relevant, define what may continue without connectivity and how data is reconciled later.
These are general engineering requirements whose implementation depends on the project. For Ignition Cloud, central management, deployment, monitoring and device recovery are confirmed; the remaining points should not automatically be read as a public feature list.
When an integration layer is not enough
An integration layer cannot rescue a POS that is unmaintainable, lacks the required data or cannot safely start the necessary action. Changing the POS, architecture or an old component can also make more sense when the integration creates more exceptions than shared rules.
A workflow redesign is needed when a technical connection preserves a poor process — for example, when staff enter the same information three times or cannot distinguish payment status from receipt status.
Map the current flow before deciding what to keep, connect or replace. You can see more real projects and their status in What we are already building and operating. We also discuss integration assessment in App development with AI: when it makes sense and what to watch out for.
Conclusion
Modernisation does not have to mean replacing everything. Sometimes the most valuable part of the architecture is the layer between systems. It only creates value when its boundaries are clear, its failure behaviour is reliable and it can be operated over time.
