Magnetic Gift Card Swipe + CF Form

The following code is some javascript I wrote back in 2000-2001. It still works today in all the browsers we support but since it is old code, it can be improved upon by using regular expressions, etc. to parse the incoming keyboard data more efficiently.

Useage overview:
Include the main js file (the code below - I call it cardSwipe.js)
Override the csPopulate function which is automatically called upon a swipe detection
Install the onKeyPress event

The csPopulate function will need to be adjusted to match your form and field names.

Hope this helps. Good luck.

tclaremont wrote:
> What I
> was trying to explain is that there IS no programming made by the card reader
> manufacturer.

There *is* some type of programming made by the card reader manufacturer
otherwise a card reader ain't going to do anything when a card is run
through it.

There is no programming done by the user of a card reader, the
manufacture has taken care of it for you.

But I don't believe you are saying that just passing a card through an
empty box with a slot in it connect to your computer is going to do
anything.

The point that seems more complicated than it really is; is your implication that the client programming was created by the card reader manufacturer. What I was trying to explain is that there IS no programming made by the card reader manufacturer. Whatever YOU encode onto the card gets passed to the client when the card is swiped. There is no intelligence to speak of. Whatever is encoded on the mag stripe gets entered into your form. This simplicity is the part that suprises many people that want to make use of a system such as this. Encode a unique number onto the card, log that same number into your database, and wait for that card to be scanned anywhere on the planet with internet access to your site.

Of course, you will no doubt want to add additional fields, such as an ID number associated with your business. You don't want someone scanning a card from XYZ corp and having it come up a match with your company. Common sense will dictate your direction here. Use a UUID number when you encode the card. Easy enough.

tclaremont wrote:
> Ian, you might be making this more difficult than it needs to be. Of course,
> without more information, I might be making it EASIER than it should be.
>
> My experience is with keyboard wedge style mag stripe readers. When a card is
> scanned, the puter just thinks it is being typed by the end user. There is no
> intelligence to determine that it is a mag stripe, etc.
>

Not difficult. I think we are explaining the same thing in different
ways. The point I was trying to make was that ColdFusion as no
knowledge and does not care how that form was filled in or completed.

As you described, the 'keyboard wedge style mag stripe reader' dumped
its data into an HTML form. This was accomplished by client programming
created by the card reader manufacturer.

ColdFusion then processed the form it received. Again it had no idea
how that data got into a form. All it knows is that it received a form
and did something it was told to do with the information contained within.

Just to hammer the point has hard as I can. ColdFusion is the server
and has no idea of what the client does. The reader is the client and
just does what it was told to do to send the data to a server.

Ian, you might be making this more difficult than it needs to be. Of course, without more information, I might be making it EASIER than it should be.

My experience is with keyboard wedge style mag stripe readers. When a card is scanned, the puter just thinks it is being typed by the end user. There is no intelligence to determine that it is a mag stripe, etc.

To experiment, create two CFM pages. Page1.cfm and Page2.cfm

On Page1.cfm place a single input box within a CFFORM. NOTHING else on the page. Set the form to autofocus on that input box. Set the CFFORM action to Page2.cfm

On Page2.cfm, just put a <CFDUMP> to display the values submitted from Page1.cfm.

View page1.cfm and scan the card.

Upon scanning, the form will submit. Therefore, what you should see is Page2.cfm with the contents of the mag stripe within your CFDUMP table. The data will probably be delimited in some way. It depends on how the card was encoded. For your stated purposes, I can't see the card needing any more than a single ID number of some sort. This would equate to a key field in your database. ALL of the important information would reside in your database.

Now that you have the card information on Page2, you can query the database using the number that was obtained from the scan.

SELECT *
FROM mytable
WHERE ID = #Form.ScannedNumber#

Now you have all of your information with regard to that particular card. Use the returned information to populate a form to display to tne end user, or whatever you want to do with it. You can credit or debit the value in the database as you see fit.

Oh yeah... You state that this is a gift card. Make sure you DO NOT encode the value remaining ONTO the gift card. Just store a unique value that identifies the gift card, and store the balance in your database.

Why? Because card encoders are very inexpensive, and it would not take much effort at all for an unscrupolous end user to rewrite the card with a higher available balance any time they wished. By storing the balance in your database it allows you to keep your financial records in order, too. You will know how much credit is outstanding at any given time, etc.

Easy enough, since you are responsible for the encoding of the card.

The card reader is dumb, in a technical sense. When you scan the card, the card reader merely sends the contents of the magnetic stripe to the application, just as if sent by a really fast typist. Now, becuase of this, you, as the programmer, will need to parse the text string that is returned in order to extract the distinct field values.

To start, I recommend hooking the mag stripe reader to your local workstation. Open up notepad, and then scan the card. What do you get?

In my application, I record ONLY numbers. Therefore, upon scan, I immediately apply logic that removes any non-numeric characters. I do that like this:

#ReReplace(Form.SannedData,"[^0-9]","","ALL")#

This removes the customary begin and end characters from the scanned data, too.

Since you are including multiple fields, I predict that you will wind up with a delimited list of values on that card. This is totally dependent on the way you set up the writing on the card though. Only you can answer how you did it.

Next step is to parse the value that is returned, and then insert those values into your database.

Ask questions here if you need more help.