When a transit authority launches or upgrades a fare system, the most consequential—and most often underestimated—decision is not the gates or the back office. It is the card itself. The card is the only part of the system every rider touches several times a day, and the wrong specification quietly locks in years of higher replacement cost, limited interoperability, and security exposure. This guide is written for the procurement, engineering, and operations teams who actually write the specification: it walks through how fare cards work, which chip to choose, how long they must last, and the standards that keep a city-wide program interoperable.
How Fare Cards Actually Work: Stored-Value vs Account-Based Ticketing
Before specifying a chip, you must decide what the card holds. In a stored-value model, the card carries a secure electronic purse—the balance lives on the card, typically on a MIFARE DESFire secure element. Riders top up at stations and gates deduct locally. In an account-based ticketing (ABT) model, the card is essentially an identifier: a token that points to a cloud account, while the balance, fare rules, and history live in the back office. ABT is now the dominant direction for new city programs because it simplifies card lifecycles and enables open-loop convergence with bank cards and phones.
Both models still rely on the same underlying contactless standard, ISO/IEC 14443, which defines how a 13.56 MHz card talks to a reader (ISO/IEC 14443 overview). Your chip choice—not the ticketing model—determines cost and security headroom. See our smart card chip selection guide for the full memory, interface, and security trade-offs.
Choosing the Chip: MIFARE DESFire EV3 vs MIFARE ULTRALIGHT C
Most transit programs standardize on NXP MIFARE, but “MIFARE” covers very different silicon. MIFARE DESFire EV3 is a secure microprocessor card with AES-128 and 3DES cryptography, large flexible memory, multiple application slots, and support for key versioning and secure rollover. It is the right choice for stored-value systems, multi-application city cards, and any program that must stay backward compatible with existing DESFire infrastructure (NXP MIFARE DESFire EV3).
MIFARE ULTRALIGHT C is a low-cost memory chip with limited storage and a single AES-128 authentication step—no secure purse, no multi-app. It fits disposable, low-value, or single-purpose tickets where cloning risk is acceptable (NXP MIFARE Ultralight C). Rule of thumb: if money or a long-term credential lives on the card, specify DESFire; if it is a short-life token, ULTRALIGHT C is the economical choice. If you are migrating away from legacy silicon, our MIFARE Classic to DESFire EV3 migration playbook covers the cutover.
Never specify MIFARE Classic for a new program—its CRYPTO1 algorithm has been publicly broken since 2008 and it must not carry value.
Built for the Daily Tap: Durability and Card Lifespan
A transit card is tapped thousands of times a year and handled by millions of riders in pockets, wallets, and heat. A well-specified transit card is expected to survive 3–5 years of daily use—tens of thousands of taps—without reader failures. That lifespan depends on the card body (PVC, PETG, or polycarbonate composite), thickness held to the ISO/IEC 7810 CR80 0.76 mm nominal spec, and resistance to abrasion, bending, and the cleaning chemicals used at service desks.
Specify edge-to-edge, scratch-resistant printing and verify suppliers against an accelerated durability test plan referenced to ISO/IEC 10373. Our warranty, SLA, and failure-rate guide explains the acceptance criteria buyers should put in the contract.
Dual-Interface Cards and Gate Interoperability
Modern transit cards increasingly need to work both ways: tapped at a gate (contactless, ISO/IEC 14443) and read at a service desk, encoder, or acceptance terminal (contact, ISO/IEC 7816). A dual-interface card carries one chip with both interfaces, so a single credential serves riders at the gate and operators at the back office. Our dual-interface smart card guide details the real-world benefits and trade-offs.
More importantly, interoperability across operators and regions is not a chip property—it is a specification property. Cross-operator acceptance depends on a shared application specification such as ITSO (UK) or Calypso, layered on top of the common ISO/IEC 14443 air interface (ITSO, Calypso Networks Association). Specify the application standard first; the chip is then a compliant implementation detail.
Personalization and Issuance for a City-Wide Program
A city program means volume: millions of cards, variable data, and a personalization line that must keep pace with demand. Two printing methods dominate. Dye-sublimation is fast and low-cost for basic artwork but leaves a slight edge border and softer durability. Re-transfer (reverse-transfer) printing lays a thin film across the entire surface for edge-to-edge, highly durable artwork—the better choice for high-wear transit cards. Our card personalization methods comparison breaks down the cost and durability math.
Pair printing with correct encoding: DESFire keys must be diversified per card, and the personalization data flow (issuance system to encoder to card) needs validated error handling so a mis-encoded card is caught before it reaches a rider.
Security, Anti-Cloning, and Standards Compliance
The biggest failure mode in transit is not a broken gate—it is a cloned card draining a stored-value system. Weak or static cryptography lets attackers clone a credential and replay it. Mitigations are well established: use AES-secured DESFire with per-card key diversification, enable secure UID and anti-tearing features, and keep a documented key-management and custody process. For programs that converge with bank cards or national IDs, align to EMV and the relevant ICAO/ISO procurement checklists so the credential fits the wider ecosystem (EMVCo). Our ICAO, ISO 7810, and EMV compliance checklist is a ready-to-use specification appendix.
Frequently Asked Questions
- What is the difference between stored-value and account-based ticketing? Stored-value keeps the balance on the card (secure purse); account-based keeps it in the cloud and the card is just an identifier. ABT is the current default for new programs.
- Which MIFARE chip should a city choose? DESFire EV3 for anything carrying value or multiple applications; ULTRALIGHT C only for disposable, low-value tokens.
- How long do transit smart cards last? Typically 3–5 years of daily use when specified to ISO/IEC 7810 dimensions with durable printing and verified against ISO/IEC 10373.
- Can transit cards work with EMV open-loop payments? Yes—many modern programs accept EMV contactless bank cards and phones alongside proprietary transit cards, which is why specifying the application standard (ITSO, Calypso) matters more than the chip.
Specifying transit smart cards is less about picking a chip and more about matching the card to the ticketing model, lifespan, and interoperability you committed to. Use the checklist above—and before you place a volume order, request physical samples to validate print durability and reader performance on your own gates.
