iOS 13: Set up a Suica card in Apple Pay

Apple Support page for setting up a Suica card in iOS 12

Up until iOS 12 adding a Suica card to Apple Pay Wallet has been centered around transferring a plastic Suica card. The Apple setup page assumes you already have a plastic Suica, there is no mention of adding a virtual Suica card or how to do it. This is changing in iOS 13, the Suica setup focus is no longer transferring a plastic card, it’s all about creating a virtual Suica card in Wallet. This will eliminate a lot of setup hurdles for inbound travelers, and Japanese users too, who want to use Apple Pay Suica:

  • No more need to buy a plastic Suica
  • No more fuss adding the last 4 digits of the Suica ID number
  • No more entering a birth date
  • No more reading Suica card data into Wallet
  • No more dead useless plastic Suica card

The new iOS 13 Set up a Suica card in Apple Pay instructions are this:

  1. Set Region to Japan
  2. Open Wallet and tap the plus sign
  3. Tap Continue.
  4. Tap Suica Card.
  5. Select an amount to put on your transit card.
  6. Follow the steps to create a new transit card on your iPhone.
  7. Return Region to desired preference.

The iOS 13 Suica setup is exactly like the current Beijing/Shanghai transit card setup with one big difference: you use your Apple Pay credit/debit cards to add money to Suica, it’s open ended. China transit virtual cards require an Apple Pay China UnionPay credit/debit card, it’s not inbound friendly.

The Suica setup is inbound friendly, as Apple Pay Octopus will be when it launches with iOS 13. JR East has streamlined and beefed up the Mobile Suica system to accommodate the addition of what will doubtlessly be many virtual Suica cards. It appears that all new Suica cards created in iOS 13 Wallet are the ‘My Suica’ variety, this means they are registered in the Mobile Suica system and you can create more than one.

Creating virtual ‘My Suica’ used to require a Mobile Suica account and Suica App, but if this is no longer the case it suggests that all Apple Pay users adding virtual Suica in iOS 13 Wallet are now registered Mobile Suica users….at least from the backend system operations point of view. I suspect we’ll be getting details from JR East, and a new version of Suica App shortly after the Apple Event on September 10.

There are still some gray areas, such as the status, or necessity of SuicaENG. I hope it sticks around because even though it’s a throwaway one time use app, it adds a virtual Suica without the ‘set Region to Japan’ setup requirement of Wallet. There’s also the problem of Apple Pay Suica card refunds which require a Japanese bank account to receive. I suspect JR East will stick to its guns and tell users to spend the remaining Suica balance down close to zero and remove it from Wallet.

Advertisements

Transit Gate Evolution: Do QR Codes Really Suck for Transit?

The short answer of course is: yes, QR Codes really suck for transit, which Abacus first reported on when the QR code transit meltdown hit Chengdu last April. Abacus is taking a closer look at the problem again in a new piece, QR code payments make long commutes even longer in China:

while QR codes have proven remarkably effective at meeting most people’s mobile payment needs, it seems ill-suited for public transit compared with NFC. Since NFC relies on radio waves, payment requires only a tap of the phone. There’s no need to wake it up or turn the screen on, making it as convenient as traditional transit cards.

The limitations of the <QR> technology are apparent even as cities race to install QR code scanners in turnstiles across the country. Over time, though, the inconvenience might be enough to nudge China away from its reliance on QR codes.

The long answer requires a quick look at transit gate technology evolution. The success of Suica can be found in its development process, a fascinating story by itself. The Suica card and transit gate were developed as one thing to replicate the ease of flashing a commuter pass to the gate attendant without stopping.

A video of old style paper ticket manned gates illustrates the start point. There is no physical barrier. People slow down to get their ticket punched but rarely stop. For a commuter pass the user flashed a wallet with a clear plastic window at the attendant and kept on going, shown at the 0:16 mark:

Shigeo Miki came up with an idea of using IC cards for tickets. The magnetic-type ticket automatic gates, which were in use since the 1980’s, had some inconvenient aspects. Old-style passes could be shown to attendants without being taken out of their cases. But to use automatic ticket gates, passengers had to take them out, pass them through the automatic gate, and then put them away again. He thought that was a decline in service quality…

JR East “Following the track leading to Suica

This was the late 1980’s when IC cards were just coming into wider use, but not for transit. The Suica project had a large impact on Sony FeliCa development as did the Hong Kong Octopus project starting in 1992…

Furthermore, systems that read ID data from read-only cards and interact with the main computer each time someone goes through the ticket gate could not keep up with the enormous volume of data processing transactions in rush hour. So Miki and his fellow researchers perceived that the cards must be read/write types.

