Kiosk Software Development: Custom Kiosk Software and Kiosk App Development for Self-Service Ordering, Check-In and Ticketing

Updated October 2026 · Written and maintained by the Progression Agency strategy team

Kiosk software development is the design and engineering of the app that runs on a self-service screen, the lockdown that keeps the device on that app, the links to card readers and printers, and the back office that updates and monitors every unit. Progression builds kiosk software for restaurants, retailers, clinics, hotels, venues, transit and parking operators, public offices and the companies that make kiosk hardware. Progression Agency is based in New York City and works with clients across the United States and worldwide.

What is kiosk software, and what does kiosk software development cover?

Kiosk software is the program a customer uses on a public or shared screen to complete one task without staff: order, check in, buy a ticket, find a room or pay a bill. Kiosk software development covers that app plus everything around it that keeps a screen in a busy lobby working every day.

How does kiosk software work?

Four layers work together. The operating system is locked so the screen shows only your app. The kiosk app runs the customer flow and talks to peripherals such as a card terminal, a printer and a scanner. A back end connects the app to your POS, scheduling, ticketing or billing system. A management console lets staff see every unit, push updates and restart a stuck one.

Kiosk app development versus phone app development

Kiosk app development starts from a different user. A phone app has one owner who knows how to use it; a self service kiosk app meets a stranger every few minutes, so it resets itself after each session, clears personal data, ignores stray taps, survives a dropped network and never shows a system menu. Those behaviors are most of the engineering, not the screens.

Kiosk software developers and the hardware maker

The hardware maker supplies the enclosure, the screen, the mount and often the operating system image. Kiosk software developers write the app, the integrations and the fleet tools. When you buy both from one vendor, ask which parts are theirs and which are licensed from someone else, because that decides who can change them later.

Custom kiosk software or an off-the-shelf kiosk app?

Buy first when the flow is standard and the site count is small; build when the kiosk must read and write your own systems, carry your brand or run across a fleet where license fees add up. Plenty of good kiosks run on a packaged product, and we say so when that is the answer.

When off-the-shelf kiosk mode software is enough

If the task is a single web form or a static menu, the lockdown built into Android, Windows or iPadOS plus a well-made web page can be enough. Kiosk mode software of this kind keeps people on the page; it does not take payments, print receipts or report which units are offline. Start there when the stakes are low.

When custom kiosk software pays for itself

A custom build earns its cost when the flow depends on live data from your systems, when every extra tap costs sales at the counter, when you run enough units that per-device fees outweigh a build, or when the kiosk is a product you sell. You also own the code, so a vendor’s price change or shutdown does not strand your fleet.

Is open-source or free kiosk software enough?

Free tools and the kiosk modes built into Windows and Android lock a screen well. What they rarely include is the part that costs money to run: payment terminal links, integrations, remote updates and alerts. Open-source parts can sit inside a custom build; we list every component license in the handover so nothing surprises your legal team.

Self-service kiosk software by use case

Self-service kiosk software follows the job it replaces. An ordering kiosk is judged on speed and order value, a check-in kiosk on wait time and data accuracy, a ticketing kiosk on throughput at peak. The table lists the use cases we scope most, with the system each one depends on.

Self ordering kiosk software and restaurant kiosk software

Self ordering kiosk software lives or dies on the menu: modifiers, combos, allergens, sold-out items and suggestions that appear at the right moment. Restaurant kiosk software also has to fire tickets to the kitchen in the right station order. For ordering apps, loyalty and QR table ordering across a brand, see our restaurant app development page; kiosk ordering software usually shares that menu service.

Check in kiosk software for clinics, hotels and visitor desks

Check in kiosk software confirms who someone is, pulls up the booking and updates the record so staff are ready. Patient check in kiosk software adds insurance cards, consent forms and copays, and it must keep one patient’s details off the screen when the next person walks up. Our healthcare software development team handles the scheduling and records side; hotel check-in adds the key encoder and the property system.

Ticketing, transit and airport kiosks

Ticketing kiosks sell or print passes at speed, often in several languages. Airline kiosks carry their own federal rule: the Department of Transportation requires carriers at US airports with 10,000 or more enplanements a year to make at least 25 percent of automated kiosks in each location accessible, under 14 CFR 382.57, with the same functions as the other kiosks there.

Interactive kiosk software for wayfinding, museums and showrooms

