We support something similar in our records management software. Our application is designed to work with a wedge reader, since they are the easiest to get up and running (no special drivers needed). When a card is swiped, the reader sends keystrokes to the OS for each character that is encoded on the magnetic stripe, with a simulated Enter keypress between each track (an AAMVA-compliant license has 3 data tracks). It's slightly annoying because it behaves exactly as if someone was typing out the data by hand, so there is no easy way to tell when you have all the data (you could just wait to get 3 lines of information, but then it's difficult to detect invalid cards, such as when someone tries to swipe a student ID card, which might have fewer than 3 tracks encoded; in this case, the application hangs forever waiting for the non-existent third track to be received).

To deal with this, we use a 'fail-fast' approach: each time we get an Enter keypress, we immediately process the current line, keeping a record of which track we are expecting at that point (1, 2, or 3). If the current track cannot be processed (for example, a different start character appears on the track that what is documented for an AAMVA format driver's license), we assume the user must have swiped something other than a driver's license. I'm not sure if the reader we use supports reading image data or not. It can be programmed to return a subset of the data on the card, but we just use the factory default setting, which appears to return only the first three data tracks (and actually I believe image data is encoded in the 2D barcode found on some licenses, not on the magnetic stripe, but I could be wrong). For more on the AAMVA track format that is used on driver's license magstripes, see Annex F in the. The basic approach we use is: • Display a modal dialog that has a hidden textbox, which is given focus.

2D Area-Imaging Presentation Scanner with Driver's License Parsing*. EasyDL Driver's License Software. Scanner With EZ Drivers License Parsing Software. “The Drivers’ License Parsing Application is now part of the Datalogic Aladdin™ software configuration program.

Reading File Complete. The dialog box simply tells the user to swipe the card through the reader. • The user swipes the card, and the reader starts sending keydown events to the hidden textbox.

• The keydown event handler for the textbox watches for Enter keypresses. When one is detected, we grab the last line currently stored in the textbox, and pass it to a track parser that attempts to parse the track according to the AAMVA format.

• If this 'fail-fast' parsing step fails for the current track, we change the dialog's status message to a message telling the user the card could not be read. At this point, the textbox will still receive additional keydown events, but it's OK because subsequent tracks have a high enough chance of also failing that the user will still see the error message whenever the reader stops sending data.

• If the parsing is successful, we increment a counter that tells the parser what track it should process next. • If the current track count is greater than 3, we know we've processed 3 tracks. At this point we parse the 3 tracks (which have already split most of the fields up but everything is still stored as strings at this point) into a more usable DriversLicense object, which does additional checks on the track data, and makes it more consumable from our application (converting the DOB field from a string into a real Date object, parsing out the subfields in the AAMVA Name field into first name, middle name, last name, name suffix, etc.).

If this second parsing phase fails, we tell the user to reswipe the card. If it succeeds, we close the dialog and pass the DriversLicense object to our main application for further processing. I wrote a parser in C#, and while it's 'ok' it's still far from perfect. I can't seem to find it but a Wikipedia entry used to exist that has the patterns to look for (trust me, parsing this yourself is a pain without any help). Be aware that different states have different laws for what you can and can't use government issued ID's for.

Texas has one. We use a dell card reader and it inputs it exactly as though it were being typed through a keyboard, followed by the enter key.

This made programming /very/ easy because then you just send focus to the text box and wait for enter. The main keys which break it in to chunks is the carrot '^'. Break that and you'll have your basic chunks.

I'm working on a JavaScript project that involves reading credit cards and driver's licenses from a USB magnetic stripe reader in keyboard emulation mode. It turns out getting credit cards working was extremely easy, as they're all in the same format. However it quickly became clear that driver's licenses are much harder, as even within a single state (CA) the format varies from one card to the next. In any case, the goal is to take the raw data from swiping a driver's license (using a magnetic stripe reader) and extract the number from it, in a way that produces the correct number for as many U.S. States as possible (all 50 would be amazing). Worth mentioning is that I am not particularly concerned with validation, at least not at this point. Has anyone else already done this, and packaged it all up in a library (either free or commercial) I could use?