Transit Cards on Mobile

Transit cards on mobile devices first appeared in 2006 with the launch of Mobile Suica, the world’s very first comprehensive transit on mobile service. With the arrival of digital wallet platforms from Apple, Google and Samsung in 2015, mobile transit cards have gradually become widely available outside of Japan. The first mobile transit card on Apple Pay was Suica in 2016.

The chart below lists native transit cards hosted on embedded secure element (eSE) mobile digital wallets by service launch year. Entries are limited to native transit cards defined as reloadable virtual transit cards already in service or formally announced by wallet platform vendors (Apple/Google/Samsung/etc.) and/or transit agencies. Open Loop service is not listed. The chart is best viewed in landscape mode.

YearCardAreaOperatorDigital WalletNFCProtocol
2006
Mobile SuicaJapanJR EastOsaifu Keitai SymbianFMobile FeliCa
2011
Mobile SuicaJapanJR EastOsaifu Keitai AndroidFMobile FeliCa
2015
TmoneyKoreaTmoney Co. LtdSamsung PayAMIFARE
cashbeeKoreaEB Card Co.Samsung PayAMIFARE
2016
Mobile SuicaJapanJR EastApple PayFMobile FeliCa
China T-UnionChinaVariousHuawei Pay Samsung PayAPBOC 2.0
2017
Beijing
Shanghai Transit
ChinaBMAC
SPTCC
Apple PayAPBOC 2.0*
2018
iPassTaiwaniPass Co.FitBit Pay Garmin PayAMIFARE
EasyCardTaiwanEasyCard Co.Garmin PayAMIFARE
HOPPortlandTriMetGoogle PayAMIFARE 2GO
Smart OctopusHong KongOCLSamsung PayFMobile FeliCa
2019
HOPPortlandTriMetApple PayAMIFARE 2GO
Mobile mykiVictoriaPublic Transport VictoriaGoogle PayAMIFARE 2GO
NavigoParisÎle-de-France MobilitésSamsung PayBCalypso
2020
ShenzhenGreater Bay RegionShenzhen Tong LimitedApple PayAPBOC 3.0
GuangzhouGreater Bay RegionGuangzhou Yang Cheng Tong LimitedApple Pay APBOC 3.0
FoshanGreater Bay RegionApple Pay APBOC 3.0
SmarTripWashington DCWMATA/CubicApple PayAMIFARE
EasyCardTaiwanEasyCard Co.Samsung PayAMIFARE
Mobile PASMOTokyoPASMOOsaifu KeitaiFMobile FeliCa
Mobile SuicaTokyoJR EastGarmin PayFMobile FeliCa
Smart OctopusHong KongOCLApple PayFMobile FeliCa
TAPLAMETRO/CubicApple PayAMIFARE
Apple Pay PASMOTokyoPASMOApple PayFMobile FeliCa
VentraChicagoCTA/CubicApple PayAEMV
2021
VentraChicagoCTA/CubicGoogle Pay
(announced)
AEMV
*iOS 11 Apple Pay Beijing/Shanghai transit cards were not full spec PBOC 2.0 and listed as ‘beta’

Mobile transit card protocol overview
The current lineup of transit card payment mobile protocols are FeliCa, MIFARE and PBOC 2.0/3.0 and Calypso. PBOC is the Chinese variant of EMV, the slowest of the protocols, designed for leisurely supermarket checkout not transit gates at rush hour. Transit has special needs for fast fare processing at the gate to keep people moving and operations safe. Here is a good rundown of the technologies and tap times.

While transit gates and NFC processors are found worldwide, what makes the Japanese gates different from the rest of the world is they don’t use global standard ISO 14443 (never mind Type A which uses Miller bit coding, the least efficient bit coding method) protocol which is common in many transit and bank cards issued worldwide.

The tap time with ISO 14443 Type A (née Philips) and B (née Motorola) varies greatly: from 200 to 500 milliseconds (ms) with 200 ms only achievable with Type B/Calypso. But it never reaches the short as 100 ms which is only achieved with Felica developed by Sony, also designated NFC-F and NFC Tag Type 3 by the NFC Forum and compatible with ISO 18092 which is commonly found in smartphones and NFC wearables since 2013. In this video passengers maintain their walking pace but never overshoot and trigger a gate closure nor slow down not even a bit.

It may be a minor difference but due to the high volume of passengers per gate (comparison example of large crowds at gates in Malaysia and Japan) and to reduce gate maintenance requirements, taps times really matter. Companies such as JR East have specified tap time of 200 ms but Suica is actually faster and this allows real life speed tolerances: some passengers tap faster than others due to walking pace, the higher speed tolerances are only possible with the 100 ms tap time of FeliCa.