These kiosks answer questions: where is room 214, which model fits my space, what is in this gallery. It needs search that forgives typos, maps that orient to where the kiosk stands and content staff can edit without a developer. Analytics on what people search for often become the most useful output.

Bill payment and public service kiosks

Payment kiosks for utilities, fines or rent post money to a billing system and print a receipt the customer can trust. They need clear failure messages, a reference number for every attempt and reconciliation reports that match the processor’s settlement file to the cent.

Kiosk mode software: locking the device to one app, by operating system

Every major operating system can pin a device to one app; they differ in how it is set up, managed and released. The choice usually follows the hardware and the peripherals, so we settle it before design starts.

Android dedicated devices and lock task mode

Android’s developer guide describes lock task mode for dedicated devices locked to a single app or a set of apps, and names kiosk apps as a use. In that mode users typically cannot see notifications, open other apps or return to the home screen, and only apps allowlisted by a device policy controller can run. Screen pinning looks similar, but the person using the device can leave it, so it is not a kiosk lockdown. Most kiosk android app development we scope uses this mode.

Windows Assigned Access

Microsoft’s Assigned Access runs a single Universal Windows Platform app or Microsoft Edge full screen above the lock screen, and restarts it automatically if it closes. It works on Windows 10 and Windows 11 in the Pro, Enterprise, Education and IoT Enterprise editions, needs User Account Control turned on and a sign-in at the console, and is not supported over a remote desktop connection.

iPad kiosks: Guided Access and managed single-app modes

On a single iPad, Guided Access restricts the device to one app, can switch off parts of the screen, hardware buttons and the keyboard, and needs a passcode to end. For a fleet, Apple’s deployment guide documents App Lock and Autonomous Single App Mode payloads for devices under management, so units can be locked and updated without anyone touching them.

Which operating system is best for a kiosk?

Choose the platform your peripherals support first, then the one your team can manage. Android suits low-cost tablets and purpose-built kiosks, Windows suits large screens and PC peripherals, iPadOS suits counter-top units where a polished feel matters, and Linux suits embedded hardware where you control the whole image.

Touch screen kiosk software design: screens a stranger can use in seconds

Good touch screen kiosk software is designed for a first-time user standing up, in a hurry, possibly with a child or a bag in one hand. Kiosk software design is mostly subtraction: fewer steps, bigger targets, one decision per screen.

The attract screen and the session timeout

The idle screen has one job: invite a tap. Once a session starts, a timeout returns the kiosk to that screen and wipes what the last person entered. Too short and people lose their order; too long and the next customer sees someone else’s details. We set it from the pilot logs, not by guess.

Large targets, short flows and a visible way back

Buttons sized for a thumb, a progress indicator, a back button on every step and a start-over option that asks before it erases anything. Text stays short enough to read at arm’s length, and every error message says what to do next.

Languages, receipts and the hand-off to staff

Language choice belongs on the first screen. The final screen tells the customer exactly what happens next: take your receipt, wait for your number, go to room 3. When something fails, the kiosk shows a code staff can look up, so the customer is not sent back to the start.

• One task per kiosk flow, with optional extras offered once and never twice
• No account sign-up before the customer reaches the main task
• Every screen tested at full size on the real enclosure, not a laptop
• Glare, viewing height and the reach of a seated user checked on site
• Analytics on where people abandon, reviewed weekly during the pilot

Accessibility rules for kiosks: ADA machines, airport kiosks and Section 508

Several federal rules reach kiosks, and which one applies depends on what the machine does and who owns it. We design to the rule that fits and use the most specific provisions as a reference for the rest; your counsel confirms the legal position.

ATM and fare machine provisions in the 2010 ADA Standards

The 2010 ADA Standards say that where automatic teller machines or self-service fare machines are provided, at least one of each type at each location must comply with section 707. That section requires the machine to be speech enabled, at least one tactilely discernible control for each function, a display visible from 40 inches above the center of the floor space in front of it, characters at least 3/16 inch high in a sans serif font, and Braille instructions for starting speech mode.

Reach ranges and operable parts

Where a forward reach is unobstructed, the standards set the high reach at 48 inches maximum and the low reach at 15 inches minimum above the floor. Operable parts must work with one hand, without tight grasping, pinching or twisting of the wrist, and with no more than 5 pounds of force. Those numbers decide where on the screen the main buttons can sit.

