Extending kiosks
Future Ordering's kiosk sales channel is extensible at several different layers. Which layer you extend depends on what you need to change: the on-screen experience, the connection to in-store hardware, or the application that hosts the kiosk itself.
This section gives you an overview of the available extension points and points you to the detailed documentation for each. It does not replace that documentation — treat it as a map for choosing the right starting point.
Ways to extend a kiosk
| Extension point | What it changes | Typical use case |
|---|---|---|
| Frontend plugins | Adds UI elements or behavior to the existing kiosk web frontend | Injecting a custom upsell block, adding a loyalty sign-up step, reacting to order events |
| Custom hardware (scanner, printer or payment terminal) | Connects a kiosk to a specific in-store payment terminal | Supporting a payment terminal that is not already integrated with Future Ordering, or one with a custom fiscalization flow |
| Custom frontend shell | Replaces the application that hosts the kiosk frontend | Running the kiosk experience inside your own native application, or on hardware Future Ordering does not natively support, or if you need to load device-specific plugins instead of loading tenant-wide kiosk plugins |
These extension points are not mutually exclusive. A custom frontend shell, for example, still loads the standard Future Ordering web frontend and can serve frontend plugins locally so those plugins can reach hardware such as payment terminals, receipt printers, and barcode scanners.
Frontend plugins
A frontend plugin is JavaScript or TypeScript code that Future Ordering loads into the kiosk web frontend at runtime. Plugins can inject UI components, transform lists of data, listen for order and navigation events, and register services — implementations of platform capabilities such as payment processing, receipt printing, barcode scanning, and display brightness control.
Frontend plugins are the right starting point for most customizations, since they run inside the existing Future Ordering frontend and don't require replacing any part of the kiosk application. See Frontend plugins for how plugin works and Custom Kiosk Shell if you need to load device-specific plugins.
Custom kiosk payment terminal integration
Kiosks that need to support a payment terminal Future Ordering does not already integrate with can do so by integrating an external payment provider integration, which is an asynchronous, HTTP-based integration for a payment provider's own backend, which in turn can interact directly with the terminal connected to a specific kiosk. See the section on building an External Payment Provider for more information, and review the high-level sequence diagrams in the Custom hardware integrations article for more understanding of the flow itself.
Custom frontend shell
A custom kiosk shell is the application that hosts the Future Ordering web frontend on the kiosk device — typically an Electron application, but any technology capable of hosting a WebView and implementing the required messaging bridge works. Building a custom shell is a larger undertaking than writing a frontend plugin, and is only necessary when you need to control the hosting application itself, for example to support hardware, an operating system Future Ordering does not already provide a shell for, or if you need additional control of the shell experience such as opening blocking overlays when a printer latch is opened, or if you need to load device-specific frontend plugins.
See Custom kiosk shell for more information about building a custom frontend shell.
Related integration flows
The Custom hardware integrations article describes high-level flows for hardware integrations, covering scanner integration, guest printing, payment terminal, and fiscalization choices.