All three fare systems are managed by Cubic Transportation Systems who also run the London Oyster and Sydney Opal systems. Cubic systems all use the same MIFARE smartcard technology but the interesting thing about SmarTrip and TAP is: (1) they are the first Cubic managed digital wallet transit cards, (2) neither system has implemented open loop fare payments for tap and go credit cards.
Ventra, Oyster and Opal all have open loop, and as of this writing Cubic has yet to deliver those transit cards on digital wallets. Why?
The SmarTrip/TAP Apple Pay launch gave us the answer that nobody wants to discuss: open loop support adds a layer of complexity and cost that stymies native digital transit card support. Complexity and higher cost means fewer choices, delays, and lousy performance, simple as that.
Steve Jobs explained it best in his last public 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 when you’re spreading yourself too thin. Ventra is spread too thin, that’s why Apple Pay Ventra and Google Pay Ventra are delayed more than a year after being announced.
Open Loop is sold as the cost effective future of transit ticketing but it’s had a surprisingly rocky time in the American market. The failure is pinned on transit companies but I think credit companies are to blame. The arguments for open loop are plastic era constructs that ignore how mobile digital wallet platforms and mobile apps have changed everything. For example the oft cited open loop benefit of plastic smartcard issue cost savings completely overlooks the cost savings of digital transit cards on smartphones.
It’s high time for the credit card industry to rewrite the open loop marketing script for the mobile era, but they don’t want to do that. Expect more of the same. In the meantime, let’s hope the SmarTrip and TAP Apple Pay rollout is a sign that Chicago will be getting Apple Pay Ventra soon.
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 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.
*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. PBOC is the Chinese variant of EMV, the slowest of the three 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, but users really notice 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.
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 real speed difference between the two so most people choose AliPay and WeChat Pay for the convenience of reward points and campaigns.
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 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?
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 eats up precious system resources and 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 have already launched, neither system supports Open Loop. Despite the recently announced Google Pay and Cubic alliance, I think transit cards on mobile will continue to arrive in a slow trickle.
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 the protocol ‘better’ than FeliCa and MIFARE, but in reality has nothing to do with protocols or smartphone hardware. It is all about streamlining and centralizing 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.
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 there is nothing to negotiate and it’s the same centralized IT software stack running everything. The various transit operators only need to plug into the network. They don’t have to host everything directly or build a cloud backend from scratch, and there’s nothing to negotiate because UnionPay is the only payment network.
China T-Union illustrates the power a national transit card standard backed with a shared cloud resource but it’s a streamlined straightjacket.
Hong Kong Octopus Card Limited and MTR on the other hand have been slow adding mobile transit service. The Apple Pay Octopus launch in June 2020 was a big success. In the long run however, Octopus will become another China T-Union card.
Apple Pay Ventra The native Chicago Ventra transit card on Apple Pay is a big deal that was announced back in March. It represents the first major native transit card for the USA on Apple Pay. The much smaller Portland transit system HOP card landed safely in Wallet in May, but Ventra is still listed as ‘coming soon.’ The fault is not with Apple but with Cubic Transportation Systems who operate transit fare systems for Ventra, New York OMNY, Transport for London (TfL) Oyster, Sydney Opal, Washington DC Metro, and many more. For all of their supposed system expertise, Cubic was extremely slow rolling out Apple Pay Express Transit on TfL and has yet to deliver a single native transit card on Apple Pay or Google Pay. I hope Cubic does a better job in 2020.
Apple Pay Octopus The Apple Pay Octopus ‘now you see it, now you don’t’ saga of 2019 was strange and ultimately sad. The Apple support side was all ready to roll with iOS 13. Octopus Cards Limited announced Apple Pay support back in July with ‘coming soon’ website artwork that was pulled when the launch was officially delayed on December 19. My take is that OCL parent Hong Kong MTR made, or was forced into, a political decision to limit services, starting with the unexplained service outage of Smart Octopus during the Hong Kong Polytechnic University siege. This is not a popular opinion.
Readers have reported riot damage to MTR infrastructure and suggest this might be a reason for the Apple Pay Octopus delay. I don’t buy it. Hong Kong MTR, or someone higher up, wants to limit services and control movement, not open them up. But this introduces great risk: moving people are moving money. Limit services and the flow of people, and you limit the flow of money. In this scenario Hong Kong doesn’t have a future. More than anything, I hope Hong Kong gets it’s future back in 2020.
Apple Pay Express Transit arrived on the Transport for London system over the weekend, some 6 months after it was announced. The other 2 remaining Apple Pay Transit cards announced for later this year are Chicago Ventra and Hong Kong Octopus. I already wrote about Octopus not launching this year. The Ventra odds seem a little better. On the bright side Ventra is run by Cubic, the same folks who operate the TfL and New York OMNY systems and already have EMV Apple Pay Express Transit support up and running. Also the Ventra Chicago Twitter account did mention Apple Pay Ventra as ‘coming later this year’ in a Nov 30 tweet.
On the not so bright side, Apple Pay Ventra is the native MIFARE transit card, the first native transit card that Cubic has ported to a digital wallet and a big complicated transit system at that. Nevertheless, Ventra is telling users that Apple Pay is coming this year. Let’s hope for a successful 2019 launch in the next few weeks.
discover their iPhone X NFC is wonky on transit gates
discover their iPhone X Apple Care is expired
As much as my iPhone X Suica performance was a headache, my iPhone XS Suica performance is a joy. To be honest, I have not kept up with the iPhone X Suica NFC issue as most of the users who complained about having the problem have long since gotten Rev. B iPhone X replacements and moved on, or moved on to Pixel 3 JP FeliCa devices.
Most iPhone X NFC problem devices are sleeper cells, the user doesn’t live in a demanding enough NFC use environment to actively notice the issue. The iOS 13 release is due September 19, Apple Pay Octopus and Apple Pay Ventra should be online soon after, barely a month before iPhone X Apple Care dead hour.
Getting a replacement iPhone X for unacceptable NFC performance was never easy, but it’s about to become extremely difficult, if not impossible. Good luck to all iPhone X users out there, may the NFC be with you.