Can HTML5 Communicate with Peripherals Like Scanners and Credit Card Readers

Can HTML5 communicate with peripherals like scanners and credit card readers?

UPDATE (Jan 16th, 2019): The Credential Management API has been announced. It's currently only supported on Chrome and Opera but it's looking promising. Google Developers wrote an article elaborating on the spec.

UPDATE (Dec 28th, 2016): Another couple years gone, and another update. This one will be more focused on two new developments than anything else. See the new "WebUSB & Web BlueTooth" section under "Full Device API". But the answer remains the same.

UPDATE (Nov 3rd, 2014): It's been just over two years since the original post was made, but the answer remains mostly the same for now. We are, however, closer to your original goal in several areas.

ORIGINAL ANSWER:

There would be a number of ways to go about this.

Background

The HTML5 specification has entered into the "Recommendation" state. This means that HTML5 is pretty much set for what it looks like. However, I will be using HTML5 in the same way that every marketing person in the world has decided is best. That is, I will not be talking about HTML. Well, I will, in so far as you will utilize it from an HTML page, but not really. What I'll actually be discussing is JavaScript (JS) and that's a horse of a different color. But for all intents and purposes, we're putting it all under the same heading as HTML5, which has been decided to mean "shiny and new" now.

Also, the items which I am discussing will vary in support. Some are very browser dependent projects (like Chromium specific implementations), and some are more standards driven projects that may not have browsers implementing or experimenting with them yet. I'll try to distinguish between the two as I go along.

Full Device API

Status: Incoming, but not ready

Being able to access devices from the browser is making slow but steady progress. Right now, many modern browsers have access to some of the more common devices like the camera or gamepads, but they are all high level APIs. Browser vendors, the standards groups, and lots of companies involved with the web are all trying to make webapps just as powerful as your local applications.

But the APIs you are looking for are still in progress and a ways off. For your particular case, and for the more general case of connecting your webapp to most devices, we're still a few years away from something we can use. If you want to see what awesome things are coming up in that field, here are just a select few items that may help you directly:

Web Near Field Communication (NFC) API

This one unfortunately may be dead in the water for now. But it looks like originally some folks at the W3C (mostly Intel it looks like) were looking at adding a NFC API to the web.
Media Capture Streams

The WebRTC group is working on programmatic access to media streams like the camera which would allow to integrate things like barcode scanning or other features. This has reached CR status and is available in browsers, but is less helpful on its own.
Web Bluetooth

If you had bluetooth capable tools, this API would help you connect with them from computers and devices that were able to listen and connect. The primary driver for this at the moment seems like it is the Chrome team, including an experimental implementation, but I wouldn't consider it anywhere ready to use yet (See "WebUSB & Web BlueTooth" section).
WebUSB

This would allow full access to low level USB information including listing devices and interacting with them. Same as Web BlueTooth, this seems to be current Chrome pet project, but I also wouldn't rely on it (See "WebUSB & Web BlueTooth" section).
Network Service Discovery

If you have other devices or items on the network which broadcast and use HTTP, this API would allow you to discover and interact with these services. No browser implementation, but it is in a working draft for the W3C.

Originally, Mozilla was pushing a number of these forward because of Boot2Gecko (or Firefox OS). However, with that project officially cancelled, we aren't seeing much progress from them in these areas now.

Members of the Chrome team, however, seem to have decided to dive in and start not only working towards these, but putting them live in browsers. Which leads us to...

WebUSB & Web BlueTooth

Like sausages, it's better to not know how Web Standards are made

-Abraham Lincoln (probably)

There's been a little bit of buzz in this area as it looks like the Chrome team snuck in these as experimental features and developed their own specification for it. Which is great! Just maybe not in the way that you were hoping for.

Each browser vendor and W3C contributor group has their own style and makes contributions towards the specs in their own way. The result is usually a fairly decent specification that the browsers have agreed upon. But getting from nothing to something is... messy. Real messy. And is quite a process a lot of times. It doesn't always result in a good spec (yeah, I'm talking about you Florian compromise...) but even when it does, it takes a while.

However, It seems like Google developed this version of the spec all on their own. And, in my experience, Google's approach to the specs is always a little... well... setting my personal opinions aside we'll say "gung-ho". They tend to just dive right into the deep end. And that seems to be what they've done here.

I highly doubt these specs or implementations will look anything like this when they become standards. And there's nothing wrong with that. That's part of the process. But I wouldn't go relying on this implementation or developing any code or products against it. This is an unprecedented feature on the web and all the browser vendors are gonna want a big say in this.