Open Loop NFC ticketing (in its current form, EMVCo Contactless specifications are adopted in contactless bank cards issued worldwide including China UnionPay QuickPass which is PBOC derived from the EMVCo Contactless spec and uses the ISO 14443 Type A at 106 kbps only for 500 ms tap time, which is adopted in cities worldwide such as London, New York, Moscow and Rio de Janeiro is never supposed but as seen here, transit cards in Japan such as Suica, PASMO and ICOCA are supported for ultra hight speed and precise account verification and fare processing. Transit cards use offline Stored Fare (SF) which includes the amount of funds stored in the card’s IC smart chip data storage, NOT backend on a server like a bank card, and stored commuter passes.

YouTube comment explaining the speed differences between NFC types (blocked outside of Canada), edited for clarity

Both Japan and China have de facto national transit card standards. Japan has Suica, ICOCA, PASMO, etc., which share the same basic architecture that gradually evolved into mutual compatibility and expanded national use from 2001~2013. This is now called Transit IC. The PBOC 2.0 China T-union card spec is the Chinese mainland standard for interoperable transit cards on plastic and mobile that was created in 2012 to replace existing MIFARE and FeliCa based transit cards.

The interesting thing about the latter is that many Greater Bay Area transit cards were FeliCa based cards and users really noticed the difference when China weeded them out for slower PBOC 2.0 powered China T-Union cards:

Compared to other contactless smartcards in use, the data transmission of <PBOC 2.0 China T-Union> Yang Cheng Tong is criticized by commuters that it takes 1~2 seconds between the card and reader to complete the transaction, though the operator claims that the data communication only takes 0.5 seconds in its official site.

Wikipedia Yang Cheng Tong

My take is the slower China T-Union speed is one factor driving the popularity of QR codes for transit in China: there isn’t any speed difference between the two so most people choose AliPay and WeChat Pay for the convenience of reward points, campaigns and more services.

This Wikipedia chart needs to be updated but illustrates how many China T-Union cards there are

Mobile transit cards vs Open Loop
Mobile FeliCa developed by Sony and NTT Docomo has been around the longest and works across multiple mobile hardware platforms from Symbian handsets, to Android, to iOS/watchOS and now Garmin Pay Suica. MIFARE has a shorter history on mobile. PBOC 2.0/3.0 is basically new. The key period is 2015~2016 which saw transit card debuts on Apple Pay, Samsung Pay and Huawei Pay.

The biggest advantages of transit cards in digital wallets is the freedom of anywhere anytime recharge with credit/debit cards; transit users are no longer chained to station kiosks to recharge plastic smartcards with cash or renew a pass. The more payment options supported on the recharge backend, the more convenient the card is.

These are great customer features, so why is it taking so long to get transit cards on mobile in America and Europe when there are some 257 China T-Union transit card compatible transit authorities already on mobile?

Blame the slow mobile transit card rollout on open loop
Many transit card fare systems outside of Asia are managed by Cubic Transportation Systems, including Oyster, Opal, Clipper, OMNY, Ventra and SmarTrip to name a few. Cubic and operators like Transport for London, Transport for NSW and New York MTA have focused primarily on Open Loop EMV card support as their mobile solution instead of hosting native virtual transit cards.

Publicly run transit system resources are limited so using bank cards for open loop transit is seen as a way to reduce costs for both fare collection and plastic card issue. The downside is that open loop support adds a layer of complexity and cost that stymies native digital transit card support. In other words it eats up precious system resources while banks get a cut from transit gate transactions. The end result is that native transit card mobile support is a secondary priority, if at all.

Cubic’s very first virtual transit card effort, the long delayed Apple Pay Ventra, is all the evidence you need when open loop is a priority and transit cards are not. Apple Pay SmarTrip and Apple Pay TAP launching first is no coincidence: neither system supports Open Loop.

Steve Jobs explained it best in his last All Things D appearance. A great product or service comes down to focus and choices, either you can focus on making certain technologies work great on your platform versus just okay because you’re spreading yourself too thin. Ventra is spread too thin, that’s why Apple Pay Ventra and Google Pay Ventra have been delayed more than a year after being announced.

For this reason I think transit cards on mobile will continue to arrive in a slow trickle despite recent announcements like the Google Pay and Cubic alliance.

China T-Union: centralized straightjacket cloud for mobile
The large deployment of PBOC 2.0/3.0 China T-Union cards on mobile has been cited as proof that it’s ‘better’ at mobile than FeliCa and MIFARE, but the reality has nothing to do with protocols or smartphone hardware. It is all about streamlining, centralizing and eliminating choices on the cloud side:

  • All China T-Union cards share a common recharge backend cloud provided by UnionPay. It’s the reason why China T-Union only support UnionPay recharge and sport a similar logo. It’s all one package.
  • China T-Union cards on mobile have to be created on the device, plastic card transfers are not supported. Local transit agency transit card apps are intentionally crippled and do not support any NFC features. Apple Support pages do not mention plastic card transfer.

Eliminating plastic card transfers reduces management hotlist headaches and the UnionPay recharge backend shared by all transit cards with the same card architecture makes hosting virtual cards simple because it’s the same centralized IT backend running everything. The various transit operators only need to plug into it. They don’t have to host everything directly or build a cloud backend from scratch, and there’s nothing to negotiate because UnionPay runs the payment network.

China T-Union illustrates the power a national transit card standard backed with a single common cloud resource, but it’s a streamlined straitjacket.

Every country and region has their own priorities and services for area transit, as it should be. My position is a simple one: even if a transit company does not implement a transit platform business model, there is a lot to learn from that model that can be adapted to local regions for long term sustainable transit in the mobile payments age.