Print PDF
Favorite
Email
Step 3Magnetic Card Basics
The primary functions that you'll need to do to read a magnetic card are:
1. Detect when the card has been swiped
2. Read the stream of data
3. Detect when the card has gone
4. Process the data
5. Display the data
First, I'll introduce you to some magnetic card basics that you'll need to know when you start writing your own code.
7810 Physical characteristics of credit card size document
7811-1 Embossing
7811-2 Magnetic stripe - low coercivity
7811-3 Location of embossed characters
7811-4 Location of tracks 1 & 2
7811-5 Location of track 3
7811-6 Magnetic stripe - high coercivity
7813 Financial transaction cards
As you can see, financial cards are specified in a separate document and often have different formats than, say, your grocery card or international calling card. You will have to program for these differences. I just had a credit card and insurance card handy, so I programmed for these types (which both happen to be format B).
Track 1
For financial cards, the first track is recorded at 210 bits per inch and is the first 0.110" of the card from the top. The data is encoded as "card data" as 7-bits per character. That's 6-bits for the character and a bit for parity. There are ~ 79 alphanumeric characters on track 1.
The physical ordering is backwards. That is, data is but it's written backwards on the card (and hence, will be read by your firmware) as . The parity is odd.
The card data format looks like this:
[SS] [FC] [Primary Account #] [FS] [Name] [FS] [Additional data] [FS][ES][LRC]where:
SS Start sentinel
FC Format code
FS Field separator
ES End sentinel
LRC Longitudinal Redundancy Check character
Track one SS = '%', FC = one of the formats (going to be B a lot of times), FS is often '', ES is '?' and the LRC character is commonly '<' although it's not specified in the standards. Besides being written on the card backward, the data has an odd parity bit and is 0x20 from ASCII. We'll handle this when we process the data.
Track 2
Track two is 0.110" wide and starts 0.110 from the top of the card. It's recording density is 75 bits per inch. The data is 5-bits per character and consists of around 40 numeric symbols only. You shouldn't encounter any letters on this track.
The card data format should follow this structure:
[SS] [primary account #] [FS] [additional data | discretionary data] [ES] [LRC]The SS for track two is the semicolon: ';' and the FS is '='
With this holy knowledge under your belt, continue on to the next steps to see code implementing the procedure outlined above.
1. Detect when the card has been swiped
2. Read the stream of data
3. Detect when the card has gone
4. Process the data
5. Display the data
First, I'll introduce you to some magnetic card basics that you'll need to know when you start writing your own code.
Magnetic Card Standards
Magnetic cards are standardized by the ISO in the following documents:7810 Physical characteristics of credit card size document
7811-1 Embossing
7811-2 Magnetic stripe - low coercivity
7811-3 Location of embossed characters
7811-4 Location of tracks 1 & 2
7811-5 Location of track 3
7811-6 Magnetic stripe - high coercivity
7813 Financial transaction cards
As you can see, financial cards are specified in a separate document and often have different formats than, say, your grocery card or international calling card. You will have to program for these differences. I just had a credit card and insurance card handy, so I programmed for these types (which both happen to be format B).
Card Formats
There are several different formats for magnetic cards. Format A and B are common, with B being the most common I've seen, and which is supported in this code. Formats C through M are reserved by the ISO, I believe, while N through ?? are reserved for institutional custom use.Track 1
For financial cards, the first track is recorded at 210 bits per inch and is the first 0.110" of the card from the top. The data is encoded as "card data" as 7-bits per character. That's 6-bits for the character and a bit for parity. There are ~ 79 alphanumeric characters on track 1.
The physical ordering is backwards. That is, data is but it's written backwards on the card (and hence, will be read by your firmware) as . The parity is odd.
The card data format looks like this:
[SS] [FC] [Primary Account #] [FS] [Name] [FS] [Additional data] [FS][ES][LRC]where:
SS Start sentinel
FC Format code
FS Field separator
ES End sentinel
LRC Longitudinal Redundancy Check character
Track one SS = '%', FC = one of the formats (going to be B a lot of times), FS is often '', ES is '?' and the LRC character is commonly '<' although it's not specified in the standards. Besides being written on the card backward, the data has an odd parity bit and is 0x20 from ASCII. We'll handle this when we process the data.
Track 2
Track two is 0.110" wide and starts 0.110 from the top of the card. It's recording density is 75 bits per inch. The data is 5-bits per character and consists of around 40 numeric symbols only. You shouldn't encounter any letters on this track.
The card data format should follow this structure:
[SS] [primary account #] [FS] [additional data | discretionary data] [ES] [LRC]The SS for track two is the semicolon: ';' and the FS is '='
With this holy knowledge under your belt, continue on to the next steps to see code implementing the procedure outlined above.
| « Previous Step | Download PDFView All Steps | Next Step » |
 |
Add Comment
|
