Magnetic Gift Card Swipe + CF Form

[Ssirseth]

Hey everyone!

I got one for you - possible challange? Maybe it cant be done? I dont know.

Basically I am trying to setup a test application so that when a plastic magnetic gift card (that I encoded) is swipped with a magnetic card reader - I want it so that when it is swipped it actually fills out a coldfusion form (on the web) with its values.


Does anyone know if this is possible? There are 3 values I am trying to pull off the card and have entered into the CF form.

This is the card reader: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&Item=350142691991&Category=26261

maybe it wont work for the job etc?


But basiclaly I want to click a page in my CF website, and have it wait until the card is swipped (connected to USB) and when it has, fill out the form.


If anyone has any suggestions or artilces to read, I am all ears.

Interesting Article

See "Wednesday, Thursday"

http://coldfusion.sys-con.com/node/296187

Thanks

[tclaremont]

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.

[tclaremont]

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.

[Ssirseth]

Hey
Thanks so much for the info.

Yes I will 100% be saving the balance, history etc on my online DB.

So its really that easy. I was speaking with some other developers on the subject they advised me I should have a vb.net program on the computer, that reads the card, and then sends all the info to my DB online though a webservice. They say this is way more secure etc etc etc???

Any suggestions there? What type of security issues might I get into if I just scan the card direct into a CF website, the parse the data, then query my DB etc.

Also do you suggest any "cheaper" card readers (any better then others)

[Newsgroup_User]

Ssirseth wrote:
>
> So its really that easy. I was speaking with some other developers on the
> subject they advised me I should have a vb.net program on the computer, that
> reads the card, and then sends all the info to my DB online though a
> webservice. They say this is way more secure etc etc etc???
>

Yes it is that easy and ColdFusion is not involved at all with the card
reader, client end of things. ColdFusion could easily be the server end
that receives the data and interact with the database and returns the
results to the client. It can even do all of this with web services if
you want it to.

But as for reading the card on a client and having the results appear in
a form on the client and having that form sent to the server from the
the client. That is all client programming and has nothing to do with
ColdFusion as ColdFusion does not do client programming.

AIR does client programming via Flash|Flex. VB does client programming.
Java does client programming. C|C++|C# does client programming. But
I'm not sure how much client programming you need to do.

I presume card readers come already programmed to interact with the
client computers they are plugged into. And you would just use the API
provided by the card reader manufacture to get the data read from the
card and somehow sent from the client to your server.

Then from the server, this is just straight up HTTP get|post and|or web
service requests that ColdFusion process normally as it has no idea how
the client got the data that was sent to it and it does not care.

[tclaremont]

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.

[Newsgroup_User]

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.

[tclaremont]

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.

[Newsgroup_User]

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.

[Kibbage-Data-Services]

There is no programming on the client to read the card. To the client (PC) it looks like the data on the card was keyed in from the keyboard; just a very fast typest. There is microcode in the reader to make it look like it is the keyboard.

[Steve Sommers]

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.