Is Suica ‘all-in-one’ possible?

Now that Suica 2 in 1 Region Affiliate transit cards are out, it’s time to examine the question that Yanik Magnan posed in his limitless possibility podcast: is Suica all-in-one possible? He defines it as follows: “All-in-one in my case would mean all Transit IC and local area transit members sharing the same physical card as a common container for their data, I’m assuming (maybe incorrectly?) that Suica + PASMO on the same card would be possible through whatever totra is doing.”

In my initial Super Suica coverage I outlined all-in-one possibilities beyond the Suica 2 in 1 Region card program and called it ‘Super Suica’ to capture that idea. Unfortunately, and as Yanik points out, I forgot an important aspect: Suica and sister Transit IC cards all use the same FeliCa technology but have their own data formats. That was an oversight. Nevertheless I think we agree, so I’m retiring Super Suica in favor of Yanik’s Suica ‘all-in-one’ moniker. Here is a grab bag of various pieces that hopefully add up to an quick overview, with Suica all-in-one as a platform of technologies that others can build off of, instead of a specific transit card.

FeliCa Enhancements
Since November 2020 we’ve seen a number of FeliCa enhancements: (1) FeliCa Standard SD2, (2) Mobile FeliCa Multiple Secure Element Domains that support non-FeliCa protocols and, (3) Mobile FeliCa Ultra Wideband Touchless. The most important of these right now is SD2 because it’s a real shipping product with Extended Overlap Service and Value-Limited Purse Service. TagInfo scans of the newly released totra 2 in 1 Suica Region Affiliate transit card reveal Extended Overlap in action. The card itself shows 2 issue numbers on the back, one from JR East who own the SF (stored fare) purse and one for the region operator who own the overall card. That JR East owns the Suica 2 in 1 card SF and float is…interesting and offers a clue as to what’s going on behind the scenes.

FeliCa Standard SD2 powered totra Suica has 2 card numbers

Float Gloat
Who owns the SF purse float, how it works on the reader side and as a business model are the big issues. Here’s an example: I suspect SD2 Extended Overlap might also be used in the new Suica-TOICA-ICOCA cross region commuter passes as those cannot be issued on current plastic and require an upgrade trip to the nearest JR station. We won’t know for sure until we get a TagInfo scan of the new physical card but let’s pretend for a bit.

Say a TOICA user purchases a cross region commuter pass from Numazu (TOICA) to Odawara (Suica) for regular non-Shinkansen transit. In this case the cross region solution is easy and acceptable to all JR companies because each transit card issuer owns the SF purse, in this case JR Central. The same applies to JR East when issuing the same commute pass route for Suica. The same scenario would likely be acceptable to all Transit IC companies, sharing a common physical card as a common container for their data, but only if the SF purse ownership was clearly defined as it is in totra Suica so it works on the reader side: this is Suica SF, this is a ICOCA SF, etc., otherwise the reader doesn’t know which one to use.

In other words, let’s 2 in 1 and all-in-one for the shared resources like points, commuter passes and special discount fares for elderly and disabled users, but the SF purse is not shared for 2 in 1 or anything else. Common data format, yes. Common shared SF purse, no. At the end of the day you can’t have a Suica and a PASMO on the same card as the reader won’t know which one to use. We’ll see if Extended Overlap and Value-Limited Purse solves this wanna have cake and eat it too Transit IC dilemma. Sony is now shipping FeliCa Standard SD2 antenna module chips for the reader side of the equation so readers will be getting smarter and evolve too. That’s how I see it for Suica all-in-one, Transit IC and mobile, a gradual evolution.

Mobile hardware barriers
On the mobile front we have a smartphone hardware barrier: the Mobile PASMO Osaifu Keitai Type 1, Type 2, Type 3, mess landed on Mobile Suica with addition of multiple Mobile Suica cards on March 21. Only Osaifu Keitai Type 1 devices can handle multiple Suica and PASMO cards.

This has implications for Mobile FeliCa features such as the Japanese Government My Number Digital Card and UWB Touchless digital car keys. Mobile FeliCa 4.0 and later on Pixel devices indicate the ability to upgrade FeliCa JAVA Card applets and even Mobile FeliCa itself. Whether Android device makers will actually use this OTA ability is a mystery. To date the standard industry practice has been if you want new features, you buy a new device.

