Denis Kondopoulos, Project Director, Naxtech
Food-Ordering.com is a standalone web application for hospitality businesses. It allows direct, efficient, fully owned and controlled sales and engagement with customers across different functions (online ordering, in-store ordering, telephone ordering with CallerID, table booking with preordering) and 144 languages.
When I started working on the Food-Ordering.com system, I was amazed to see that in the world of POS and kiosks all vendors appeared to have a take-it-all approach to sales. If you wanted to use their kiosk you’d have to get whatever hardware they had for you, use the payment providers and hardware that they offered, and use a printer that they had selected for you. In short, the minute you wanted a kiosk (among other things) you were essentially forced to go with whatever choices the kiosk vendor made for you. Not only the choice of hardware was limited but they even demanded that you buy it from them rather than anywhere else. The approach did not leave me with a positive feeling and I thought I could do better.
I began looking into the integration of kiosk devices with printers, card terminals and kiosk software. With that in mind, I think it is important to realise (for those who do not know) that essentially a kiosk is just a computer running Windows or Android (usually) but it just happens that this computer has a different shape. So whatever kiosk software you’d want to run it would have to be written as a Windows or Android application.
I then looked at printer integrations and this is where things got interesting. There are so many choices when it comes to printers – different brands, paper width support. But printers typically come with Windows drivers/software. When it came to Android there were no drivers. A printer may have an SDK you can use and then your kiosk software has to use this specific SDK to talk to a specific printer. There is, therefore, no easy way to talk to any printer type on Android – and printers come with no Android drivers. That means that in order to have flexibility in terms of what printer you use you can only do that by using Windows. All printers have drivers for Windows. You simply ask Windows to print whatever you want and the operating system does the rest for you.
Terminal integration
It was a similar picture with terminals. Almost all of them have no integration documentation and those which do have, they use an Android or iOS SDK and communication happens via a mobile phone. Using a more “proper” card terminal or one of those pre-certified for unattended transactions seemed impossible as their suppliers do not avail such information to anybody (unless perhaps you want to spend serious money with them?). The other difficulty with card terminals is that even if you manage to integrate with one, you are sort of locked to the payment provider than goes with it and the country the terminal is intended for.
Card terminals
Financial regulations mean that you cannot really be agnostic when it comes to card terminals. But as long as you can find a vendor who will provide technical information on how you can talk to their card terminals, then you’re halfway there.
All in all, my research had shown me that using Windows as the kiosk platform would allow maximum flexibility for hardware. This meant that you can use literally ANY Windows-based devices (tablet, laptop, or big proper kiosk) and connect ANY printer to it and you pretty much have your kiosk there – minus the card terminal and the software.
The Food-Ordering.com system is natively web-based. As we all know, a website cannot control and communicate a piece of hardware. There is, of course, the WebUSB API but it is experimental technology and not widely supported.
Here’s where the “fun” starts. We know that our kiosk software has to be a Windows application. And in Windows it is possible to embed a web browser component (aka WebView) within the application. So if we kept the same web application pretty much as is but made the Windows application communicate with it, then we could pick up on the total amount that needs to be charged from the web application, pass it on to the Windows application, then tell the card terminal to charge that amount and, upon a successful payment, print a receipt using Windows (since all printers come with Windows drivers) and communicate back to the web application that the transaction was a success and let the web application show its normal thank-you page.
All this means that we can use ANY Windows device, ANY printer and a card terminal (which can talk to a Windows application and pre-certified in our country of use) and you have a self-ordering kiosk from a starting price of something like £200. Or at least it is up to us now to choose what kiosk device we want to use.
All that’s missing is to adapt the existing web application and create a version of it that is styled in a way which has the look and feel of a kiosk. And there you have it – a full-blown self ordering kiosk solution which works with the hardware and price point of your choice while at the same time allows you to re-use your existing web application.
That’s how the Food-Ordering.com kiosk application was born, running on the kiosk device of your choice, using a printer of your choice, without having to re-invent the wheel.
