On Thu, Feb 18, 2010 at 3:42 PM, Daevid Vincent <dae...@daevid.com> wrote:

> I'll confess that I've done almost zero research on this topic as of right
> now aside from pricing readers and blank cards.
> So we're opening a new super-club here in Seattle. One of the ideas we'd
> like to pursue is that people are assigned a card. This can be a magstripe
> card or something with a barcode. Not really sure at the moment which way
> to go.
> The idea being that when they enter, we "swipe/scan" their card and we can
> log stats (# of visits, # guests, favorite drink so the bar has it ready,
> enter into contest, etc.) I was thinking we setup a simple netbook with a
> USB reader at the front door when they pay. Then we have another back at
> the bar. Connect via WiFi. Have a notebook somewhere behind the scenes that
> runs LAMP (or a VM thereof). No internet needed.  The backend database and
> even web/GUI stuff is of course trivial with any LAMP stack.
> What I don't know is how do I interface _to_ PHP from say a magstripe
> reader. They're dirt cheap ($50), but I assume come with zero software.
> http://www.kanecal.net/mag-stripe-reader-scanner.html . And there are
> hundreds of these gadgets out there all the same basically.
> I guess what I'm hoping for is some pointers, from someone who's done this
> sort of thing.
> My gut thought is something so simple, where there is some XP software (or
> Linux I suppose) that reads the card (and generally they only have a number
> encoded on them) and this is sent via a URL we define, such as
> or
> etc. (ignore the security issues
> and all that. It's trivial to encode the parameters, plus it's a closed
> system with WEP/WPA/WTF). But does anyone know of such a key piece of code?
> Like I said, I'm not locked into magcards. It could be a barcode reader
> just as easily. Or fingerprint scanner, or facial recognition. In the end
> it's just a unique "thing" that maps to a unique number. I just need the
> "FM" (F*ckin' Magic -- it's a programmer term -- look it up!) that goes in
> between PHP and the hardware.


ok, so it all started out a few years back when i started a company set out
to build a wireless capture portal.  we wanted to integrate with a 2-Touch
POS which had 'gift cards' which were magcards.  the idea was someone buys a
drink, the clerk swipes the card and the customer gets a window of time on
the internet.

so heres the deal (on linux [likely similar on other OS' though not sure on
the implementation there]).  when you attach a usb card reader, barcode
scanner or similar, if you have linux USB HID (HumanInputDevice) support the
kernel magically uses the module to treat input from the device as keyboard
input; simple right...

well this only works iff you have a terminal for the output to arrive at.
if you dont it goes nowhere (likely /dev/null or similar).  so if you want
something quick and dirty, a laptop or any box w/ a full window manager or
just a terminal will capture the output.  but thats for newbs (haha)...

the way we rolled w/ my product was w/ a linux server, running as the local
gateway w/ a full lamp stack to provide a UI for the business owner and the
customers.  new problem - how to capture the output of the device w/o a
terminal or UI on the server.  to cut to the chase we ended up developing a
*user space* driver for the card reader via libusb (which is cross-platform
btw).  i started out trying the java wrappers, but they all sucked ass.. so
ended up going w/ C.

basically, we wrote a simple single threaded daemon which sits and listens
for card swipes, once the card is swiped, the daemon uses the C system()
function to invoke a configurable executable program (which in our case was
a php script :)) and passes the captured info from the card via the shell.

the code is semi-generic but frankly we stopped off where our needs did at
the time.  the only real limitations are:
. it only provides a fraction of the info from the card (all info could be
passed ideally)
. it has hardcoded values for a minimag card reader (easily changed - these
are just values to identify the proper hardware in the USB tree and bind to
. single threaded - it would be nice to have a main listener thread and fork
child threads to process the swipes (thats where binary from the device is
converted to ascii based on the usb2.0 spec) believe it or not you can
actually send 2 swipes before the first one is processed w/ a single thread
if you swipe it quickly enough!
. dependent on glib for some string functionality - i think it would be nice
to see it have as few dependencies beyond libusb (and pthreads if ever it
was threaded), though glib is quite common afaik

we originally ran the software on gentoo, but it could be packaged up for
pretty much any OS afaik since libusb is cross-platform.

anyways, if this is interesting at all im happy to share the code.  i was
planning to touch it up a bit at some point but dont have the time atm.  i
would be happy to help someone work with the code to tie it into their
system and put it to good use.


Reply via email to