We support something similar in our recording management software. Our application is designed to work with a wedge reader, since they are easiest to start and run (no special drivers are required). When the card is pumped out, the reader sends keystrokes to the OS for each character encoded on the magnetic stripe, with a simulated press of the Enter key between each track (AAMVA-compatible license has 3 data tracks).
This is a little annoying because it behaves exactly as if someone were typing the data manually, so there is no easy way to tell when you have all the data (you can just wait to get 3 lines of information, but then it's hard detect invalid cards, for example, when someone tries to carry a student’s identification card that can have less than 3 tracks encoded, in this case the application freezes forever, expecting that a non-existent third track will be received). To cope with this, we use a "fault tolerant" approach: every time we get hit Enter , we immediately process the current line, keeping a record of what track we expect at this point (1, 2 or 3). If the current track cannot be processed (for example, a different start symbol appears on the track that corresponds to the document for the AAMVA format driver license), we assume that the user should have pulled out something other than the driver license.
I am not sure if the reader supports reading image data or not. It can be programmed to return a subset of the data to the map, but we just use the factory default setting, which seems to only return the first three data tracks (and, in fact, I believe that the image data is encoded in a 2D barcode, found on some licenses, not on the magnetic strip, but I could be wrong).
For more information on the AAMVA track format used on magnetic strips of driver licenses, see Appendix F in the current standard .
The main approach that we use:
Display a modal dialog box with a hidden text box that is given focus. The dialog box simply tells the user to swipe the card through the reader.
The user views the map, and the reader begins to send key change events to a hidden text field.
The keydown event handler for the text box monitors Enter keystrokes. When someone is discovered, we take the last line, which is currently stored in the text box, and pass it to the track parser, which tries to parse the track in accordance with the AAMVA format.
If this “unsuccessful” parsing session is not performed for the current track, we change the dialog status message to a message informing the user that the map cannot be read. At this stage, the text field will still receive additional events related to the recording, but this is normal, because subsequent tracks have a high enough chance that the user will still see an error message whenever the reader stops sending data .
If the parsing is completed successfully, we increase the counter, which tells the parser which trace it should process next.
If the current number of tracks is more than 3, we know that we processed 3 tracks. At this stage, we analyze three tracks (which have already divided most of the fields up, but are still saved as lines at this point) into a more convenient DriversLicense object that performs additional checks of the track data and makes it more consumed from our application ( DOB field conversion from a string to a real Date object, parsing subfields in the AAMVA Name field to first name, middle name, last name, suffix of the name, etc.). If this second phase of the parsing fails, we tell the user to re-paint the map. If this succeeds, we close the dialog and pass the DriversLicense object DriversLicense our main application for further processing.