That said, this is actually good. One of the things Google often does (for better or worse) with situations like this is forces the conversation and it can push things along. And having a feature shipped in the browser, even an experimental feature, can turn up the heat on the demand for it. So we may see more progress in this area soon.

PhoneGap Apache Cordova. You know, for your phone

Status: Not fully featured and phone only

Apache Cordova, previously Adobe PhoneGap, is a way to write your program in HTML, CSS, and JS that allows you to access lower level functionality on things like phones, and compile across devices. This would be a way to implement your program, but it would be a phone application, not necessarily a desktop one. An option to consider, and something I figured I would mention.

Cordova implements a few of the above features already, but doesn't have some of the more powerful ones like NFC or BlueTooth.

The Native-App solution (for Windows 8)

Status: Possible, but OS specific and desktop app

Windows 8 offers the ability to build applications in HTML and JS. This would allow you to easily access lower level functionality on the OS via their API. From the looks of it, it is pretty extensive and you can do a lot. You mentioned cross OS support, however, and this obviously limits you to one OS.

It's so Flash-y!

Status: Dying/Dead, not possible as a web app

Flash won't have direct access to the system through the web. You could create an AIR application, but that will sort of defeat the purpose of having it web based. In addition, Flash support on mobile, and on the web it would seem, is on the decline.

NodeJS

Status: Can be a bit of a pain and only possible as a desktop app

NodeJS and JS applications have sort of been a hot topic the last couple years. I didn't discuss it in my original post because I felt it wasn't quite there yet. However, things have progressed and it is much closer to being ready for this sort of thing, and has the support and power of a growing user base. That said, for your particular case, I wouldn't recommend using it. It would have to be local on the users machine, and because of how NodeJS (and similar engines) are at the moment, it would require a lot of extra configuration and setup that would complicate things a bit.

So you could build an app using HTML, CSS and JS with NodeJS or similar engines and have low level access to what you need, but it has to be local, and it would take more work than I'm sure you want to do every time you'd like to install it for a customer.

... Now where was I?

So where does that leave us? Well, simple: if you want a single language/set of code as your code base, HTML/CSS/JS aren't a great option... yet. But they could be some day. For now, your options are limited to what you feel is best for your customer. Java is a stable option you listed, but obviously comes with its own drawbacks. As the web develops, I think we'll see a lot of really cool things coming out of the new functionality, but we've got a ways to go still.

Accessing scanner at client side from a web page without applet

Atalasoft has a web scanning toolkit that should meet your needs:
Atalasoft WingScan product page

The product does not use browser-specific plugins and therefore works nicely in all modern browsers (IE8+, Chrome, Firefox).

Architecturally, there is a small local component that should be installed, which exposes RESTful web service. Web page uses standard JavaScript/jQuery to communicate with the service and scan/import/enhance images.

Here is the online demo, so you could try it out right away: Wing Scan Demo page

The scanning component is based on the EZTwain library, and it includes a number of image processing algorithms that improve quality of scanned images (deskew, autorotate, blank page detection, etc.)

You can optionally license and use embedded VRS technology, which I have to say is impressively good at cleaning up scans.

Read Credit Card With EMV Chip and Write Data Into Web Browser-Based POS Screen

I think you're looking for a so-called 'keyboard wedge'. I haven't heard of anything out-of-the-box like that for chip readers.

However if all you need is to read the card-number (and not perform full EMV), then you could create one yourself fairly easily. Are you able to create a standalone application (perhaps written in c++) that runs all the time, and can act as the device 'listener'? I.e using your choice of SDK, wait for card-events and, invoke the command(s) to read the necessary EMV tag (5A?)

You then trigger the keyboard event for each digit in the card number (as explained here), followed by a [enter] event. With a text-input within your browser having focus, that could effect a simple form submission with the card number.

Communication with an external (hardware) pushbutton

The USB keyboard class HID seems the best to me. You can use different scancodes than standard keyboards, or less often used like those used for app-specific buttons on some keyboards. (Note that current X.Org drivers are still limited to scancodes < 256.)

Probably it's not hard to find a reference HID keyboard implementation for your device, too.

Serial ports are rare in modern PCs and especially notebooks; even if the system board has RS232 circuitry it has no external connector.

Writing a custom driver for the PC side means much more work and more space for bugs. You're far safer using a time-proven standard driver.

Can HTML5 Communicate with Peripherals Like Scanners and Credit Card Readers