And then there is Apple. iPhone 7 JP models that support Suica do not support PASMO, UWB is only available on iPhone 11 and later, and so on. There is no guarantee that Apple will update, say iPhone 11 models, for UWB Touchless, Mobile FeliCa My Number Digital cards or even Suica 2 in 1, if and when the format comes to Mobile Suica.

We’ll see what FeliCa Dude has to say about the all-in-one subject, hopefully in a future Reddit post. It may take a while but worth the wait.

UPDATE
I’m sticking with Super Suica. Yanik’s All-in-one take is a great name focused on the 2 in 1 card architecture that fits all of Transit IC on a single card. My Super Suica take is a wider set of developing platform initiatives. Yanik’s feedback was valuable in forcing me to review my posts and define Super Suica as a platform, I thank him for it.

Japan Cashless 2021: the Wireless Android NFC Reader Suck Index

You too can have the whole transaction world in your hands with the Android based Square Terminal for just ¥46,980

Now that contactless is everywhere, wireless contactless readers have become very fashionable and popular. Nobody wants wires or checkout lines. All of these systems are built around an Android based reading device connected to the internet payment service via Bluetooth, WiFi or 4G with a main terminal, an iPad or a laptop running payment network software. Convenient though they may be, compared with hard wired NFC reader performance they all suck with different levels of suckiness:

  1. stera: this lovely little ‘NFC antenna under the screen’ piece of shit from SMBC, GMO and Visa Japan is so slow that checkout staff put their hand over the stera screen/reader to keep customers waiting until the device is ready to go. This is followed by the instruction ‘don’t move your device until the reader beeps.’ It’s a 2~4 second wait until it beeps. This is 2014 era ‘you’re holding it wrong’ garbage nonsense. I teased one store manager about the hard wired JREM FeliCa readers that were swapped out with stera, “Those were too fast,” he said. Too fast?!
  2. PAYGATE: Another payment provider associated with GMO, slightly faster than stera but still slow, PAYGATE does’t like Apple Pay Suica•PASMO Express Transit very much. Have of the time it ignores it altogether forcing customers into the 2016 era ‘manually bring up Apple Pay Suica’ authenticate and pay maneuver. Another ‘you’re holding/doing it wrong,’ when the fault is on the checkout system side. Passé and totally unnecessary.
  3. AirPay: It’s weird that the cheap AirPay hardware performs better than PAYGATE or stera, it’s even weirder that AirPay performs better than Rakuten Pay which uses the very same reader but is stera shitshow slow.
  4. Square Terminal has gotten lots of media attention in Japan. Too early to experience it in the field yet but I’m not hopeful. Square Terminal is Android based after all and the NCF antenna under the screen design is the worst performing reader design out there. As one Brazilian reader wrote: “I just don’t like the ones running Android because at least here the software is less reliable and I managed to crash a few one by just taping my phone.”

Yep, that observation matches my experience. Payment network providers need better Android readers, the current crop is too slow getting the payment transaction ready to tap. In this era of endless subcontractor layers in the development process, creating a fast reliable Android based NFC wireless reader might be a tall order, if not impossible. The all over the place wireless NFC reader experience certainly doesn’t boast well for open loop advocates.

UPDATE
I ran across another crappy reader experience (above) and retweeted it. A reader had some questions about it, answered here by an anonymous expert. It basically comes down to poorly executed reader polling or not following Sony polling recommendations for FeliCa cards. This is what is happening in the above retweet. It is also what is going on with PAYGATE Station readers, half of the time the proper code hasn’t loaded correctly although this issue seems to be fixed in new PAYGATE Station checkout installations. Which brings us to the point I was trying to make: these performance issues can be fixed with reader firmware updates or transaction system software updates, but never are.

Wildcard polling involves the reader making a request for system code 0xFFFF and expecting the card/device to list all the system codes that it supports. Wildcard polling won’t work on an Apple Pay device in Express Transit mode – instead, the system code must be explicitly polled for (0x0003 for CJRC, 0x8008 for Octopus). You can cause Suica/Octopus to be automatically selected by sending SENSF_REQ (Polling command, 06) for those services explicitly.

I have verified that doing so with Apple Pay will cause the emulated card to be switched out as appropriate – the IDm value will also change, since Apple Pay emulates each card separately, instead of with a common IDm as with Osaifu Keitai. If you read the Sony documentation, you will see that developers are cautioned to also poll for the specific service codes they want to access if there’s no response to a wildcard poll.

