Kiosk Software Explained: Three Layers, Not One

Ask five suppliers for "kiosk software" and you will be shown five different products. One locks a tablet into a single app. One manages a fleet of Windows PCs. One sits between the application and the cash acceptor, the card dispenser or the passport scanner. They are all called kiosk software, they are all useful, and none of them replaces the others.

That confusion costs buyers time, because a proposal can look complete while missing the layer their project actually depends on. This guide separates the three, shows where a device abstraction layer sits, and lists the questions that reveal which product a supplier is really offering.

Three products, one label

App lockdown keeps a device on one application. It restricts the browser, hides the operating system, blocks navigation and reapplies the policy after a restart. It is the layer that stops a customer from reaching the desktop. Products in this category are often sold as "kiosk software" and are good at what they do.

Fleet and device management covers everything around the application: inventory of devices, remote status, application releases, access control and audit. It answers the question "which machines are healthy, and what is running on them?" It does not talk to a cash acceptor.

Hardware middleware is the layer between your application and the physical equipment. It exposes device operations as an interface, handles the vendor protocols underneath, and returns a structured result the application can act on. It answers "did the dispenser pay out, and what does the fault code mean?"

A real deployment usually needs two of the three, and sometimes all three. The failure mode is buying one and expecting it to cover another's job — a lockdown tool cannot reconcile a cassette, and a middleware layer will not stop someone closing your app.

What the device abstraction layer does

A device abstraction layer runs on the kiosk, beside your application, and presents every peripheral through one contract. The application asks for a readiness check, a dispense, a document capture or a print job. The layer selects the right driver, performs the operation and returns a result with a status code, a message and the data or errors.

The supported families in a mature deployment look like this:

• cash acceptors, dispensers, recyclers and coin handling
• card issuance modules and SIM printers
• biometric modules, including fingerprint and facial capture
• ID and document scanners, including passport readers
• receipt and document printers, and card issuance modules
• barcode scanners and PCI payment terminals

The practical value shows up when the device list changes. If the application calls a method rather than a vendor protocol, a new device model becomes a driver update. The application keeps its workflow, and the integration does not have to be rebuilt for every hardware change. That boundary is the difference between a platform and a per-project integration.

Capabilities shared across channels

Once the device layer is behind an interface, the same capability can serve more than one channel. A kiosk can run the full journey; a tablet can support an assisted flow; a phone or the web can prepare the context before the customer reaches the machine. The customer session, the references and the business rules stay consistent even though the front end changes.

That sharing works when the middleware owns the device interaction and the application owns the journey. It breaks when each channel grows its own integration, because the same cash, identity or printing logic is then implemented several times and drifts apart.

Channel coverage depends on the deployment, not on a product claim. Confirm which channels are in scope, which of them share a session, and where the customer can resume.

The integration layer

Below the device layer, the middleware needs somewhere to put what it knows. An integration layer typically covers inventory, reporting, alerts and limits: cassette levels, consumable stock, transaction outcomes, exception counts and the alert rules that decide when a site needs attention.

It also connects the kiosk to the systems of record — core banking, CRM, ticketing, ERP, clearing, and existing APIs. The important boundary is that the middleware reports and executes; the business decision stays with the system that owns it. A card is not active because it was dispensed; a payment is not settled because a terminal approved it. Eligibility, activation and settlement belong to the issuer, the processor or the bank.

The operations view

Everything above produces data an operator needs: which devices are healthy, which sessions failed, what version of the application is running, and who changed what.

A useful operations view answers those questions across the fleet rather than one machine at a time. It shows device and application state together, keeps a history of actions, and separates an observed fault from a predicted one. Access control matters here as much as visibility: staff should see the sites and actions their role allows, and the record of what happened should survive staff changes.

How to separate them in an RFP

Six questions usually settle which product a supplier is offering:

1. Which peripherals does the product control, and through what interface?
2. What happens to the application when a device model changes?
3. Where does device state — readiness, faults, stock — come from?
4. Does the product keep the app open, or does it also manage the device and its releases?
5. Which systems does it post to, and which decisions does it deliberately leave alone?
6. Who supports the hardware fault at 2am: the software supplier, the device vendor, or the field team?

Answers that stay at the level of "we integrate with everything" are a warning. A supplier that can describe the boundary — and name what it does not do — is describing a layer you can build on.

Where Azimut SDK fits

Azimut SDK is the middleware layer. It runs beside the kiosk application, exposes device operations through one JSON API, and handles the vendor protocols, session lifecycle and device state underneath. The platform overview describes the boundary; the developer guide shows the first read-only request and the response envelope; the integration catalog lists the device models and the operations recorded for each.

Fleet operations are a separate product, Satellite. It covers device visibility, supported diagnostics and application releases — the second of the three categories above — and it is intentionally not the same thing as the device abstraction layer.

If you are comparing categories, bring your hardware list and the workflow you intend to run. The evaluation guide sets out what to confirm before a pilot, and the contact page routes the conversation to the integration team.

Common questions

Is kiosk middleware the same as kiosk mode? No. Kiosk mode restricts a device to one application. Middleware talks to the peripherals and connects the application to the devices and systems.

Does the middleware replace our application? No. It replaces the hardware integration code underneath your application. The customer journey and business rules stay with your team.

Can one kiosk run more than one device vendor? Yes, provided each model is supported or a driver is written. The application calls the interface, not the vendor protocol.