iOS 13: Set up a Suica card in Apple Pay

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

Up until now, adding a Suica card to Apple Pay Wallet has been all about transferring a plastic Suica, My Suica or Commuter 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 will look like this:

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

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 will be inbound friendly, as will Apple Pay Octopus which is also due to launch 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
Featured

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 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 local transactions are required. That’s why complex transit fares are only supported on read/write native transit cards like Oyster on TfL but not EMV bank cards. It’s also the reason why manual swipe MTA Metrocards will be around for a while, even Apple Pay Transit on OMNY is not particularly fast or reliable:

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

Last but not least, using EMV contactless for transit does carry some potential security risks that native transit cards do not.


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 China Situation
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 China migrated them to the 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, 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.

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 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 Card and Apple Cash Trademark Applications for Japan

The CoRRiENTE.top site reports a JP trademark bot tweet that shows Apple applied for Apple Card and Apple Cash trademarks in Japan on July 16, the trademark bot tweet itself is dated August 4. The application follows recent similar moves in Europe and other countries. The official launch of Apple Card in America is expected in the next week or so.

Japan will likely be unique in that Apple Card and Apple Cash in other countries will be EMV only, but FeliCa and EMV dual mode for Japanese digital issue. Mastercard, American Express and JCB already offer dual mode service for Japanese issue Apple Pay credit cards, which work well with NFC switching introduced in iOS 11 and global FeliCa iPhone/Apple Watch.

If Apple really wants to innovate with Apple Card, leverage the global NFC capabilities of iOS 13 and iPhone, and leave outdated single mode plastic credit card business practices in the past, they should go all in with dual mode Apple Card for all regions. After all it is Apple’s card, and virtual like the Apple Card tag line says, “Apple Card lives on your iPhone, in the Wallet app. And that makes all kinds of new things possible.”

Mastercard has been the most aggressive card company offering dual mode for Japanese Apple Pay card holders. Offering dual mode for virtual Apple Card customers everywhere can be done and would be one heck of an innovation for inbound visitors with iPhone and Apple Card for the Tokyo Olympics.

It will be interesting to see how Apple integrates Apple Card with the Japanese contactless payment networks: iD, QUICPay, and NFC Pay, how Apple Card/Apple Cash integrate with Suica Recharge and what kinds of reward points are offered.

Pixel 3 Global NFC Evolution

Reader feedback and discussion from my earlier post analyzing the fuzzy state of iPhone 7 FeliCa and its possible support of Apple Pay Octopus, resulted in some interesting information about the Pixel 3 Japanese FeliCa model. From FeliCa Dude’s epic Reddit Octopus on iPhone 7 post:


<reader comment> Regarding the Pixel though, are you sure that the non-Japanese Pixel 3 models even have an eSE <embedded secure element>? I was under the impression that these were HCE <host card emulation> only.

<Felica Dude answer> All the Pixel 3 devices have an eSE, but it might not be able to be enabled by the end-user, and even if it is possible, it won’t be provisioned. A teardown of the global edition Pixel 3 XL (G013C) reveals a <NXP> PN81B.

The NXP PN81 announced in February is all-in-one off the shelf global NFC chip that includes both the frontend NFC A-B-F hardware and the necessary embedded secure element (eSE) + keys for EMV, FeliCa and MIFARE. The odd thing is that the Google Pixel 3 Japanese model apparently doesn’t use the PN81 for FeliCa, and has a separate FeliCa chip sitting in the fingerprint sensor assembly inside the back case.

Google Pixel 3 JP SKU iFixit teardowns do not exist but I did run across an interesting article from the Keitai Watch site showing a Pixel 3 JP SKU being taken apart for repair at an iCracked repair shop.

Just for kicks, I called the iCracked shop and asked about repairing a faulty FeliCa Pixel 3 device. The Pixel 3 repair technician explained that a FeliCa chip replacement was not expensive because it is not on the motherboard, “it’s attached to the fingerprint sensor assembly.” Look carefully at the picture from Keitai Watch piece and you can see the back case with fingerprint sensor assembly that the technician was referring to.

Disassembled Pixel 3 JP model from Keitai Watch

This presents a very strange situation. All Pixel 3 SKUs have the FeliCa ready PN81 chip but don’t use it, while Pixel 3 Japan SKUs apparently have another separate FeliCa chip attached to the back case finger sensor assemble. Google alludes to this on the Pixel 3 support page: If you purchased your Pixel 3 or Pixel 3a phone in Japan, a FeliCa chip is located in the same area as the NFC. There is also the recent batch of Pixel 3a Japan SKUs with bad FeliCa chips, but reports of bad NFC (EMV) Pixel 3a international SKUs have not surfaced; this also suggests a separate FeliCa chip. Why have two FeliCa chips in a device when one will do?

My take is different from FeliCa Dude: the Pixel 3 does not use the PN81 eSE or ‘pie in the sky’ HCE for anything. Instead, Google Pixel 3 uses the Titan M chip Secure Enclave as the virtual eSE for EMV and MIFARE, similar to what Apple does with the A/S Series Secure Enclave. Titan M FeliCa support was either not ready, or Google wanted to test the Japanese market before making a custom hardware commitment.

The point of all this is that Google has laid the foundation for a global NFC Pixel 4 made possible by a custom Google chip. The Titan M is Google’s answer to Apple’s A/S Series Secure Enclave that can host any kind of virtual embedded secure element for any kind of transaction technology, from EMV to PBOC.

I might be wrong, but even if my virtual eSE on Titan M take is incorrect, taken all together with the NXP PN81 development, I think Pixel 4 will finally be the global NFC Android device that many have hoped for.

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.