There we have it, the Suica project goals were: open gates, waving commuter passes, local processing. Magnetic strip paper ticket gates got faster, Omron states the speed is within 600 Milliseconds (MS), and better with the ability to handle and sort multiple tickets at a time. Suica is cool but nothing is cooler than watching the physical action of a well designed machine:

Despite development problems and a low research priority within JR East at the time, Suica success was achieved by moving the battery supply from the card to the gate and creating fast reliable performance with an illuminated target NFC ‘hit area’ tilted forward at 15 degrees, the same design you see today on the JREM EG-20 transit gate. The EG-20 already looks surprisingly similar to the open public transport gate concept. (Here’s a Japanese website that catalogs every JR East ticket device if you are interested)

Smartcard Transit Gates Compared
Smart transit cards were an important development that revolutionized transit and launched successful systems such as Suica, Hong Kong MTR Octopus and TfL Oyster. However all smart transit gates are not equal. Compare the Malaysia Touch n’ Go gate speed with Suica on EG-20:

One of the commentators notes the crucial differences: FeliCa (used for Suica and Octopus) is the most efficient NFC protocol, 212 kbps minimum/847 kbps maximum, while Touch ‘n Go is mainly MIFARE Classic at 106 kbps an “early form of ISO 14443A, …the least efficient NFC protocol.”

There is another crucial difference: Japan transit gates are open by default and close only when needed, just like the old manned JR gates, while Malaysia and Hong Kong gates are closed on default or use old fashioned turnstiles. The combination of the Ferrari fast FeliCa combined with the well designed JREM EG-20 gate (and variants) that is default open, keeps people moving, best highlighted in a Pokemon Go event ‘Pikachu’ transit gate video:

Suica speed is part of what makes it fun but there is a serious reason behind it: major Japanese transit operators like JR East have to move a tremendous volume of people through a fixed station infrastructure space that cannot be enlarged. Bigger stations with more transit gates are not an option. So the system focus is using the fixed space infrastructure as efficiently as possible. That is why the Suica transaction speed is less than 200 MS, that is why a Suica transit gate must clear 60 people a minute.

Open Loop Multiple Protocol Transit Gates Compared
Using EMV contactless with cards and smartphones, or QR Codes on smartphones for transit instead of native transit smartcards, is a step backwards from the fast read/write local processing model of Suica, and back towards read only centralized processing, one of the original system bottlenecks that Suica was designed to avoid. The QR Codes used for transit in China appear to be particularly slow and a poor match for high traffic stations. Poor gate design is certainly a factor here.

EMV has it’s own transit gate problems as well, as Singapore transit users found out in the recent rollout of EMV SimplyGo service there, things slow down:

It’s fascinating that Singapore’s Land Transport Authority (LTA) dumped the fast FeliCa (rated 200 millisecond transaction but Octopus clocks in at around 100ms) behind EZ-Link cards to roll their own faster CEPAS technology (rated 180ms transaction) but are now letting super slow EMV contactless (500ms plus and counting) on their transit reader infrastructure. It’s like ripping out all the cutting edge transit gate technology and replacing it with clunky old supermarket cash register technology.

The last comment in the first Twitter timeline is an important observation: most EMV transit is simply grafted onto the current transit gate infrastructure which was designed for something else, a factor contributing to unreliable performance, forcing users to adapt. Most of the multi-protocol transit gates in service are poor design.

This leads to another EMV issue users have to adapt to: ‘card clash’. When EMV is bolted onto an existing system slapping a wallet on the transit reader doesn’t work anymore, the card has to come out of the wallet. This is still one of the nice things about plastic Suica cards. Young Japanese women in particular seem to enjoy slapping those cute little Hello Kitty wallets on the gate reader with a surprisingly hard thwack, stress relief perhaps? Chicago Ventra support offers insight on the current state of EMV transit:

  • Get your device ready, first, for fastest entry
  • “Card clash”: touch only your desired payment method
  • Multiple credit cards: always use the same card on the same device on transit readers

These are issues that Apple Pay EMV Express Transit is designed to fix by designating a single EMV bank card for transit but it cannot change the inherently slow EMV transaction speed or solve the limitations of EMV bank card architecture which is basically centrally processed read only. There are limits on how much the central processing read only model can achieve when fast, precise, local transactions are required. All EMV Express Transit does it designate a bank card that tells the transit gate reader: I am a real bank card, not a forged one, we’ll settle the bill later.

That’s why complex transit fares are only supported on read/write native transit cards like Oyster on TfL, not EMV bank cards. It’s also the reason why manual swipe MTA Metrocards will be around for a few more years, the new OMNY Apple Pay Transit was not particularly fast or reliable at startup. Things will get better, a real OMNY transit card for plastic and digital wallets is due to arrive in late 2020. Last but not least, using EMV contactless for transit does carry some potential fraud risk that native transit cards do not.