Airport kiosks under the carrier rule

For airlines, the Department of Transportation rule required kiosks installed on or after December 12, 2016 to meet its design specifications until 25 percent in each location did, and 25 percent by December 12, 2022. Accessible units must be marked as accessible, kept in working order and offer every function the other kiosks in that location offer.

Section 508 for federal agency kiosks

The Section 508 Standards are mandatory for federal agencies subject to Section 508 of the Rehabilitation Act. For devices with closed functionality, such as a kiosk, the standards require operation without the user attaching assistive technology other than personal headsets, and speech output on any device with a display screen.

Accessibility in the on-screen app

Beyond the hardware rules, we build customer-facing screens to WCAG 2.2 level AA: contrast, text size, focus order, timeouts the user can extend and an audio mode with a headphone jack or handset where the hardware supports it. For the website side of the same brand, see ADA compliant website design.

Peripherals: card readers, printers, scanners and cameras

Most kiosk faults are peripheral faults: a printer out of paper, a reader that lost pairing, a scanner that will not wake. The kiosk app has to know each device’s state and tell staff before a customer finds out.

Device drivers, SDKs and the test bench

Each peripheral comes with a driver or software kit for a given operating system, which is one more reason the hardware choice comes first. We keep a test bench with the exact models you will deploy and run every release against it before it reaches a site. Where devices pair over Bluetooth, the same skills apply as in our IoT app development work.

• Confirm the driver or software kit exists for your operating system version
• Test each peripheral after a power cut, not only after a clean start
• Log every device error with the unit, the model and the time
• Keep spare-part and paper-low alerts separate from software faults
• Recheck every peripheral after each operating system update
• Write the staff fix for each common fault into the console

Fault handling customers never see

If the printer fails mid-order, the kiosk still completes the sale and shows the order number on screen. If the reader drops, the app offers another payment path or sends the customer to the counter with the cart saved. The unit then raises an alert in the console.

Payments on a kiosk without card data in your app

The safest kiosk payment design keeps card numbers out of the kiosk app entirely: a certified terminal reads the card and talks to the processor, and the app only learns approved or declined. That keeps most card-security work with the terminal and the processor.

Why PCI DSS shapes the design

The PCI Security Standards Council describes PCI DSS as a baseline of technical and operational requirements for protecting payment account data, aimed at entities that store, process or transmit cardholder data or could affect the security of that environment. A kiosk app that never sees the card number keeps itself far from that scope.

Approved terminals and point-to-point encryption

The council publishes listings of approved PIN transaction security devices and validated point-to-point encryption solutions. We integrate the terminal your processor supports through its own software kit, so encryption runs from the card to the processor and the kiosk handles only the sale amount and the result.

Who holds which responsibility

Your processor and terminal vendor carry the card-reading side; your organization keeps its own PCI obligations as a merchant. We design the kiosk so card data never enters it, document the payment flow for your assessor and do not store payment details in logs or analytics.

Kiosk management software: remote updates, monitoring and content

Kiosk management software is how a fleet stays healthy without a technician in a van. It shows every unit’s status, pushes app and content updates, raises alerts and restarts a unit that hangs.

Device management tools or a custom fleet console?

Mobile device management tools handle the operating system: lockdown policy, Wi-Fi, certificates and app installs. A custom console handles the business: which unit sold what, which printer is low, which menu version each site runs. Most fleets use both, with the console reading device status from the management tool.

Staged updates and rollback

Updates go to a few pilot units first, then to everyone once error rates hold steady. Every release can be rolled back from the console. That turns a bad update into a short dip at one site rather than a dark fleet on a Saturday.

Offline mode

Networks drop. A well-built kiosk keeps taking orders or check-ins against a local copy, queues the writes and syncs when the connection returns, and tells staff which transactions are waiting.

Content and price changes without a release

Menus, prices, opening hours and promotions live in the back office, not in the app code. Staff change them in a browser, preview on a test unit and publish to one site or all. Our dashboard development team builds these consoles.

Integrations: POS, EHR, PMS, ticketing and loyalty

A kiosk is only as useful as the systems behind it. The integration list usually decides the timeline, so we confirm vendor API access in the first week.

APIs first, screen scraping never

We connect through the vendor’s published API or a supported integration partner. Where an older system has no API, we build a small service in between and document it. Our API development and EHR software development pages cover that work in more depth.

