Kiosk Software Development

Kiosk mode means the device runs one application and nothing else. On iOS, we configure Guided Access, which locks the device to a single app, disables the home button and hardware buttons, restricts swipe gestures, and prevents the screen from going to sleep during active use. On Android, we configure COSU (Corporate-Owned Single Use) mode via Android Device Policy Manager or a third-party MDM such as Hexnode, Scalefence, or SOTI MobiControl, which pins the application to the foreground, disables the home button, recent apps drawer, notification shade, and status bar, and auto-launches the app after a device restart. On Windows, we configure Assigned Access so the device boots directly into the application and the shell is hidden.

Every kiosk build includes watchdog logic that monitors the application process and restarts it within seconds if a crash occurs, no staff intervention needed. Idle timeout and screen reset logic returns the kiosk to the start state after a defined inactivity period, clearing any session data and resetting the UI so the next user starts fresh. Remote management via MDM allows us to push application updates, change configuration values, and view device health across the entire fleet without physical access to any unit. For multi-location deployments, this means a menu price change or a UI update reaches every kiosk within minutes of approval.

Payment on a kiosk has three parts: the software flow, the hardware device, and the printing. On the software side, we build the checkout flow including basket management, discount and coupon code handling, tax calculation by jurisdiction, partial payment handling, and split-payment support where the terminal accepts card and the customer has a loyalty credit balance. The payment hardware integrations we support include Stripe Terminal (BBPOS WisePOS E, Stripe Reader S700), Square Terminal (Square Reader, Square Terminal standalone device), and PAX payment devices (PAX A80, A920 series) via the PAX ePOS SDK.

All integrations handle EMV chip, NFC contactless (Visa PayWave, Mastercard contactless, Apple Pay, Google Pay), and magnetic stripe as a fallback. Receipt printing connects to thermal printers via USB or network: Star Micronics TSP series (common in hospitality and retail) and Epson TM series (TM-T88, TM-T20) via StarIO or Epson ePOS SDK. PCI DSS compliance is handled at the hardware layer since all card data is processed by the certified payment terminal, never by the kiosk application itself. This P2PE architecture means the kiosk application never touches raw card data and PCI scope stays minimal.

Guest lookup is the first step in any check-in kiosk: the guest enters a booking reference, phone number, or scans a QR code from their confirmation email. We build camera-based QR code scanning using the device camera (on iPad or Android) or a connected USB barcode scanner (Honeywell, Zebra DS series) for higher-volume environments. ID document scanning for age verification or identity checks integrates with document scanning SDKs such as Microblink BlinkID or Regula Document Reader, which capture and validate passport, driver licence, and ID card data from the camera feed.

Wristband and key card printing connects to BOCA thermal wristband printers (common in events and waterparks), Zebra ZD and ZC series card printers for plastic key cards, and Matica card personalization units for hotel key card programmes. After check-in, the system dispatches the guest into the right service queue via integration with queue management platforms such as Qmatic or SEDCO. Waiver and terms of service signing uses on-screen signature capture with a stored image and timestamp, meeting the evidentiary standard for most hospitality and events operators. Every session is logged with timestamp, booking reference, and outcome so operations teams have a full audit trail.

The ordering flow starts with the menu: items, categories, images, prices, and real-time availability driven by the kitchen management system so a sold-out special disappears from the screen the moment the kitchen marks it gone. We integrate with KMS platforms including Square for Restaurants, Toast, and custom kitchen display systems via API or WebSocket, depending on what the kitchen is running. Customization flows cover the full depth of modifier trees: size selection, protein choice, sauce and topping add-ons, special instructions text input, and allergen flagging with hard stops for declared allergens on the guest profile.

Basket management handles item quantity changes, item removal, special instructions per item, and a clear order summary before payment. On completion, the order fires directly to the KDS (kitchen display system) screen so kitchen staff see it immediately without a server walking a ticket over. Order status display on the kiosk shows the guest their order number and estimated wait time, updated in real time as the kitchen updates the order state, so the guest does not need to approach the counter to ask. Upsell placement in the flow (suggested add-ons at basket review, dessert prompt after the main is added) is A/B testable via the content management layer, so operators can measure which placements drive higher average order value.

The most important question in kiosk software is: what happens when something breaks? We design failure handling for every component, not as an afterthought. When the internet connection drops, the kiosk queues transactions locally using an on-device SQLite store and syncs them when the connection returns. Read-only data such as menus, product information, and room availability is cached locally with a configurable TTL so the kiosk keeps displaying current data during a network outage. When the payment terminal loses its connection to the payment gateway, the application shows a clear message to the user, flags the unit for staff attention via an alert in the monitoring dashboard, and offers a graceful exit from the checkout flow without leaving the user stranded on a payment screen.

Watchdog processes run as a separate service from the application and monitor it via a local health check endpoint. If the application does not respond within a configurable window (typically ten seconds), the watchdog kills and restarts the process. Remote monitoring gives operations teams a real-time dashboard showing which kiosks are online, which have reported errors in the last hour, and which have gone silent. Alert rules fire to Slack, PagerDuty, or email when a kiosk goes offline, when an error rate exceeds a threshold, or when a transaction fails to sync after a defined retry window. This turns a silent failure into a visible, actionable event before a guest queue forms.

Kiosk content changes constantly: menu prices, promotional screens, room rates, event registration details, information directory listings. A content management layer lets operators update these from a browser without a development deployment. We build the CMS to match what operators actually manage: menu items with images, pricing, and availability; promotional media for the idle screen and interstitial slots; opening hours and location information for directory kiosks. The CMS connects to the kiosk application via a polling or WebSocket channel so updates appear on-screen within a configurable interval, typically under five minutes.

For multi-location deployments, fleet management lets an operator push a single content update to every kiosk across every location simultaneously, or target a specific location or device group. A restaurant chain updating a seasonal menu can push to all 50 ordering terminals across 12 locations from one screen. Analytics built into the kiosk application feed session data back to the CMS dashboard: how many sessions per day per unit, what items were viewed versus ordered, where in the flow sessions were abandoned, and what the average transaction time is. These metrics tell operators which kiosk placements are working and which flows need attention, without needing to watch CCTV footage.