2

I'm in the middle of creating a web application for a client, and he wants me to integrate magnetic card swipers so his office staff can quickly swipe a card, and load up details for specific patients (each patient is assigned a unique number corresponding to a unique card).

In my software, handling the incoming string is fairly trivial, as the card swiper simulates keypresses for each character in the id on the card.

However, I've run into some oddities. We are using two different brands of card swipers, and I discovered that one card swiper generates a string that begins with "+", and the other swiper generates a string that begins with ";". The actual numbers on the card (the id number that comes after the "+" or ";") are the same for each kind of swiper.

I can of course add to my code and detect for both a "+" and a ";". However, I'm concerned that if we introduce yet another brand or model of card swiper, it might generate something entirely different. Or, if they decide to use a different brand of cards, I might get something different still.

I don't want to have to keep patching my code to handle all these differences, if possible. Is there some sort of documentation that sets standards for all card swipers and magnetic cards? I'm looking for something that will tell me something like:

  1. All cards begin with one of these: ['$', '+', ';']
  2. Followed by a varied length string of alpha-numeric characters
  3. Ending with one of these: ['?', '*', '^']

Here are some additional considerations:

  1. These are simple magnetic cards, that simply contain on string of characters (used as identifiers for quick lookup). We aren't swiping credit cards or anything like that.
  2. This is a distributed web application, that will be used all over the United States. And I don't have control over what brand of card or swiper each office uses.
  3. Because of business requirements, I am using pattern recognition based on the keypress event. I'm not looking at the generated string inside a text box.
3

Not really, no. At least, not outside of the fact that there are three tracks to read from, and each has a maximum number of bytes they can hold.

While there are standards that are followed, it's highly dependent on the industry / implementer. For example, driver's licenses are encoded based on specifications published by the AAMVA. For example:

The following data is stored on track 1:[16]

  • Start Sentinel - one character (generally '%')
  • State or Province - two characters
  • City - variable length (seems to max out at 13 characters)
  • Field Separator - one character (generally '^') (absent if city reaches max length)
  • Last Name - variable length
  • Field Separator - one character (generally '$')
  • First Name - variable length
  • Field Separator - one character (generally '$')
  • Middle Name - variable length
  • Field Separator - one character (generally '^')
  • Home Address (house number and street) - variable length
  • Field Separator - one character (generally '^')
  • Unknown - variable length
  • End Sentinel - one character (generally '?')

Notice the various delimiter characters aren't specified. Yes, the starting character is usually '%', but not always! You just know that the first byte is a delimiter.

The way I have been able to get around this is to ignore the character itself. Just knowing the first character is a delimiter means I can ignore it and read the next two characters for the state abbreviation.

In other cases, it's not as cut and dry (see the city field above). That's where you have to determine the type of card, and based on the card type use a different parsing strategy. The strategy pattern is helpful here.

Further reading:

  • thanks for the thorough answer. I am asking about both the card as well as the card swiper. My major roadblock is that when using one swiper, the first character is "+". But when using the other swiper (with the same card), the first character is a ";". Any insights as to why this is happening? – Matt Spinks May 17 '18 at 19:40
  • Could it be because the swipers are reading different tracks? en.wikipedia.org/wiki/Magnetic_stripe_card#Financial_cards and abacus21.com/Magnetic-Strip-Encoding-1586.html. Note that the semicolon appears to be an invalid start character. – Robert Harvey May 17 '18 at 19:42
  • Ah, the ; comes from the ANSI/ISO BCD Data Format (tracks 2 and 3). – Robert Harvey May 17 '18 at 19:47
  • I see. Maybe one card reader is reading from track 1, and the other one is reading from track 2 or 3. This helps. At least now I have a set list of characters to look for as the first character. I can analyze and parse the remainder of the data. – Matt Spinks May 17 '18 at 19:51
  • @MattSpinks It could be a lot of things. Difficult to answer without more understanding of how your application interacts with the devices and how the data on the cards is encoded and returned to your application. Organizations that produce these cards also have a lot of control over how they write the data on the card. They could follow a standard, or ignore them. Also, If all you get back is one long string, you are losing the ability to parse individual tracks, which is important because each track, depending on the standard in question, has a different layout. – Cypher May 17 '18 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.