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.

Sorry PRESTO but your open loop video is fake Express Transit (Updated)

UPDATE
March 16: The PRESTO UP Tickets and Fares page now lists EMVExpress Transit support, but no mention of any similar benefits using Google Pay. The Apple Pay Transit support page does not list Express Transit for Canada yet, but the last update was February 3. The PRESTO page also mentions an interesting iPhone issue: “Some iPhone models (8 and earlier), may experience an error message when tapped on a PRESTO device. If you tap with an older Apple device and see a message saying that multiple cards were detected, simply tap your device again and the PRESTO device should accept your tap.” Sounds like a pilot program for teething open loop use issues. No mention of a digital PRESTO card of course. I suspect that when it comes (much later), it will be a closed loop debit card like Apple Pay Ventra.

Apple did a similar Express Transit deal for NYC OMNY, which was basically a very long pilot program and gradual rollout. PRESTO UP is also a pilot program but has an advantage over OMNY in that the PRESTO contactless transit card has been in service since 2009. People are used to it, only the smartphone wallet aspect is new. Meanwhile OMNY is still nursing off the ancient mag-strip swiping MTA Metrocard without a replacement. It will be interesting to hear customer feedback regarding the PRESTO EMV Express Transit experience…for real.


The Metrolinx PRESTO UP service started an open loop contactless payment pilot program this past week. It’s the first step for open loop support across the entire PRESTO fare system. The coverage on MacRumors and elsewhere, and the PRESTOcard youtube video itself makes it look like PRESTO already supports Apple Pay Express Transit when it apparently does not. Apple is very picky when it comes to certifying which open loop transit systems support EMV Apple Pay Express Transit. There aren’t any in Canada. The U.S. has three: NYC OMNY, Chicago Ventra and Portland HOP.

Unfortunately the PRESTO video uses post-production tricks to fake Apple Pay Express Transit. There are three instances: the 1:14 PRESTO reader, the 1:30 onboard verification check, and the 2:16 PRESTO reader. Each of these require a Face ID without mask or passcode Apple Pay authorization. As a reader pointed out the post-production folks neglected to fix the Apple Pay passcode request screen to match the reader ‘Accepted’ screen. Metrolinx promoting PRESTO open loop rollout so people will use it is one thing, but deception isn’t doing users, or PRESTO, any favor.

It’s official: Face ID sucks with face masks

I was disappointed when Daring Fireball finally checked in on the Face ID face mask problem in the iPad Air w/Touch ID power button review. It summed up western tech journalist ignorance and indifference to a big problem that Face ID users in Asia have been dealing with since iPhone X day one. DF’s latest take on the issue in ‘Unlock With Apple Watch’ While Wearing a Face Mask Works in iOS 14.5 is even more disappointing, finally admitting that, “Prior to iOS 14.5, using a Face ID iPhone while wearing a face mask sucked.” This is pure ‘let’s not admit a problem until there’s a fix’ Apple apologia that is all too common on tech sites. DF hasn’t played straight or gotten it right when it comes to the big picture of Face ID. Then again the site is more into politics than tech these days.

Twitter followers pointed out that Apple went with Face ID knowing the trade-offs they were making in Asian markets but it was the right choice. I don’t know how much the Face ID face mask problem was on Apple’s radar during iPhone X development. But there was some arrogant, ‘we can blow off a few Asian customers’ attitude in that choice that Apple is paying for now. Face ID iPhone was quietly removed from how to videos on the Suica•PASMO promotion page in October. Face ID iPhone 12 sales might be driving 5G growth in the USA, but Tsutsumu Ishikawa reports that Touch ID iPhone SE sales in Japan are stalling the 5G transition.

I say this because there was certainly plenty of Apple arrogance when they blew off iPhone X Japanese users suffering from the notorious iPhone X NFC Suica problem. It didn’t matter because it was a iPhone problem…in Japan. It took me 3 exchanges to finally get a NFC problem free iPhone X revision B unit and I was one of the lucky ones. There were, and still are, plenty of iPhone X users fumbling in the dark. To this day iPhone X NFC problem search hits are the #1 hit on this site. Years later I am still outraged by Apple’s secrecy and denial of the issue. There was no excuse hiding the problem so that people would keep buying a defective top of the line product.

So no, I don’t think iOS 14.5 Unlock with Apple Watch is a solution for the Face ID face mask problem. It’s a stop gap until we get an ‘Apple finally figured it out’ iPhone that reviewers will gush over. And it performs like a stop gap: even in iOS 14.5 beta 2, one out of three Face ID with face mask attempts fails for me and performance is often sluggish, particularly glitchy when listening to Apple Music and using Apple Pay Suica transit.