Perhaps your reader doesn’t do this, but it’s fairly big omission…it should be doing explicit polling. Simply polling for service code 0x0003 should wake up Suica if selected as an Express Transit candidate, even if you don’t send any other commands. I’ve verified this with an RC-S380 reader and NFCPay.

Multiple Secure Element domains for Mobile FeliCa 4.1

FeliCa Dude posted a series of deeply interesting tweets relating to Mobile FeliCa 4.1 changes. He had earlier complained of Mobile PASMO lack of Pixel 5 support and it now appears that multiple Secure Element domain support in Mobile FeliCa 4.1 was a reason for that delay. This is an fascinating development but what is it there for?

On a Mobile FeliCa 4.1 Google Pixel device Google has it’s own secure element domain

I assume his tweeted profile is for a Pixel device, hence the FeliCa Networks secure element (SE) + Google SE references. In this context it appears that Google ‘owns’ the Mobile FeliCa SE and which applets load, in other works FeliCa Networks needs permission from Google to load applets on a Google device SE. Devices come pre-loaded as always so customers simply use it out of the box, but the implication is that FeliCa Networks and the SE domain ‘owner’ can load/delete Java Card applets and even update Mobile FeliCa over the air. Whether they actually use this functionality or not is another story.

FeliCa Dude thinks multiple secure element domains are also there to support Ministry of Internal Affairs and Communications (MIC) plans for a digital version of My Number Card (Individual Number Card) for smartphones using the Mobile FeliCa eSE, even though the current plastic card uses NFC-B. It’s strange but exciting to ponder the possibilities of a Mobile FeliCa 4.1 secure element that supports non-FeliCa protocols.

One of the big changes of Mobile FeliCa 4.0 was that it introduced loading a FeliCa applet on any approved secure element. This change frees Android device manufacturers from having to purchase FeliCa chips from the FeliCa Networks supply chain. It basically gives Android devices the same custom secure element arrangement Apple has had since the iPhone 7 Apple Japan Pay launch in 2016.

I asked FeliCa Dude if the Mobile FeliCa 4.1 development is also related to next generation FeliCa feature support used for Suica 2 in1 cards coming this month, in particular the new Extended Overlap Service. He says this is unlikely but I hope we discover other pleasant surprises as intrepid explorers dig into Mobile FeliCa 4.1 details.

MIC digital My Number Card proposal for smartphones

End of the line for Suica and the native Japan Transit IC smartcard standard?

There is a consistent theme among some Japanese tech journalists: the native Japan Transit IC smartcard system is obsolete and destined for that fabled junk heap, the Galapagos island of over-engineered irrelevant Japanese technology. The arguments always boil down to cited higher costs of maintaining the ‘over-spec’ proprietary FeliCa based inflexible transit IC architecture in face of ‘flexible, lower cost’ proprietary EMV contactless bank payment tap cards and smartphone digital wallets used for open loop transit. Is Suica really ‘over-spec’ or is it clever stealth marketing sponsorship from EMVCo members and the bank industry disguised as journalism? Logically the same argument applies to proprietary MIFARE smartcard transit systems as well but is never mentioned, presumably because it was invented in Europe instead of Japan.

Despite all the digital ink on the subject I have yet to see a single article where said costs are actually shown and compared. Smartcard deposit fees are a standard way to offset plastic issue costs and Japanese transit companies like to earn interest off the float of card deposits and unused stored value. But this is never discussed nor the fact that digital wallet issue is free of hardware costs.

Bank payment cards and smartcards have very different business models. EMVCo members and their card issuers can hide associated hardware and licensing costs in bank transaction fees that NXP, FeliCa Networks and other smartcard technology solution providers cannot. Without hard numbers we can only take journalist claims at face value, that transit smartcards are not smart at all, but expensive obstacles to lower cost open loop centralization nirvana.

I don’t buy the ‘one solution fits all’ argument and neither should you. One constant issue in our internet era is that too much centralization is not only a technology monoculture security risk, cloud services fail, and cloud centralization is abused to limit human rights. As speech is censored on SNS platforms and online profiling is used to limit freedom of travel with politically biased no fly lists, it is inevitable that face recognition transit gates will be used to track people and implement ‘no ride’ or ‘limited ride’ policies. These are issues that people must be aware of in the relentless rush towards online centralization of transit payments and services.

