Kiosk software guidance

I need to develop a kiosk system. The only payment option will be a credit card/debit card. The kiosk need to be networked with another PC. For example, if a customer orders something on the kiosk, it needs to be sent to a another pc where a store employee can see what was ordered.

Here are my following solutions:

OPTION 1) web based application

Use FLASH, ASP.net, or JAVA for user interface?

If I take this route, how can I communicate with the credit/debit card reader? The reader will be installed on the kiosk, but the kiosk software will be on the web. Would I have to create a secure connection to communicate with the reader?

OPTION 2) create an application on the kiosk

Use FLASH, JAVA, Windows presentation layer with.net?

How can I communicate with the card readers?

Which option is the best? 1 or 2? JAVA, FLASH? WINDOWs .net? What about linux? Is it easy to develop kiosk aps in?

Thank you for your help.

回答1:

Speaking as someone who has actually implemented a Flash application targeted for a kiosk environment, I would highly recommend against using it for the following reasons:

The memory management is not good enough to leave an application running unattended for days/weeks at a time. It will leak memory and you will eventually have to restart it. Just Google for 'Flash memory leak' to get an idea of how many issues there are with it. They've supposedly improved memory management in the most recent versions, but to be honest, Flash is mostly targeted at the browser where users will close the Flash tab/window after interacting with it for a few minutes, so they haven't spent very much time optimizing its memory usage.
The error handling isn't robust enough to deal with an extended running environment. If your app throws an error for any reason, the player will basically stop completely until you restart it. Writing to error logs is also more difficult than it should be due to (3).
You are sandboxed in a Flash environment and can't directly access things like card readers or other external devices, or write to the system. Using AIR might help you get access to the file system, but not much beyond that. If you want to access external devices you'll have to write a proxy that sits on the client and sends the relevant data to Flash via a socket. If you do decide to use sockets to communicate with your Flash client, be prepared to pull your hair out deciphering Flash player's security policies.

Basically Flash was built for an entirely different environment than a kiosk, and therefore is not very well suited to the task. I would also recommend avoiding using a web based interface, because of the same difficulties associated with accessing hardware devices. Oh and for the love of god don't run Flash on Linux. The Linux Flash player is 234234 miles behind the Windows version and will give you a massive headache.

As far as communicating with the card reader, generally you interface with a card reader over USB, and the card reader can be placed into 'keyboard wedge' mode or HID mode. In keyboard mode the card reader will read a card swipe and output a plain text string containing the swipe contents as if it were a keyboard, and you need to parse that string to get the data out you want. HID mode is a little cleaner and you interact with it by reading swipes off of the USB device.

Of the options you listed, your best option (unfortunately) is probably writing some kind of Java or .NET app that can stand to run in a 24/7 environment. If you need to access printers or other hardware devices (to automatically print a receipt for example), then Java and .NET have very good support for the OPOS standard, which is the standard interface for talking to receipt printers. As far as Linux vs Windows, I've seen both used successfully.

BTW if your application is processing credit card data, don't forget about PCI compliance :).

回答2:

Use a Web based application and write the UI in HTML5.

As for the software on the kiosk, I recommend Webconverger. Disclaimer: I'm the founder of this open source project.

You should get an independent payment device and match up the receipts manually.