Question

We are designing a self-service kiosk for Windows machines that allows customers to order online through a touch-screen website, pay through an attached chip-and-pin card reader, and then print off the order number with a receipt printer.

Essentially, we're looking for kiosk software that allows a website to communicate with the installed hardware on the device. If that's not possible, could anyone advise a different approach to the problem? Using a website for ordering is the non-negotiable.

Was it helpful?

Solution

Having worked on several projects for this kind of scenario, I can tell you straight away that communicating to the hardware from a web only client is not going to happen.

Even now, 2 years after this was originally posted in the glory days of HTML5 there are still some elements of hardware that are just never going to be available direct from HTML and/or JavaScript code.

However.... that's NOT to say that it's impossible to do

It just means that you have your work cut out for you.

First off, each and every kiosk will have to have installed on it, it's own personal web-server or some description.

I don't mean the you absolutely have to have Apache, IIS, Nginx or what ever installed (Although it does make things easier) but you will have to have some kind of native binary installed on the platform that has the ability to talk to the hardware.

I work a lot in .NET, so in the past I've elected to have a windows service application running, and then exposing a set of json endpoints using something like NancyFX.

This service would run in the background, listening on some defined socket.

This service could also be responsible for delivering the actual HTML code for the kiosk pages too (But that would be easier, serving them off a static server like Nginx)

The HTML then simply has to use JQuery, Knockout, Angular or any other framework that will allow it to make calls to these Json endpoints to control the various bit's of hardware.

Much of the hardware, such as chip & Pin pads, Card readers, Receipt printers are all controlled from Serial Ports, so talking to the actual device once you have the protocol guides, is usually very easy.

I know you made a point of saying the HTML bit is non negotiable, but for what it's worth, scenarios like this are still prime time for technologies like Silverlight and Flash.

Most of the stuff Iv'e worked on, have had a fairly mediocre PC build inside of them, installed with a windows server based OS, a copy of IIS running, and a layer of service apps running against the hardware. IIS then delivers a single HTML page, which launches a Silverlight based full screen touch based UI, that then can talk directly to the services via RPC and/or WCF.

The whole scheme of things works really well.

If your working on a *nix system, then you'll likely want to write a bunch on daemons fro the service layer, and apache with mod mono should allow you to do a .NET UI running on a non .NET platform.

OTHER TIPS

KioWare, a kiosk browser lockdown software, has recently added support for chip and PIN devices in 32 countries by integrating their software with ChipDNA, an API offered by CreditCall payment gateway.

I've used KioWare, and it does work well.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top