Nevertheless there are articles with valid criticisms well worth reading. I ran across one recently by Masanoya Sano on Nikkei that asks a good question: ‘Does taking 14 years to deliver Mobile PASMO mean the transit IC card foundation is crumbling? While I don’t agree with everything Sano san says he makes a good case that Japan Transit IC association members are failing in the face of a hydra-headed crisis: declining population with less ridership, competition from other payment services such as PayPay and EMV based VISA Touch, and ridership killing COVID lockdowns. He argues that transit companies must fix some basic problems if the Japan IC Transit standard is to survive:

  • Increase coverage: get all transit on the Transit IC card service map
  • Go mobile: for all transit cards
  • Improve the transit IC card architecture: improve compatibility and loosen up current restrictions for cross region transit, and the ¥20,000 stored fare limit

I believe most, if not all of these can be addressed with next generation FeliCa + 2 in 1 Suica (aka Super Suica) launching this year and deeper payment infrastructure sharing between transit companies. Nothing is guaranteed of course but here’s a look at each category and possible solutions.

Coverage
The transit IC coverage gap is the biggest failure of Japanese transit companies and there are big gaps. Suica only covers major population areas in Tokyo, Niigata and Sendai, roughly half of the stations on JR East are not wired for Suica. A similar situation applies to the other JR Group companies. JR East has promised to get their entire rail network on Suica with a simplified lower cost cloud based Suica in the 2020 fiscal year ending March 2021 but has yet to announce any details (they are specifically referenced in the new Suica Terms and Conditions effective March 27).

On the plus side JR West is expanding ICOCA coverage with a light rail approach of incorporating NFC readers installed in the train car for tap in/tap out for unmanned stations. No wires. SMBC and VISA use the same strategy for their VISA Touch transit boutique marketing program. It’s a practical low cost strategy for lightly traveled rural lines that reduces the hard wire requirement. Only stations that need it get wired and even those installations can use the lower cost JR East cloud based system.

JR West ICOCA area expansion includes on train NFC readers starting March 13, 2020

All major transit companies need to install these lower cost solutions to fill the transit IC gaps and integrate remaining isolated regions. VISA Touch transit boutiques are marketed as a solution for inbound and casual users, but these EMV only installation leave those transit areas off the transit IC grid for regular users and don’t work for wider area travel.

Mobile
Mobile Suica and Mobile PASMO combined represent 80% of the current transit IC card market. Mobile ICOCA (JR West) is due to launch in 2023. There is no word yet about mobile for TOICA (JR Central), manaca (Nagoya City Transit rail/bus), PiTaPa (Kansai region private rail/bus), Kitaca (JR Hokkaido), Sugoca (JR Kyushu), nimoca (Nishitestsu), Hayaken (Fukuoka City Transit). This is a big challenge but the borrowed Suica infrastructure used for Mobile PASMO is a strategy that can be applied to the other major cards.

Improving Transit IC
JR East is releasing the 2 in 1 Suica card architecture that incorporates new FeliCa OS features the most important being the “2 cards in 1” Extended Overlap Service. New regional transit card using this new FeliCa OS and Suica format are launching this month in Aomori, Iwate and Utsunomiya. The next challenge for JR East is expanding 2 in 1 Suica to existing and important region transit cards inside the JR East transit region such Niigata Kotsu Ryuto and Sendai City Transportation Bureau icsca. The JR Group has cooperated to deliver cross region commuter passes which started in

The ultimate long term success of the Japanese Transit IC systems depends on infrastructure sharing and integration. For this to happen other JR Group companies and private rail outside of the JR East regions have to incorporate the 2 in 1 Suica format and improvements for their own cards and regions. Only when all Transit IC Mutual Use Association members are using the new format can they link and combine services in new ways, and add new features such as raising the stored fare card value above the current ¥20,000 limit.

Will it be enough? I have no idea. Immediately I see problems for the Kansai region PiTaPa card association companies (Hankyu, Hanshin, Keihan, Kintetsu, Nankai) as they have to make fundamental changes to use the new card format. I don’t see a Mobile PiTaPA in its current incarnation and this is why SMBC (who run PiTaPa card accounts) and VISA are targeting the Kansai area for VISA Touch transit: non-JR Kansai transit companies have their backs against the wall and no way easy forward to mobile except for going all in with JR West Mobile ICOCA, or taking what SMBC offers them.

Open Loop competition
Kansai area private rail companies never managed to create the equivalent of PASMO. PiTaPa is a postpay card that has credit card issue checks and cannot be purchased at station kiosks like all other transit cards for casual use. Issue is limited, so Kansai transit companies issue JR West ICOCA commuter passes for people who can’t use credit cards. This is the context surrounding the SMBC VISA Touch transit for Nankai announcement that got lots of press attention as the first major test deployment of open loop on a Japan Transit IC card system.

