A magnetic stripe reader is sold as one line item and three different devices. "MSR" in a quotation can mean a head that reads tracks 1 and 2, which is what a payment application needs, or a head that also reads track 3, which is what a loyalty or access program needs. The two are close enough in price that the difference rarely shows up in the quote, and far enough apart in behavior that it shows up at the counter instead. This is what the three tracks carry, what a terminal actually does with them, and how to specify the one you need.
What "three-track" actually means
ISO/IEC 7811 defines three parallel tracks on the same stripe, and the standard is old enough that its constraints are still visible in the data. Each track has its own recording density, its own character set and its own capacity, and the three were designed for three different jobs that existed in the 1970s: airline ticketing, bank authorization, and thrift or savings transactions.
Only the first two survived as payment interfaces. The third survived as a place to put things that are not payments. That split is the whole story of why a 3-track head is still a real product in 2026 rather than a museum part.
What each track can hold
The differences are not arbitrary. A track that has to carry letters needs more bits per character than one that carries only digits, and the density was set to make each track fill roughly the same length of card.
| Track | Standard name | Capacity | Density | Characters | Bits per character |
|---|---|---|---|---|---|
| 1 | IATA | 79 characters | 210 bpi | Alphanumeric, ASCII 32 to 95 | 6 data bits plus parity |
| 2 | ABA | 40 characters | 75 bpi | Numeric, ASCII 48 to 62 | 4 data bits plus parity |
| 3 | THRIFT | 107 characters | 210 bpi | Numeric, ASCII 48 to 62 | 4 data bits plus parity |
Capacities include the start sentinel, the end sentinel and the check character, so the usable payload is always a little smaller than the number in the table. Track 2 is the tightest of the three, which is why the arithmetic on it is worth doing before a program assumes it can write something there.
Why all three tracks are about the same length
Track 2 records at 75 bits per inch, roughly a third of the 210 bits per inch used by tracks 1 and 3. That looks like a weakness until the character widths are counted: 40 characters at 5 bits each is 200 bits, while 79 characters at 7 bits each is 553 bits. The lower density is what lets a shorter character string occupy the same physical space.
| Track | Bits used | Length at its density | Share of an 85.60 mm card |
|---|---|---|---|
| 1 | 553 | 66.9 mm | 78% |
| 2 | 200 | 67.7 mm | 79% |
| 3 | 535 | 64.7 mm | 76% |
Three tracks, three capacities, and within 3 mm of each other. The consequence is mechanical rather than theoretical: the usable stripe is a fixed strip on an ID-1 card, and no track has room to grow. A program that needs more than 13 discretionary characters on track 2 has to move to a different track, a different card or a server side lookup, because the standard has no spare space to sell.
What a payment terminal reads, and what it ignores
A payment application reads track 2 and, if it is present, track 1. Track 2 carries what the authorization needs: the account number, the expiry as four digits in YYMM form, and a three digit service code. Track 1 carries the same account number plus the cardholder name in readable characters, which is what appears on a receipt, in a dispute screen or in a refund lookup when the customer has no receipt.
| Field | Track 2 budget on a 16 digit card | What it is for |
|---|---|---|
| Start sentinel and format | 2 characters | Where the record begins |
| Account number | 16 characters | The authorization key |
| Separator | 1 character | Field boundary |
| Expiry | 4 characters | YYMM, no separator |
| Service code | 3 characters | Interchange scope, processing rules |
| Discretionary data | 13 characters | Issuer's own use, often a check digit or a sequence |
| End sentinel and check character | 2 characters | Record end, longitudinal redundancy check |
Thirteen characters is the whole discretionary allowance on a 16 digit card. On a 19 digit card it drops to 10. Programs that want to write a member tier, a store number and a sequence number into track 2 usually run out of room in the middle of the design, and the discovery tends to happen after the card artwork is approved.
Track 3: unused by the card networks, still ordered by three kinds of program
No payment scheme authorizes a transaction from track 3. It is read and write, it is large, and it was designed for savings and thrift transactions that were never migrated onto it in most markets. That history is why it is available: the space exists, the format is standard, and nobody else is using it.
Three kinds of program still write there. Closed loop and gift card schemes that grew out of a proprietary system and have never been re-platformed. Access control and ID programs that want a card to carry both a payment identity and a door or locker credential. And legacy integrations where the software vendor's data model has a third field and the integration contract is older than the people maintaining it.
If none of those describe the deployment, track 3 is a feature the buyer pays for and never uses. That is not a reason to avoid it, because the price difference is small and the option has value the day a loyalty program is added. It is a reason not to accept vague reassurance: the question to ask is not whether the reader has three heads, it is whether the third field arrives at the host.
What "MSR" in a quotation can mean
Four different products get quoted under the same three letters, and the quote rarely says which one it is.
| What was quoted | What it reads | Where it falls short |
|---|---|---|
| 2-track head, tracks 1 and 2 | Payments, gift cards, membership numbers held on track 2 | Any program that writes track 3 |
| 3-track head, tracks 1, 2 and 3 | All three, if firmware exposes them | Nothing, but check the firmware |
| 3-track head with 2-track firmware | Tracks 1 and 2 only | The third field never reaches the application, and the parts list still says 3-track |
| External reader on USB or serial | Whatever that device supports | One more thing to mount, power and support |
The third row is the one that costs money, because it is invisible in a datasheet and invisible in a quotation. A three-track head feeding a two-track firmware path is a two-track reader with a slightly better part number. The only reliable check is a test card with data on all three tracks and a look at what the application receives, which is a five minute test that a purchase order deserves.
Swipe, insert, tap: why all three interfaces are still on the price list
A magnetic stripe is not a payment method that happens to be old. It is one of three physical interfaces to the same account, and each one fails differently, which is why terminals keep all three rather than the newest.
| Interface | What it reads | What it is best at | What breaks it |
|---|---|---|---|
| MSR, swipe | Tracks 1, 2 and 3 on the stripe | Gift, membership and ID cards; a chip card whose contacts are dirty | A demagnetized stripe, a worn head, a swipe that is too fast or too slow |
| IC, contact chip | The chip through six contact pads | Card present payment where the scheme mandates chip | Dirt or oxidation on the pads, a damaged chip, an insert that never seats |
| NFC, contactless | The same chip over a short radio link | Speed at a busy counter; cards and phone wallets | Distance and orientation, a metal counter, interference from another reader |
The interfaces coexist because the cards coexist. A store that accepts a bank card, a store gift card and a staff discount card is running all three interfaces on one counter, and removing the oldest one would break the two programs that cost the least to support.
How the three are packaged differs by product family, and the difference matters when a buyer is counting ports. On the payment terminal range, magstripe, IC and NFC are read by the same module: the countertop and handheld models carry built-in NFC, EMV chip and magnetic stripe reading, with PCI PTS 6.x and EMV Level 1 and Level 2 on the financial models. On the all-in-one range the reader set is modular, and MSR is an option alongside the built-in NFC reader rather than part of the base build. Neither arrangement is better; they are different answers to "how many card types does this counter see".
Testing a three-track reader before you accept the shipment
Four checks, in this order, and the third one is the one that gets skipped.
- Read a card with data on every track. A bank card will not do, because track 3 is empty on most of them. Use a card written for the purpose, or one the loyalty program already issues, and confirm the application shows three populated fields rather than two plus a blank.
- Read a card with an empty track 3. The reader must return an empty field, not an error, and the application must accept the card. This is the mixed estate case and it is the most common source of false rejects.
- Read the same card in both swipe directions. A track layout assumes a leading edge. A head that reads only in one direction passes a careful test and fails a busy cashier, and the failure is intermittent enough to be blamed on the card.
- Read a worn card. Take a card that has been in a wallet for a year and read it twenty times. Track 2 at 75 bits per inch tolerates more wear than tracks 1 and 3 at 210, so a failing head often shows up on the alphanumeric track first.
The acceptance test for a hardware order is a separate exercise from reading one card on a bench, and the units, stores and pass criteria for it are set out in how to test POS hardware before a bulk order. For a card reader the useful addition is a known card set: one good card, one worn card, one with an empty third track, kept with the test equipment rather than in someone's wallet.
The data you must not keep
Full track data is sensitive authentication data under PCI DSS. It must not be retained after authorization, and that rule applies to the terminal, the POS application and the support log. The last one is where it usually goes wrong, because a developer turning on verbose logging to debug a reader does not think of the log as a card data store.
The arithmetic is not subtle. Five hundred terminals, two hundred swipes a day each, forty characters of track 2 per swipe, is four million characters a day. Over a month that is roughly 120 MB of data that should not exist in an unencrypted file on a store server, and it will sit there until someone finds it in an audit.
The practical controls are cheap: log the last four digits and a transaction identifier instead of the field, turn verbose reader logging off in production images rather than in the field, and confirm at acceptance that the log file contains no start sentinel. A single semicolon at the head of a logged string is the signature of track 2, which makes it an easy thing to grep for in a pre-production audit.
Five lines for the RFQ
- The tracks you need. Two or three, named, with the program that needs the third one identified so the supplier can check firmware rather than heads.
- Where the reader sits. Integrated on the terminal, on the side of an all-in-one, or a separate device on a cable, because the mounting changes with the answer.
- What the host receives. Track data as separate fields, the way the application expects it, tested against the application rather than against a spec sheet.
- The card mix. Bank cards, gift cards, membership cards, staff cards and ID cards, with the ones that are not bank issued named explicitly.
- The acceptance test. The card set, the number of reads and the pass criteria, agreed before the order rather than after the shipment.
The second line is where an integrator usually gets caught: a reader that exists on a datasheet may not fit the enclosure the customer has already specified. A short written RFQ costs less than a long call, and the structure for one, including what to put in each line and what to leave out, is in how to write a POS hardware RFQ. The comparison of the three read methods, and how they behave at a counter, is set out in what a credit card reader actually is; the hardware side starts from our payment terminal range, and an all-in-one with a reader built in is on the all-in-one POS page.
None of this changes what the terminal is for. The reader exists so that a card the customer is holding can be used, and the specification exists so that the card program the store runs can be used too. Writing both down before the order is the difference between a rollout and a repair queue. The commercial terms that sit around that order, from minimums to lead times, are on the ordering terms page, and a model that carries the MSR option is the P90W Windows terminal.
Frequently asked questions
What is the difference between a 2-track and a 3-track MSR?
A 2-track head reads tracks 1 and 2, which is what a payment application needs: track 1 carries the cardholder name in readable characters, track 2 carries the account number, expiry date and service code. A 3-track head adds track 3, which the card networks do not use for authorization but which some loyalty, gift card, access control and older proprietary systems write to. The physical head is the cheap part of the difference. The part that matters is whether the reader reports track 3 to the host at all, because a 3-track head with firmware that stops at track 2 behaves like a 2-track head.
What does track 2 actually contain?
On a 16 digit card, track 2 is 40 characters in total: a start sentinel, the 16 digit primary account number, a separator, four digits of expiry as YYMM, a three digit service code, then 13 characters of discretionary data chosen by the issuer, and finally the end sentinel and a check character. The three digit service code is the part buyers overlook. Its first digit states the interchange scope, which is how a private label card at 7 is distinguishable from an internationally accepted card at 1 or 2 without asking anyone.
Do I need track 3 for a loyalty program?
Only if the program already writes there. Track 3 is read and write, and it is where a proprietary scheme can store a member number, a balance or a tier flag without touching the payment tracks. But most loyalty programs built after 2010 keep the balance server side and use the card number as a key, which means track 2 discretionary data or the account number itself is enough. Check what the program actually encodes before paying for the third track, and check it with a card the program has already issued rather than with a test card.
Will a 3-track reader read a 2-track card?
Yes, and it will return an empty track 3 rather than an error. That is exactly where integrations break: software written against a 3-track reader may treat the empty third field as a read failure and reject a perfectly good card. If the estate will mix 2-track and 3-track cards, the application has to treat track 3 as optional, and that behavior is worth testing with a blank card before the rollout rather than discovering it at a counter.
Is swiping still allowed?
The magnetic stripe is still a valid fallback on most payment schemes, but where a scheme mandates chip or contactless support, a transaction that falls back to the stripe can shift liability to the merchant's side. That rule is set by the scheme and enforced by the acquirer, not by the terminal, and it differs by market. The practical consequence for hardware is the opposite of retirement: a terminal that cannot read a stripe cannot serve a gift card, a membership card, a driver license or a damaged chip card, so the interface stays on the price list.
Does hi-co or lo-co matter for the reader?
For reading, no: a read head resolves both coercivities, which is why the same terminal handles bank issued high coercivity cards and low coercivity membership cards. Coercivity matters on the write side, where the encoder current has to match the stripe, and it matters for durability, because a high coercivity stripe is harder to erase by accident. If the program issues its own cards and encodes them in house, that is the point at which coercivity becomes a decision rather than a property.
