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.

A great reality check

I was pleasantly surprised to find some hits coming from a website called limitless possibility, followed the link and discovered a great podcast by Luc-Olivier Dumais-Blais and Yanik Magnan on Japanese transit IC cards, Suica 2 in 1, the new features of FeliCa Standard SD2, Ultra Wideband Touchless and more…things I’ve been writing about for a while that never get any traffic.

Yanik does a much better job of summarizing the transit technology landscape than my messy collection of posts. I wholeheartedly agree that UWB Touchless is the perfect opportunity for Japanese Transit IC members to put aside political differences and merge, or at least ‘harmonize’ their data formats for a real all in one Super Suica. We shall see. There are things coming down the pike such as multi-secure element domain/multi-protocol Mobile FeliCa that might have transit implications. And I thank Yanik for his constructive criticism of my ‘Super Suica’ coverage. It’s very helpful and rare that anybody takes the time these days.

Extra bonus: their discussion of the Japan QR Code payment mess and a sendup of PayPay ‘gamification’ campaigns using the Canadian Tim Hortons roll up the rim thing is hilarious and spot on.

The Open Loop transit privacy question

In 2013 JR East faced a crisis over selling Suica ridership pattern data analysis to Hitachi. The Suica data was stripped of personal information and was used to analyze popular transit routes and create general user profiles based on age group, gender and so on. Media outcry resulted in JR East drafting an opt out data policy followed by Japanese Government laws and regulations covering personal data privacy.

That was then, this is now. Line, the popular messaging service plus Line Pay payment platform, came under attack this week for storing user and transaction record data outside of Japan, in South Korea and China. This is not a surprise since Line started in South Korea and storing data on cloud servers there was always an open secret. Why the brouhaha now? The recent complicated Z Holdings acquisition maneuvers of Line are a factor. With PayPay and Line Pay QR payment empires now in the same house some kind of streamlining is bound to happen. The data scandal could be a convenient excuse to start it.

The constant drip of privacy concerns regarding social networks and QR payment systems like Line Pay, and where user transaction data is stored, makes the old JR East crisis look small and silly. Everything is more connected now in unexpected ways than even just 8 years ago.

It doesn’t matter how secure transaction protocols are when user transaction record data is stored on leaky servers or sold to outsiders for profit. I wrote about this earlier, the so called popularity of QR Code payment services in Japan is really about big data. In that vein we have a timely blog post on Open Loop ltransit rider privacy from Transit Center.

For a professional advocacy organization dedicated ‘to improve public transit,’ the Transit Center privacy publication is surprisingly amateurish. It raises valid concerns but reads like open loop advertising from credit card companies (Transit Center soft sponsors?), where open loop is the golden cure-all future, and the only future at that, of every transit ill with closed loop invariably portrayed as a dead era of tokens, punchcards and mag strip swipe cards. They also make MTA seem like the only transit system in America that matters because idiosyncratic MTA problems apply everywhere. Right? Wrong. Let’s take a look at their privacy blog post…<<with comments>>.

Transit agencies around the country are adopting a new generation of fare payment systems. Agencies including New York’s MTA, Boston’s MBTA, and Houston METRO are in the process of switching to what’s known as “open-loop” systems that enable riders to tap into the system using digital wallets on their phones or with their credit cards…

<<more banks handling transit fare concessions sounds like a good idea for privacy, wait until the TC folks figure out that ‘closed loop’ bank card accounts for digital wallet OMNY is the next step in the game>>

These technologies come with clear benefits for riders, but they also carry the risk of exposing more personal data…

<<here it comes>>

The switch to these new fare payment technologies can accelerate access to riders’ trip data by other government agencies. In New York, for instance, individuals’ MTA trip data can be retrieved much faster with the new OMNY system than with the older MetroCard system…

<<retrieve trip data quickly on a fare system where users don’t tap out…what? privacy concerns are not just government agencies btw with multiple 3rd party companies handling and processing transit fare data…which brings us to>>

The increased involvement of third parties in fare payment underscores the need for better data collection and management policies within transit agencies.

<<better as in more big data details?>>

How to Implement the Next Generation of Fare Payment Without Shredding Riders’ Privacy

Anybody experienced in dealing with bank and card company customer service could see this coming. Bank and transit operating cultures are different and they don’t mix well with outside companies running the transit gate fare concession. If you think transit privacy is a concern now, wait until face recognition transit gates become the next transit future thing.

Let’s make this simple. Open Loop (EMV and QR) and bank card EMV Closed Loop means that banks and outside payment platforms run their services at the fare gates They have transit user data, as does the transit company, so does the fare system management subcontractor like Cubic. The more places data is stored the more it’s gonna leak. This is exactly what is playing out in Japan right now because Line Pay Japan user transaction data is stored in South Korea which does not, putting it mildly, have a good secure data reputation.

That doesn’t mean that closed loop is automatically more secure, but keeping data in-house with its own closed loop transaction card in the country of origin, as JR East does for Mobile Suica, does mean that outside company access is tightly controlled. At the very least there is only one company in the country of origin to take the blame when something leaks, and only one place to plug 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.

Riding 272km on 42km ICOCA fare

The ICOCA IC fare region extensions that went into effect March 13 have opened up some interesting transit possibilities. ICOCA has a 200km travel limit but the exit gate fare is calculated by the shortest route possible. YouTuber yasu who specializes in convoluted transit IC travel, posted a video that details his very long transit from Kyoto to Osaka in three sections as a single trip using Apple Pay Suica.

Section 1: Kyoto to Wadayama via Fukuchiyama (Sanin and Fukuchiyama lines)

Section 2: Wadayama to Himeji on the Bantan line

Section 3: Himeji to Osaka on the Sanyo line

This is a 272.6km trip that costs ¥3,410 but ICOCA only charges the shortest possible distance of 42.8km that costs ¥570 when exiting the Osaka station gate. Yasu stayed ‘inside the gate’ the whole journey but there is an in-station gate point at Himeji station between the Bantan and Sanyo lines. Logically this is where the ICOCA system could calculate a fare but JR West doesn’t do so.

Yasu points out that this ‘over the limit’ travel is covered in section 16 of the ICOCA terms and conditions and his trip is not breaking the rules. He contacted JR West before the trip and they confirmed this is possible and not breaking the rules, but this kind of loophole can disappear in the wink of an ICOCA system update.

It’s a 40 minute video but has great scenery and JNR era diesel-electrics still in service on the Bantan line with distinctive traction motor sounds, sights and sounds that are disappearing fast, captured like an O. Winton Link recording. The food at Himeji station also looks delicious. If I was still living in the Kansai, I’d gladly spend a day traveling this route on a single ¥570 Apple Pay Suica fare. It would be a fun journey.