Parse Credit Card input from Magnetic Stripe

Question

Does anyone know how to parse a credit card string input from a Magnetic Card Swiper?

I tried a JavaScript parser but never got it to work. This is what the input looks like.

%BNNNNNNNNNNNNNNNN^DOE/JOHN
^1210201901000101000100061000000?;NNNNNNNNNNNNNNNN=12102019010106111001?

The N's are the credit card number.

Answer 1

See the Magnetic Stripe Card entry @ Wikipedia:

---

Track one, Format B:

• Start sentinel — one character (generally '%')
• Format code="B" — one character (alpha only)
• Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
• Field Separator — one character (generally '^')
• Name — two to 26 characters
• Field Separator — one character (generally '^')
• Expiration date — four characters in the form YYMM.
• Service code — three characters
• Discretionary data — may include Pin Verification Key Indicator (PVKI, 1 character), PIN Verification Value (PVV, 4 characters), Card Verification Value or Card Verification Code (CVV or CVK, 3 characters)
• End sentinel — one character (generally '?')
• Longitudinal redundancy check (LRC) — one character (Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.)

---

I hope the data is fake, otherwise Anyone could get the:

• Name
• Expiration Date
• CVV

And I'm not sure but I think the credit card number (or # of possibilities) can be computed using the LRC.

Answer 2

From what I can remember:

That is a two-track magnetic strip data - first track starts with % and ends with ?, the second track starts with ; and ends with ?. These are Start/End markers.

The first track is alphanumeric, the second track is numeric, and there is a third track which is numeric also (if my memory serves correct).

The data between the start/end markers can be variable depending on the recording density of the magnetic strip. The higher the density, the more it can be recorded on one track.

Using a regex to get at the data may not be a reliable method to pick out the information required.

And not all credit cards have exactly two tracks, some uses three tracks.

Hope this helps, Best regards, Tom.

Answer 3

we have such credit card parsing component available for developers. please visit our web site for more details. we also offer free technical support via email and 1.800 telephone number. http://idscan.net/downloads.html

Answer 4

Generally for a card-not present transaction (i.e. MOTO transactions) you will need cc#, expiry and possibly the CVV (aka CVC2 etc). You can obtain the first 2 from a card-swipe as this in the track data. CVV is printed on the card.

Name on card doesn't matter so much. Unless your acquirer and the cardholder are using address verification, but you can find that between ^^, it may have white space padding which you can remove.

The part you want is track2 NNNNNNNNNNNNNNNN=1210 where NNNNN=card number PAN, and 1210 = Expiry date.

Even if track1 is empty (which sometimes it is as it's not used in processing), you will still get the ;?, so you could use the index of the second ; as start of the string and = as the end of the cc# string. With the 4 characters after the = as the expiry.

I would advise getting the card holder to sign something in record of the transaction otherwise they could dispute the card and do a charge-back.

And not all credit cards have exactly two tracks, some uses three tracks.

Only track2 is used for processing and has a standardized format.

Debit cards can't generally be processed (unless they have a visa-debit card or something).

P.S. you shouldn't store cc data in plain text, so try and keep everything in mem or strong encryption.