Retail and enterprise kiosks

Retail kiosks for endless aisle, returns and price checks read product and stock data covered on our retail software development page. Internal kiosks for shift clock-in or tool checkout connect to the systems described under enterprise app development.

AI answers: how kiosk buyers ask assistants for a kiosk software developer

Operations and IT leads now ask ChatGPT, Claude, Perplexity, Gemini, Microsoft Copilot and Google AI Overviews questions such as which kiosk software developer handles patient check-in, or what self-ordering kiosk software works with a given POS. The answers lean on pages that state specifics plainly.

What assistants tend to cite for kiosk questions

Platform documentation for kiosk modes, the text of accessibility rules, vendor pages that name the integrations they support, comparison tables and review sites. Vague pages that only say they build kiosks are rarely the ones quoted.

• Which kiosk software developer builds patient check-in kiosks that connect to our scheduling system?
• What self ordering kiosk software works with our POS?
• How do I lock an Android tablet to one app for a lobby kiosk?
• Which rules apply to an accessible ticket kiosk?
• How much does it cost to build a kiosk for three locations?

What a kiosk maker or operator should publish

If you sell kiosks or the apps that run on them, publish the operating systems, peripherals and integrations you support, an accessibility statement that names the rules you design to, and a short answer to how much a deployment takes. Our answer engine optimization service builds those pages.

How kiosk app development runs, from counter study to fleet

Six stages, each ending in something you can test, with a pilot at one site before the rollout. Working software arrives every two weeks with a short written update.

What we need from you in week one

A walk-through or video of the counter at peak, the hardware model if it is already chosen, access requests for each system to integrate and the name of the person who will own the fleet. With those, the written scope follows quickly.

How long a kiosk project takes

The longest items are usually vendor API approvals and hardware delivery, not the screens. A single-flow kiosk on known hardware is a short project; a multi-system fleet with a custom console is a longer one. The written scope gives dates for each phase.

How much does it cost to build a kiosk? Kiosk software cost drivers

The cost depends on the number of integrations, the peripherals, the fleet tools and the accessibility work, not on the screen count alone. Each build is quoted after a written scope; hardware is quoted by the hardware vendor.

Software cost and hardware cost are separate quotes

Enclosures, screens, terminals and printers are priced by the hardware maker or reseller, often with their own support contracts. We give them the peripheral list from the scope and keep our quote to the software, integrations and support.

Keeping the first release lean

Start with one flow at one site, one payment path and the console features staff use daily. Add languages, loyalty and analytics once the pilot shows where customers struggle.

How to choose kiosk developers

Pick a team that asks about your counter before your screens, names how it will lock the device and reach each peripheral, and puts the support plan in the scope. Each line below can be checked before you sign.

Questions to ask a kiosk software developer on the first call

What happens when the network drops mid-transaction? How is an update rolled back? Where does card data go? How does a blind user start the flow? Who owns the code? Clear, specific answers to those five questions sort vendors quickly.

Why Progression for kiosk application development

One team covers discovery, design, the kiosk app, integrations, the console and support, so nothing falls between vendors. You own the code, data and cloud accounts from day one.

Kiosk application development on mainstream technology

We build with TypeScript, React, Node.js and Python on the back end, PostgreSQL for data, and React Native, Flutter, Swift or Kotlin on devices, so your own team can hire for and maintain the software later. See our software development company page for the full stack.

Kiosk development software and tooling you keep

Device simulators, the peripheral test bench scripts, the deployment pipeline and the console are handed over with the app. Your team, or the next vendor, can run a release without us.

Written scope before any code

Every project starts with a written scope and estimate. Development begins only after you approve it, and working software arrives every two weeks with a short written update.

Related software and app development services

Kiosks rarely stand alone. These pages cover the systems and apps that usually sit around them.

• Restaurant ordering apps, loyalty and QR table ordering
• Retail software for stock, returns and endless aisle
• Healthcare software for scheduling and patient intake
• Enterprise apps for staff, shifts and internal kiosks
• Automotive software for dealers, service lanes and fleets
• IoT apps for connected devices and sensors
• Android app development
• iOS and iPad app development
• Cross-platform app development
• UI and UX design for touch interfaces
• Embedded software development
• Cloud app development for kiosk back ends
• MVP development for a first kiosk pilot
• Custom software versus off-the-shelf products

Frequently asked questions