Challenge
The app crashes or closes and the kiosk shows the desktop.
Agnotic approach
The device runs in single-app lockdown, a watchdog restarts the app, and the operating system's shell is never reachable from the touch screen.
Self-Service Kiosks
Self-service kiosk software development
An unattended kiosk has no one standing by when the printer jams, the card reader drops out or the app falls back to the desktop. Agnotic Technologies builds self-service kiosk software that stays locked to its task, recovers on its own and serves every customer, including those using assistive technology.
Locked-down kiosk appCard readers and printersAccessible by designRemote fleet updates
Trusted by global innovators
Kiosk software
What is self-service kiosk software?
Self-service kiosk software is the locked-down application, device drivers and management tools that let customers check in, order, pay or print a ticket on an unattended machine. Agnotic Technologies builds kiosk software for clinics, hotels, restaurants, retailers and transport operators, with peripheral control, accessibility, privacy between users and remote fleet updates.
Hardware stays your choice: the kiosk body, the screen and the peripherals. Our work is the app, the layer that talks to its card reader, printer and scanners, and the console your team uses to watch every unit.
Display-only screens that play scheduled content are a different product, covered on our digital signage page. Clinic intake forms and insurance capture are on our patient onboarding page.
Failure points
What fails on an unattended kiosk, and how do we design for it?
The failures we test for before any kiosk goes into a lobby, and the design answer for each.
Challenge
The receipt printer runs out of paper mid-session.
Agnotic approach
The app checks printer status before a session starts, offers an email or SMS receipt when printing fails, and alerts staff before the roll runs out.
Challenge
The card reader disconnects during checkout.
Agnotic approach
The peripheral layer checks the reader before payment, retries the connection, and closes the session cleanly without charging twice.
Challenge
The network drops during payment.
Agnotic approach
Every payment has an idempotency key and a pending state, so the kiosk confirms the result with the payment provider when it reconnects instead of guessing.
Challenge
The previous customer's name or booking is still on screen.
Agnotic approach
Sessions end on completion, cancel or inactivity, and the app clears screens, form fields, caches and scanned images before the next customer.
Challenge
A wheelchair user cannot reach the controls or read the screen.
Agnotic approach
Layouts keep key controls in reach, offer a low-reach layout and an audio mode, and support a headset with speech output where the venue requires it.
Challenge
A remote update bricks a unit in a busy lobby.
Agnotic approach
Updates go to one test kiosk first, then to small groups outside opening hours, and a failed health check rolls the unit back to the last working version.
Lockdown
Which operating system lockdown fits each kiosk?
The platform decides how the kiosk is locked to its app, what a customer can never reach and how the unit is managed. We choose per kiosk type.
| Kiosk platform | Lockdown feature | What the customer cannot reach | How units are managed |
|---|---|---|---|
| Android tablet or kiosk PC | Lock task mode, set by a device policy controller | Notifications, the home screen and any app that is not allowlisted | An EMM or device policy controller that pushes the app, settings and updates |
| Windows kiosk PC | Assigned Access single-app kiosk experience | The desktop, other apps and the lock screen; the app restarts if it closes | Windows device management, with the kiosk profile and updates pushed centrally |
| iPad | A single app lock set through mobile device management | The home screen and other apps | An MDM service that supervises the device and pushes the app |
| Web kiosk app in a locked browser | The kiosk browser mode of the platform above | Browser controls, address bar and other sites | The same device management, plus a web app redeploy for content changes |
Peripheral support often decides the platform: some card terminals, ID scanners and printers only ship drivers for one operating system.
Peripherals
Which peripherals does kiosk software drive?
Each device gets a status check, an error path and a log entry, so staff know what failed before a customer tells them.
Payments
- Card terminal or PIN pad as its own device
- Contactless and mobile wallets through the terminal
- Card data kept out of the kiosk app
Printing
- Receipt and ticket printers
- Bag tag, wristband and label printers
- Paper and jam status checks
Scanning and ID
- Barcode and QR scanners for bookings
- ID and passport readers where identity is checked
- Scanned images cleared after each session
Accessibility and capture
- Headset jack or handset for speech output
- Tactile keypad for non-touch input
- Camera or signature pad where a flow needs one
Session flow
What does one kiosk session look like from start to reset?
Every session follows the same path, and every path ends in a reset, including the ones a customer walks away from.
Attract screen
The kiosk shows what it can do and runs a quiet health check on every peripheral before it accepts a session.
Identify
The customer scans a booking code, card or ID, or starts as a guest, and the kiosk looks up the record from your system.
Complete the task
Check in, order, pay or change a booking, in large touch targets, with audio guidance and more time on request.
Pay on the terminal
The card terminal handles the card and returns only a result and a token, so card data never touches the kiosk app.
Print or send
Tickets, receipts, keys or wristbands are printed or dispensed, with an email or SMS fallback if a printer fails.
End and wipe
On completion, cancel or inactivity, a warning gives the customer a chance to continue, then the session data is cleared and the attract screen returns.
Who it is for
Which kiosks do we build software for?
Operators who run self-service machines in public spaces, each with its own systems and rules.
Clinic and hospital check-in
Arrival, appointment lookup and copay on a kiosk that never shows one patient's details to the next. Intake forms connect from your patient onboarding flow.
Hotel check-in and key issue
Reservation lookup from the property management system, ID scan and key card encoding.
Restaurant and quick service ordering
Menus, modifiers and payment sent straight to the kitchen and the POS.
Retail self checkout and returns
Scanning, price lookups and returns tied to the same POS and inventory as the tills.
Airport, rail and venue ticketing
Boarding passes, bag tags and tickets, with the accessibility rules that apply to airport kiosks.
What do we build into self-service kiosk software?
Modules we scope one by one, so a pilot kiosk can run one flow end to end before more flows and venues are added.
Kiosk app
The customer-facing app for each flow, with large touch targets, several languages, audio guidance and a timeout with a warning.
Peripheral service layer
One service that talks to printers, scanners, readers and terminals, reports their status and hides vendor drivers from the app.
Payment integration
The card terminal linked to your payment provider, with tokens, idempotency keys and refunds handled outside the kiosk app.
Session manager
Starts, times out and ends sessions, clears data between users and logs every session without personal details.
Offline queue
Orders and check-ins queue locally when the network drops, then sync in order, with payments held until confirmed.
Fleet console
Unit status, peripheral alerts, screenshots, remote restart and staged updates for every kiosk, through your device management service.
Back-office connectors
Links to the POS, property management system, scheduling system or ticketing platform behind each flow.
Platform and accessibility rules
Which platform and accessibility rules shape kiosk software?
14 CFR 382.572010 ADA StandardsWCAG 2.2Android lock task modeWindows Assigned AccessPCI DSS
Scope and cost
What drives the cost of kiosk software?
We do not offer a kiosk calculator or publish prices, because the hardware, flows and venues change the build more than any single number. These are the drivers we price on the scoping call.
Flows per kiosk
How many tasks the kiosk handles, such as check-in, ordering, payment and ticketing.
Peripherals
The card terminal, printers, scanners and readers, and whether their drivers support your platform.
Payment route
Your payment provider and terminal, and whether refunds or deposits run on the kiosk.
Accessibility scope
Speech output, tactile input and reach, and any venue rules such as 14 CFR 382.57 for airport kiosks.
Back-office systems
The POS, property management, scheduling or ticketing systems each flow reads from and writes to.
Fleet size and management
How many units and sites, your device management service, and how updates are rolled out.
Facts and sources
Facts behind self-service kiosk software
The platform and accessibility rules behind the lockdown table, session design and accessible mode, each linked to its primary source.
On Android, only apps allowlisted by a device policy controller can run in lock task mode, and while it is on, device users typically cannot see notifications, open apps that are not allowlisted or return to the home screen.
Source: Lock task mode (Android Developers)In a Windows Assigned Access kiosk experience, a single Universal Windows Platform app or Microsoft Edge runs full screen above the lock screen, users can only use that app, and if the app is closed it restarts automatically.
Source: Assigned Access overview (Microsoft Learn)Airlines must ensure that at least 25 percent of the automated kiosks they own, lease or control in each location at a U.S. airport with 10,000 or more enplanements a year meet the accessibility design specifications, and the accessible kiosks must provide all the same functions as the others in that location.
Source: 14 CFR 382.57(a) (eCFR)Where an accessible airport kiosk requires a timed response, the user must be alerted visually and by touch or sound and given the opportunity to ask for more time, and the kiosk must offer the same degree of privacy of input and output to all individuals.
Source: 14 CFR 382.57(c)(3) and (c)(4) (eCFR)Accessible airport kiosks must offer speech output for operating instructions, transaction prompts, input verification and error messages, delivered through a mechanism readily available to all users, such as an industry standard connector or a telephone handset.
Source: 14 CFR 382.57(c)(5)(i) (eCFR)
Engagement
How does a kiosk software engagement work?
We prove one kiosk with real peripherals and real customers before the fleet grows.
1.
Scoping call
We list your flows, venues, hardware and back-office systems, and choose the platform and lockdown approach.
Scope2.
Pilot kiosk
A fixed-scope first release: one flow on one kiosk model at a pilot site, with failure tests for printers, readers and the network.
Build3.
Roll out and support
More flows, models and sites, staged updates through the fleet console and support after launch.
ScaleFrequently Asked Questions
No. We write the kiosk app, the peripheral layer and the fleet console. If you have not chosen hardware yet, we list the platform, driver and peripheral requirements so your hardware supplier can quote against them.
The card is read by a separate payment terminal linked to your payment provider. The kiosk app sends an amount and receives a result and a token, never the card number. Our PCI DSS page covers how that keeps your scope small.
After a period of inactivity the kiosk shows a warning and offers more time. If nobody responds, it cancels the session, releases any held payment and clears the screen and stored data before the next customer.
Partly. Tasks that need a live answer, such as payment approval, wait for the connection. Orders and check-ins that can be confirmed later queue on the device and sync in order when the network returns.
Yes. Each flow reads from and writes to the system behind it: the POS for orders, the property management system for hotel stays, the scheduling system for clinic arrivals or your ticketing platform.
Yes. A fixed-scope first release covers one flow on one kiosk model at a pilot site. The fleet console, more flows and more venues come once the pilot works with real customers.
Peripheral drivers are usually the biggest unknown, so we test them on your hardware first. The plan for the pilot follows from that test, the number of flows and the back-office systems involved.