You have the card design, the volumes, and a deadline. Then procurement writes “encode the cards” into the RFQ and waits. What comes back is three quotes that each encode something different — different stripe coercivity, different chip applets, different contactless behaviour — and none of it matches what your readers actually need at the door. Encoding is where good card programs quietly fail, because “encode the cards” is not a specification. This guide turns that vague line into a bid-ready encoding spec covering the three technologies most B2B card programs combine: ISO 7811 magnetic stripe, ISO/IEC 7816 contact chip, and ISO/IEC 14443 contactless — and shows how to verify it on arrival.
Why “Just Encode the Cards” Breaks a Procurement
A one-line encoding instruction hands every supplier a blank cheque to fill the gaps with their cheapest default. The result looks fine on the quote and collapses at deployment. A magnetic-stripe quote may assume Lo-Co 300 Oe stripe; your existing readers were installed for Hi-Co 2750 Oe, so the new cards decode poorly or not at all. A contactless quote may ship a blank ISO/IEC 14443-4 card with no application loaded — nothing for your system to authenticate against. A contact quote may arrive with the wrong applet, so the reader never sees the credential it expects.
“Encode the cards” is not a specification. It is three suppliers’ three different interpretations of an unstated requirement. The cost does not show up on the invoice; it shows up later as re-issuance, help-desk calls, and a security gap where a card that “should” work does not. Credential-integrity guidance such as NIST SP 800-116 Revision 1 treats the encoded credential as a controlled element precisely because an unspecified credential is an unmanaged one.
The fix is not more words for the sake of it. It is a small, structured spec that names the standard, the parameter, and the acceptance check for each technology on the card. Everything below builds that spec.
ISO 7811 Magnetic Stripe: Coercivity, Tracks, and Data Format
The magnetic stripe is the oldest technology on the card, and the easiest to get wrong because it is usually specified as an afterthought. ISO/IEC JTC 1/SC 17 publishes ISO 7811, which defines the recording technique for the stripe itself.
Coercivity is the first decision: Hi-Co (2750 Oe) resists accidental erasure near magnets and bag checks and outlasts Lo-Co; Lo-Co (300 Oe) is cheaper but erases far more easily. Specify which one, and specify it against the readers you already run — a Hi-Co reader will not reliably read a Lo-Co card and vice versa. State whether the stripe is read/write or one-write (OWS).
Then name the tracks. Track 1 holds up to 79 alphanumeric characters (the legacy airline/IATA layout), Track 2 holds 40 numeric characters (the banking/ABA layout most access and payment systems use), and Track 3 holds 107 numeric characters and is rarely used today. For each track you intend to use, state the character encoding (ASCII or BCD), the parity convention, and the start/end sentinel and LRC scheme. A supplier who knows the coercivity, the tracks, and the format will return a card that decodes on your readers — not a guess.
ISO/IEC 7816 Contact Chip: ATR, Chip Type, and Application
The contact chip (the gold pad you can see and feel) is governed by the ISO/IEC 7816 family — physical dimensions, electrical interface, and the transport protocol. The detail most buyers skip is the one that protects you from silent substitution.
Specify the expected ATR (Answer To Reset) — the byte string the chip returns on power-up — or at least the chip platform, so incoming inspection can detect a swapped component. A card that “has a chip” tells you nothing; a card whose ATR matches the approved sample tells you the silicon is what you paid for.
Next, the chip type. Memory cards store data; microprocessor (MCU) cards run code. For most secure programs you want a Java Card / GlobalPlatform MCU capable of hosting an application. And the application is the part that is almost always missing from a lazy spec: you must state the application and its AID (application identifier), not just “a chip.” For payment, that means naming the EMVCo application; for enterprise access, the credential applet and AID your readers expect. A bare contact chip with no application loaded is a paperweight with a gold pad. Plan for contact wear too — ISO/IEC 7816 contact cards are rated for a minimum of roughly 10,000 insertion cycles, which should inform a lifecycle and re-issue policy.
ISO/IEC 14443 Contactless: Chip Family, Application, and Read Range
The contactless interface is where most modern programs live, and where the most confusion sits between “RFID” and “card.” A contactless card is not “just an RFID tag.” ISO/IEC 14443 defines a proximity protocol at up to roughly 10 cm, and the chip family plus the loaded application decide whether it reads at your reader.
Two flavours matter. Type A (the MIFARE family and NFC Forum-compliant devices) and Type B (native anti-collision, common in some government IDs). Within those, chip families — MIFARE Classic, MIFARE DESFire, NTAG, ICODE — carry very different security and interoperability trade-offs, and Classic in particular is deprecated for secure programs. State the family, the product (for example DESFire EV3), and the application/AID, and state the expected read range (nominally 3–10 cm). If you actually need longer range, that is a different standard — ISO/IEC 15693 — not 14443, and the spec should say so rather than hoping a “contactless card” somehow reaches farther.
This is also the place to reconcile the contactless choice with the rest of your program. If you are weighing RFID, NFC, and BLE for the same card, our RFID vs NFC vs BLE interface guide maps each to its best-fit use case before you commit a reader estate.
Writing One Combined Encoding Specification Into Your RFQ
Once each technology is understood, collapse them into a single encoding table per card type and paste it straight into the RFQ. A structure your suppliers can bid against looks like this:
| Technology | Standard | Specification to state | Verification |
|---|---|---|---|
| Magnetic stripe | ISO 7811 | Hi-Co 2750 Oe; Track 2 numeric, BCD, LRC; read/write | Decode on reference reader, ≥95% first-read |
| Contact | ISO/IEC 7816 | MCU Java Card; ATR <value>; applet <AID> | ATR match + applet select |
| Contactless | ISO/IEC 14443 | Type A; DESFire EV3; application <AID>; read range ≤10 cm | UID read + application auth |
Lock the approved sample’s encoded data dump into the contract as the acceptance baseline. When a batch drifts, you are not arguing about intent — you are comparing bytes to the signed reference. This single clause is what separates a spec that protects you from one that merely looks detailed.
Encoding is only one of several spec layers. The artwork, bleed, and keep-out zones around the chip and antenna are a separate prepress discipline; our card artwork specifications guide covers what a secure plant checks before it prints, and the two specs should travel together in the same RFQ packet.
How to Verify Encoding on Incoming Inspection
A certificate of conformance is not evidence. The only way to know a batch encodes as specified is to sample it and test. Build a short incoming plan: check the ATR on contact cards, confirm application select, measure first-read success on contactless, and decode the magnetic stripe on a reference reader. Unverified encoding is the single most common cause of first-read failures in the field — catch it at incoming inspection, not at the door.
Size the test to the program risk. The golden pre-production sample should be tested 100 percent and archived as the reference. Production batches can be sampled against an AQL (commonly 1.0–2.5 depending on program criticality); the exact level belongs in your ID card issuance program lifecycle plan. The defects you are hunting are mundane and expensive: wrong coercivity, a swapped ATR, a blank application, or a weak contactless signal. Keep one encoded reference card at receiving so every incoming lot has something to be compared against.
Frequently Asked Questions
Can one card carry all three technologies?
Yes. Dual-interface cards put contact and contactless on a single chip, and triple-technology cards combine stripe, contact, and contactless. But each added technology adds cost and certification scope, so specify only what your readers’ infrastructure actually uses rather than paying for a capability no reader will touch.
What does Hi-Co vs Lo-Co actually change for my program?
Durability and resistance to accidental erasure. Hi-Co survives magnets and bag checks far better and is the right default for long-life ID and access cards; Lo-Co is cheaper and fine only where the environment is magnet-clean. The deciding factor is your existing reader fleet — match the stripe to what those readers were specified for.
Do I need to specify the application, or just the chip?
The chip alone is useless to your system. Specify the application and its AID for both contact (ISO/IEC 7816) and contactless (ISO/IEC 14443) so the reader has something to select and authenticate. A bare chip with no application is the most common “it arrived but it doesn’t work” failure.
How many samples should I test on incoming inspection?
Test the golden pre-production sample 100 percent and archive its encoded dump as the reference. For production batches, sample against an AQL appropriate to program risk — typically 1.0 for high-security credentials, up to 2.5 for lower-risk volumes — and escalate to 100 percent if a lot fails the ATR or application check.
Turn the Spec Into a Quote
A card program lives or dies on the details nobody argues about until they hurt. Name the standard, the parameter, and the acceptance check for every technology on the card, lock the approved sample as the baseline, and verify on arrival — and “encode the cards” stops being a gamble. If you want a copy-ready encoding table built around your reader estate and volumes, contact our engineering team and we will spec it with you before you issue the RFQ.