Japanese IT journalist Junya Suzuki tests OMNY transit gate speed…
and reliability

The China Situation

The Abacus article highlights multiple protocol Chinese transit gates: paper tickets, NFC, QR Codes and Face recognition. Oh, and closed by default gates. This is not a fast transit gate environment.

The Abacus article points out the slow uptake of NFC, blaming it on UnionPay, but it boils down to the PBOC flavored EMV spec itself:

Each card organization has formed its own specifications based on the EMV specification based on its own business refinement and expansion, such as China UnionPay’s PBOC 2.0 specification, VISA’s VSDC specification and MasterCard’s M/Chip specification. Each specification follows the EMV specification for basic transaction processes and security mechanisms, but differs in terms of data element definition and extended application…PBOC based on the EMV standard, combined with the needs of domestic banks, the People’s Bank of China promulgated the PBOC series of standards:
1 PBOC1.0: e-wallet / electronic passbook / magnetic stripe card function
2 PBOC 2.0: E-wallet extension application, debit/credit application, personalization guide, contactless IC card standard
3 PBOC 3.0: Cancel e-wallet and electronic passbook application, cancel downgrade transaction, multi-algorithm extension, multi-application extension, mobile payment standard

Super Lu

Beijing and Shanghai Transit cards were originally MIFARE but instead of examining what technologies would be best for next generation transit needs, China simply migrated them to the much slower PBOC 2.0/EMV specification implemented on the China T-union transit card architecture. The China T-union card is country wide transit prepaid card spec for interoperable transit cards that can work everywhere, similar to what Japan has with Suica, ICOCA, PASMO, etc.

Unfortunately, the rollout of new format card issuance has been slow and piecemeal, with no apparent promotion push to educate transit users. Chinese users familiar with Suica performance find China T-union cards slower and less reliable at the gate. Because PBOC is slow EMV NFC spec 500 MS transaction speed and tightly chained to UnionPay, the transit gate performance edge is not great enough to ween users away from QR Codes and the point benefits of sticking with AliPay and WeChat Pay.

If the performance gain was similar to the huge Suica over QR difference, coupled with an open flexible backend for using different payment methods to add money, China T-union would stand a better chance of nudging QR users to NFC for transit. As it stands now, there’s no real difference between a UnionPay card and a China T-union card at the transit gate. One is post pay, the other is prepaid, 2 versions of the same thing, marginally faster than QR, but not much.

Whatever the causes for the current situation, it’s a perfect gift to Chinese QR code players, I suspect that the arrangement is also a profitable one for the Chinese government on some level because if it was not, they wouldn’t be adding QR Code readers to transit gates.


QR Codes for Japan Transit
Some Japanese tech journalists have fretted about JR East not embracing QR Codes on transit gates because JR Central plans to completely eliminate paper tickets for the next generation Chuo Shinkansen. It’s less about QR and more about eliminating magnetic strip paper tickets. JR East does have limited QR code use for ticket purchases at station kiosks, we’ll likely see wide support of many cashless payment options, QR included, with the new JR East eTicketing system due in April 2020.

QR Codes have seen some limited use on local monorail systems such as Okinawa’s Yui Rail but Suica compatilbilty is coming to the system in April 2020. The next generation Super Suica that does a lot more for much less, will arrive in April 2021. QR Codes for transit use in Japan will reamain a small side show far away from the main attraction.


In summary, the use of EMV bank cards and QR Codes for transit all comes down to transit company priorities for safe operation, better customer service and long term business goals. My position has been and continues to be is that it’s a better long term business opportunity for transit companies to:

  • Offer robust support of bank cards, QR and digital wallets on the backend for adding money to native transit cards on digital wallets and plastic, where they are really useful and add value without giving control away to outside companies.
  • Use closed loop transit gate value capture to focus on building better services tied to transit cards that benefit customers and businesses of the entire transit region, aka the transit platform business model.

It’s a simple choice really, moving people quickly and safely by transit, managed wisely, is a license to make money. A company can either use that license to build something of greater long term value for the users and businesses of the transit region, a win-win, or give it away to someone else.

Apple Pay Octopus Screenshot Leak

There have been plenty of ‘Apple Pay Octopus is coming’ leaks since Octopus Cards Limited (OCL) and Apple started testing in December 2018, but there has not been a single screenshot leak, until now:

The dark mode Octopus card detail UI here does look legit and definitely iOS 13. Oh if I could only get my grubby hands on it. Hopefully we’ll get official details from Apple soon, perhaps in tandem with the Apple Card rollout due this month.

iOS 13 b4 Hong Kong Wallet now mentions ‘Travel Cards’