iOS 14.5 Face ID sucks less for Apple Watch users, that’s all. People who make excuses for Apple’s hardware mistakes and missteps aren’t helping people make the right choice before plunking down hard earned money on expensive devices. Nothing is worse than having to live with somebody else’s mistake, except for having to live with somebody else’s deception.

Apple Pay Clipper

UPDATE 4-15: Apple Pay Clipper launched April 15, digital card issue in Wallet and plastic card transfers are supported with matching real-time transit info in Apple Maps. Interesting details: (1) iPhone 8 or later with iOS 14.3, or Apple Watch Series 3 or later with watchOS 7.2 or later, (2) Adult, Youth, Senior, and RTC Clipper cards can be transferred, (3) in order to use Clipper with Apple Pay on SFMTA cable cars and other transit services using handheld card readers, all customers must authenticate with Face ID, Touch ID, or passcode (sounds like those handheld readers need a serious upgrade). Download Clipper App from the App Store.


February 18

Apple announced Clipper Card for Apple Pay today on a special page, Apple Pay Express Transit is finally coming to Apple’s San Francisco Bay Area home turf. Clipper is due to launch on Google Pay the same time. There are few details other than it works on all Bay Area transit and since open loop isn’t a thing there, it will be the same MIFARE card on Apple Pay that we saw with SmarTrip, TAP and HOP.

Unfortunately the Apple Pay Clipper image does not show an ‘Add Money’ button, it’s on a reader after all. Apple carefully crafts images to show card features. To me Apple not including an image showing the ‘Add Money’ button could mean that users reload/recharge the Clipper stored fare card balance with an app, like Apple Pay Ventra and Apple Pay HOP, instead of directly in Wallet like Apple Pay SmarTrip.

This could be a problem for Apple Watch users as they would have to use an iPhone Clipper Card app to reload and basically chains Apple Watch to iPhone. A Clipper app doesn’t exist yet but has to be in place on iOS and Android for a mobile Clipper service.

Some transit agencies stupidly keep the recharge backend locked in their app instead of leveraging the convenience of Apple Pay Wallet reload which makes the digital transit card less flexible and useful than it could be.

Let’s hope for the best launch day outcome. Meanwhile Apple Pay Suica remains the first and best implementation of a native mobile transit card on the Apple Pay platform, the best role model for a transit company to follow.

UPDATE 2-23
Good news. Apple Pay Clipper testers report on Reddit that direct Wallet reload/recharge is supported. Apple Watch transit users can rejoice. Both plastic Clipper card transfer and direct Clipper card creation in Wallet are supported and just like Suica transfer, the plastic card cannot be used afterwards. Could be a iOS Clipper app won’t be necessary for basic housekeeping after all.

UPDATE 2-18
There were a number of interesting and thoughtful Twitter threads in connection with the Apple Pay Clipper announcement.

> lordy if only we had suica in north america

>> Imo, successes like Suica is a testament to solving back-end issues (fare integration, product partnerships beyond transit, UX) and using the front-end tech to unleash full potential…Apple/Google Pay for local transit cards in the US is just not that level of breakthrough

> Yeah, exactly; the frontend technology can only be as useful as the backend system allows.

Thread

It’s heartening to discover comments that ‘get it’, that is a great mobile transit platform leverages a great front-end to unleash the potential of back-end while adding new services and product partnerships beyond transit. If only North America had Suica indeed, folks would really enjoy Apple Pay Express Transit for purchases too.

I know you’re on the closed loop side of this but imo it depends on relative power of transit vs. credit cards. In Japan CCs are not as popular so Suica was ready to take over contactless (and back integrating into CC top-up. In London both are popular so they got both…but most in US don’t use transit enough to justify a top-up card, so I’d prefer NY’s open loop over SF asking frequent travelers to switch from Clipper to Apple Pay Clipper, despite all the limitations in riding experience.

Reply

Popularity doesn’t matter, solutions matter. For years London TfL used EMV open loop in an attempt to get rid of Oyster cards but open-loop cannot replace closed-loop cards, only complement them. So now we have open-loop 2.0: EMV closed-loop cards that hide the slow and dumb limitations of a EMV front-end with a beefed up back-end. This is the Cubic + Mastercard transit solution coming to Cubic managed transit fare systems near you. Enjoy.