Magnetic License
August 3, 2012 11:32 AM Subscribe
How can I automatically populate some fields in a program from a driver license using a magnetic strip reader?
I'm looking to fill customer information automatically in our management software using a card swiper and the customer driver license. Right now, our customer info is hand-typed into the software but we would like to cut down on the time it takes to get people using our services. This is FL if it matters.
I've purchased this MSR and downloaded the programming software but trying to make sense of either the program or how to get the info into the correct fields is eluding me.
When I swipe the license, it puts out a long line of crazily formatted info from three tracks of info. The computer sees the strips reader as a USB keyboard and when I swipe my license into a text file, the first track returns (the first is STateCITY):
%STCITY^LASTNAME$FIRSTNAME$MIDDLENAME^123 FAKE ST^
while the second track brings the license number encased in another set of numbers, 1 being the driver license number:
;0000000011111111111=2222222222222=?
The third track has the zip code only (!?).
The software is completely arcane, in that there is not a single bit of instruction or help included. I've done quite a bit of reading but I've found scant info on the technical details of how this is can be achieved.
Has anyone done something like this and managed to figure it out? I would be willing to spend more money on a MSR if there was software that would help do this easier, I just need to have a suggestion. Thanks!
I'm looking to fill customer information automatically in our management software using a card swiper and the customer driver license. Right now, our customer info is hand-typed into the software but we would like to cut down on the time it takes to get people using our services. This is FL if it matters.
I've purchased this MSR and downloaded the programming software but trying to make sense of either the program or how to get the info into the correct fields is eluding me.
When I swipe the license, it puts out a long line of crazily formatted info from three tracks of info. The computer sees the strips reader as a USB keyboard and when I swipe my license into a text file, the first track returns (the first is STateCITY):
%STCITY^LASTNAME$FIRSTNAME$MIDDLENAME^123 FAKE ST^
while the second track brings the license number encased in another set of numbers, 1 being the driver license number:
;0000000011111111111=2222222222222=?
The third track has the zip code only (!?).
The software is completely arcane, in that there is not a single bit of instruction or help included. I've done quite a bit of reading but I've found scant info on the technical details of how this is can be achieved.
Has anyone done something like this and managed to figure it out? I would be willing to spend more money on a MSR if there was software that would help do this easier, I just need to have a suggestion. Thanks!
I don't think the programming software will help you, because you are using state-issued driver's licenses and the programmer is only going to help with putting information in, not parsing it out. And again since they are state-issued you are stuck with the formatting they use, which is apparently the AAMVA standard. It looks like the third track uses non-standard data that your card reader can't read properly.
So with your hardware, you're probably only going to be able capture the data from the first two fields as keystrokes. The reason it's designed that way is so that the manufacturer doesn't have to deal with creating special drivers and whatnot, it's automatically compatible with any program. That makes parsing it awkward though. When you say "our management software" is there any way to modify that software to parse out the data? Somehow you're going to need to have an application that takes those keystrokes, parses the data, and does whatever it needs to with the parsed data to get it in your system.
posted by burnmp3s at 12:16 PM on August 3, 2012
So with your hardware, you're probably only going to be able capture the data from the first two fields as keystrokes. The reason it's designed that way is so that the manufacturer doesn't have to deal with creating special drivers and whatnot, it's automatically compatible with any program. That makes parsing it awkward though. When you say "our management software" is there any way to modify that software to parse out the data? Somehow you're going to need to have an application that takes those keystrokes, parses the data, and does whatever it needs to with the parsed data to get it in your system.
posted by burnmp3s at 12:16 PM on August 3, 2012
Have you looked at this page? Unfortunately the link to the AAMVA spec there is dead, but might be available here.
If you're seeing the actual DL# in the stream, the reader is almost certainly working properly. You'll need to look at the spec to see how to parse the output for the information that you want, though.
I've never used a magstripe scanner but I've worked with barcode scanners that did the same simulated-keyboard thing and I just parsed them from stdin using commandline utilities. Not elegant but it worked. I've seen cash register programs for taking credit cards that obviously worked the same way, too: they required the cashier to put the cursor in the CC# field on a webform interface, then swipe the card, and that field would be populated. If they swiped it too early, it would end up in the wrong field. Kludgy as hell, but this was on a production system in a retail store.
posted by Kadin2048 at 12:18 PM on August 3, 2012
If you're seeing the actual DL# in the stream, the reader is almost certainly working properly. You'll need to look at the spec to see how to parse the output for the information that you want, though.
I've never used a magstripe scanner but I've worked with barcode scanners that did the same simulated-keyboard thing and I just parsed them from stdin using commandline utilities. Not elegant but it worked. I've seen cash register programs for taking credit cards that obviously worked the same way, too: they required the cashier to put the cursor in the CC# field on a webform interface, then swipe the card, and that field would be populated. If they swiped it too early, it would end up in the wrong field. Kludgy as hell, but this was on a production system in a retail store.
posted by Kadin2048 at 12:18 PM on August 3, 2012
Response by poster: Thanks for the clarification on these points, everyone. I was expecting that the card reader could be programmed to clean up and input certain parts of the data into the form but I see now that that is not the case.
As for scanning and OCR, we've looked into doing it this way but the license scanners are a lot more expensive than the swiper. We have 10 locations we'd need this set up on so that becomes prohibitively expensive but it's the way I'd rather do it, TBH.
What methods have you used to get the info into the forms after reading and formatting? I assume a Java or .Net applet, but I'm interested to hear about how you've implemented it.
posted by dozo at 2:10 PM on August 3, 2012
As for scanning and OCR, we've looked into doing it this way but the license scanners are a lot more expensive than the swiper. We have 10 locations we'd need this set up on so that becomes prohibitively expensive but it's the way I'd rather do it, TBH.
What methods have you used to get the info into the forms after reading and formatting? I assume a Java or .Net applet, but I'm interested to hear about how you've implemented it.
posted by dozo at 2:10 PM on August 3, 2012
I see that your location is listed as Florida, but do note that it's illegal for businesses to save data from swiping DLs in Texas and New Hampshire, if you have locations there.
posted by fiercecupcake at 2:51 PM on August 3, 2012
posted by fiercecupcake at 2:51 PM on August 3, 2012
Create a text box on your application that accepts the data as formatted by the card swiper. Then use text parsing logic to pick out the relevant data and pop it into the right text boxes in the application.
If you don't have control over your application, you'd basically need to create one that sits between the swiper and the end product.
posted by gjc at 2:55 PM on August 3, 2012
If you don't have control over your application, you'd basically need to create one that sits between the swiper and the end product.
posted by gjc at 2:55 PM on August 3, 2012
Response by poster: I don't have much control over the program, although there is an API. I'm not sure what functionality it exposes but I don't think this is something I can interface with. I'll ask their devs and see what I can do.
posted by dozo at 5:48 AM on August 6, 2012
posted by dozo at 5:48 AM on August 6, 2012
This thread is closed to new comments.
Most vendors that provide the hardware also provide a software development kit for interfacing with the hardware and processing the data associated with it. Part of this kit will decode the information into the different fields you are looking for. The encoding on some of the devices can be a challenge. The vendors will also usually provide a set of working source code that compiles to a reference implementation/application that can read and decode the information. You can take that code and use it as an example to work from.
I'm not familiar with this hardware, but I have the name of one of the vendors I use that does this well. If you are interested, I will MeMail their information to you.
posted by boba at 11:55 AM on August 3, 2012