Apple has not yet officially announced Apple Pay Octopus but the latest iOS 13 beta (developer beta 4/public beta 3) now mentions ‘travel cards’ and ‘public transport’ in the Wallet initial add card screen blurb when the iOS region is set to Hong Kong. You cannot add Octopus yet as that won’t happen until the official release.

No word yet on iPhone 7 and Apple Pay Octopus support, we won’t find out until Apple and OCL announce the officially supported device list, it should be coming soon. Meanwhile FeliCa Dude wrote a very informative Reddit post that definitively covers every facet of iPhone 7 FeliCa support, from Octopus to iOS 13 Core NFC. It’s amazing stuff.

The Mystery of Apple Pay Octopus and iPhone 7 FeliCa Support

There are a few remaining fuzzy spots in the Apple Pay Octopus saga. The story I broke back in December from trusted sources clearly had a Chinese New Year release target. The story went dark but busted wide open again with the Apple Pay JSON server code leak on June 25 that made it absolutely clear Apple Pay Octopus would finally arrive with iOS 13. Octopus Cards Limited (OCL) had no choice but to issue a premature press release stating ‘Apple Pay Octopus is coming, more details soon’ and nothing else.

Why the delay? It clearly was not the Smart Octopus in Samsung Pay exclusivity window that ended in December 2018. We may never know the whole story but I suspect that iPhone 7 FeliCa support is one reason for the delay, but certainly not the only one.

It makes sense for Apple and OCL to release Octopus that can be used on as many Apple devices as possible, the bigger the potential user footprint, the better. Octopus will work on Apple global NFC devices: iPhone 8/X/Apple Watch 3 and later. The important question is how badly do Apple and OCL want to add iPhone 7/Apple Watch 2 to the supported device list?

I previously wrote that Apple announced iOS 13 Core NFC enhanced tag support (FeliCa, etc.) for (all) iPhone 7 devices and later at WWDC19, but this does not sync with Apple Pay Suica device requirements: Apple is telling developers that all iPhone 7 models are good for NFC Read/Write FeliCa but telling customers that only iPhone 7 JP models are good for NFC card emulation FeliCa.

In a later post I quoted FeliCa Dude:

There are millions of NFC-F phones and devices outside Japan. That is because Type A and FeliCa are core requirements for NFC certification. If a phone supports NFC, it supports FeliCa.
What is required to be compatible with most payment terminals in Japan is an Osaifu-Keitai provisioned secure element: that can be a SWP-enabled SIM card (not available yet), the Mobile FeliCa chipset with embedded SE, or an iPhone 7 provisioned for Osaifu-Keitai.
The international iPhone 7s can do basic FeliCa read/write without encryption, because they embed a FeliCa-capable CLF <contactless frontend>. Apple has chosen not to provision them with Osaifu-Keitai keys, probably to avoid paying royalties to FeliCa Networks for each device.

This sparked some fascinating comments from Twitter user Lukas and, lo and behold, the very FeliCa Dude himself, an unexpected and pleasant surprise:

As always, the Dude delivers. Abide in the Dude, his knowledge and keen insight on all things NFC contactless and FeliCa is without peer. In a nutshell this means that OCL could offer Apple Pay Octopus on all iPhone 7 and Apple Watch Series 2 devices and add them to the Global NFC Apple device list…but will they? If OCL and Apple can supply the necessary keys in the over the air (OTA) iOS 13 release via the in-house Apple FeliCa keys server, all the better. Either way I think we will find out very soon, possibly as a ‘Apple Pay Octopus coming to Hong Kong’ side mention in the Apple Card release press kit.

Now that the FeliCa Dude has checked in, I hope he can find an appropriate outlet, blog or otherwise, to enlighten us, whatever the occasion. He is a far better writer than I will ever be. I’ve learned a lot from his writings, I know a lot of other people can too. The world needs to hear from the FeliCa Dude, not my cheap imitation.


UPDATE
FeliCa Dude has answered and posted the definitive take of iPhone 7 FeliCa support for all things from Octopus to iOS 13 Core NFC. We own him thanks for taking the time to cover all the angles in such detail.

The crucial section: “In my opinion there are only three reasons that Apple should not be able to bring Octopus emulation to iPhone 7:

  • If they are unable to allocate IDm (card unique ID) values to these non-blessed devices because that process is tangled up with FeliCa Networks
  • If they shot themselves in the foot and disabled their ability to interface their secure element to the FeliCa CLF (contactless frontend) in the PN67V on those non-Japanese iPhone 7 devices because they didn’t see Octopus coming.
  • They don’t feel like supporting iPhone 7 at all, not even the Japanese models: each device has a different generation of secure element, and additional development/testing/certification work may be required for them. This is again a combination of what Apple is willing to do and on which hardware platforms OCL is willing to authorize Octopus to be emulated on. It’s nothing to do with FeliCa Networks or Sony.”