Junya Suzuki’s latest Pay Attention installment has a deep dive on the VISA Touch Japanese open loop transit system solution powered by QUADRAC Q-CORE server technology. It is the solution also used for the Okinawa Yui Rail monorail fare system that integrates Suica/Transit IC and QR support. He argues that open loop EMV is good enough because, (1) we don’t need the over-spec FeliCa 200 millisecond (ms) transaction speed (it’s actually faster, between 100~150 ms), (2) it has a leg up on future MaaS and cloud integration. Holding onto Suica local transaction performance as ‘faster/better’ is a myth holding back progress.

I have tremendous respect for Suzuki san and his work but his arguments fall down for me here. He completely ignores the white elephant in the room: closed loop is here to stay because the open loop model cannot support all fare options. Even on the open loop systems that he champions, Oyster and Opal for example, closed loop cards are still essential and are transitioning to a closed loop EMV model for digital wallet issue. The only change is the closed loop card transition from MIFARE to EMV because bank partners are running the transit system account system backend instead of the transit company. In other words it has nothing to do with technology at all, it is bank system convenience. Bank convenience is what it all boils down to.

Making the right technology choices are essential in our era of limited resources, ride the right horse and you succeed. I want to believe the cloud holds the promise to extend transit IC to low transit volume rural areas that don’t have it now, but every time I use a slow cloud based stera payment terminal I’m reminded how impractical that approach is for stations with high transit volume.

Does it make cost sense to replace the current transit IC system and re-create it with EMV open loop when Opal, Oyster and OMNY systems will always need closed loop cards? The practical thing is leveraging a good system already in use. Upgrade the Japan Transit IC system we have now, spend precious resources that fix current limitations and extend it with new technologies like UWB Touchless.

The strength and weakness of the Japan Transit IC standard is that it’s not top down but based on mutual cooperation. It’s not one entity but association members have to move forward as if they are one. JR East has been the technology leader and is working to improve and share it at lower cost. 2021 is not the make or break year for Japan Transit IC, but it will be an important and challenging one that will set its future direction.

Related post: The 2 in 1 Suica Region Affiliate Card

The good old Japan Transit IC card mutual use map, all the little one way arrows marked with the ‘IC’ logo pointing outside the main IC area indicate transit system compatibility.

Starbucks officially adds Suica contactless payments…finally

Apple Pay Suica/PASMO finally joined the official Starbucks payment lineup, something that many people have wanted for a long time. Nothing beats Apple Pay Suica Express Transit for grabbing coffee on the run.

I knew something was coming when Panasonic JT-R600 all-in-one readers appeared in Starbucks stores starting last summer. Initially these were for EMV chip cards and came with ‘please don’t forget to remove your card’ reminder stickers. EMV contactless is missing though I suspect it will come at some point. Other FeliCa contactless payments such as iD, QUICPay, Waon, nanaco, and Edy are also missing. Line Pay QR is accepted at some store locations but remains limited for now.

Suica/PASMO (and other eMoney like Waon) has been accepted for years at Starbucks locations in stations and malls where tenants integrate payment+reward point systems provided by the landlord. Suica/PASMO support is not native however and bolted onto the Starbucks checkout system. For JR East station area locations tied into the JRE POINT system this means double entry Suica payments: once for the Starbucks checkout and once more for the Suica/JRE POINT payment reader. This will remain in place until JR East and other retail landlords (PAMSO, etc.) come up with a better system for integrating JRE POINT (etc.) with Starbucks’ native Suica support. The big takeaway is that Suica/Transit IC is officially supported and earmarked for all locations.

Contactless payments are a welcome step forward but I wish Starbucks integrated their own reward points via NFC VAS instead of barcode in Starbucks app nonsense. That way I could get JRE POINT and Starbucks point with a single Apple Watch Suica tap at JR East station Starbucks locations without the hassle of iPhone Face ID with face mask. And while we’re on the subject of NFC VAS reward point cards…JR East hurry up with that JRE POINT card for Apple Wallet please.

UPDATE
Starbucks is running a ¥100 One More Coffee refill campaign with Suica/Transit IC purchase from January 13~June 30, a ¥50 discount. A good reason to kiss the iOS Starbucks App barcode thing goodbye for the duration and use Apple Pay Suica/PASMO Express Transit instead.