As usual, I tried to get on the train using Apple Pay Suica at the ticket gate, but it didn’t respond at all and I got stuck. At first I thought it was because I was wearing a thick coat, so I held it up again, but there was no response … When I checked the Wallet app, all the credit cards and Suica were gone.
It sounds like he was using Suica on Apple Watch. Sakakura goes on to helpfully explain what can cause this and how to get your Wallet cards back. The most common cause for a lost Wallet is signing out of Apple ID. Another cause is turning off the passcode. As he points out, the notification warning when signing out of Apple ID or turning off the passcode is vague, it doesn’t specially say you are about wipe your credit cards and Suica from iPhone. Some users are not fully aware of the consequences and proceed, only to be rudely surprised when they find Wallet is empty.
In all cases it is easy to restore a lost Wallet. Sign-in to Apple ID, set a passcode, go to Wallet, tap + , tap Previous Card and re-add the listed cards. Suica is easier to re-add as there are no terms and conditions or security code steps involved. As always make sure iPhone has a robust network connection when adding Wallet cards.
Another issue to be aware of with Suica and PASMO is Express Mode deactivation without realizing it. This happens when iPhone Face ID has 5 false reads (easy to do when wearing a face mask), when Apple Watch is off the wrist, or when the iPhone side buttons are inadvertently pressed in a snug fitting pocket (often aggravated by the phone case).
One oddity I have encountered using Apple Pay Suica on Apple Watch is wrist band fit. Apple Pay Suica on Apple Watch works fine at the transit gate under layers of winter cloths but Express Transit is sometimes deactivated with a looser fitting band. I like wearing the braided sports loop but it tends to stretch over time and become loose compared with the snug fitting solo loop. On a recent trip I had to constantly enter the Apple Watch passcode as my winter coat sleeve layers pulled the loose fitting braided sport loop enough to fool wrist detection. From here on I’m sticking with cheaper, more reliable solo loop which never has this problem.
Here are some guides dealing with re-adding Suica and PASMO:
FeliCa Dude did his usual public service of posting Mobile FeliCa details for the latest Pixel 6 devices. There wasn’t any change from Pixel 5, so no global NFC Pixel for inbound visitors. Nevertheless it’s a good opportunity to review some important recent developments that have taken place behind the scenes on the Android Mobile FeliCa side and examine some possible 2022 scenarios. Things have changed even if most users don’t notice any difference.
The chart outlines Mobile FeliCa on Google Pixel developments based on information from FeliCa Dude’s tweets.
Mobile FeliCa 4.0 (Pixel 4) freed Android device manufacturers from having to use embedded secure element + NFC chips from the FeliCa Networks supply chain. Any FAST certified secure element will do. This development has resulted in a number of inexpensive Osaifu-Keitai SIM-Free smartphones released by Chinese manufacturers recently that are selling well. Hopefully it will have wider implications for inexpensive global NFC Android devices. There are lots of people in Hong Kong who would buy one to use Octopus.
Mobile FeliCa 4.1 (Pixel 5/Pixel 6) introduced multiple secure element domains. This allows the device manufacturer to ‘own’ the eSE and load or delete Java Card applets. FeliCa Dude thinks that multiple secure element domains (MSED) might play a part in the MIC digital My Number Card due to launch on Osaifu Keitai devices in 2022. My Number card uses NFC-B but MSED allows the Mobile FeliCa secure element to host it anyway, an interesting development.
Mobile FeliCa 4.2 or 5.0? The next version of Mobile FeliCa (MF) will hopefully support FeliCa SD2 next generation features that shipped in November 2020, features that power Suica 2 in 1 Region Affiliate Transit Cards (aka Super Suica) which are going wide in March 2022. These cards really need to be on mobile for future MaaS service plans outlined by JR East which cannot happen until SD2 features are added.
The improvements in MF 4.1 certainly give Android device manufacturers the ability to update MF over the air but don’t hold your breath. Standard industry practice to date has been ‘buy a new device to get new features’. Apple has been a little bit better in this regard: MIFARE support was added in iOS 12 for Student ID cards and iOS 15 fixed some Calypso bugs on iPhone XR/XS and iPhone SE.
A FeliCa Dude Reddit post comment regarding Asus smartphones illustrates the pre-MF 4.0 situation: “any phone that lists ‘NFC’ compliance must support Type F (FeliCa), but as there is no Osaifu-Keitai secure element <aka Mobile FeliCa secure element>, you will be limited to reading and potentially charging physical cards: you cannot use the phone as a card itself.” That was then, this is now.
Most people assume FeliCa support requires a Felica chip but this is not true. The evolution of hardware independent Mobile FeliCa is very clear: the ‘FeliCa chip’ from Sony/FeliCa Networks requirement is long dead and gone. Manufacturers like Xiaomi claim they make special models and add FeliCa chips just for the Japanese market, but that’s just marketing BS: they run Mobile FeliCa on the same NXP NFC chipset they sell everywhere. The majority of smartphones supporting FeliCa don’t have a FeliCa chip, everything from EMV to FeliCa and MIFARE runs on any GlobalPlatform certified secure element on any Android device.
Hopefully the sum of recent Mobile FeliCa developments, along with Garmin Suica, Fitbit Suica and built in WearOS Suica showing up in recent developer builds, indicate that FeliCa Osaifu Keitai services will become standard on Android devices as they have been on all iOS and watchOS devices since 2017.
But I don’t. In this age of shut up when we tell you to shut up big corporate and social media, I get suspicious when east coast journalists start trolling a big new ‘scoop’ at the same time. Why now and why these guys? Why do they ask the same questions? Do they hang out at the same bar and share story notes, or did somebody feed them the story and the sources? Both pieces outline some of the agreements Apple made with states and the restrictions/conditions Apple has in place to provide ID in Wallet for driver’s licenses.
When a story like this breaks from multiple outlets just before a service launch, and there is every indication Apple plans to release ID in Wallet with the iOS 15.2 update, I smell somebody’s agenda. A somebody who wants to upend Apple Pay’s ID in Wallet launch cart. This is the way to do it.
As Mikula is a former Goldman Sachs guy where he learned how to fleece things, he provides important context to the story that CNBC does not:
Multiple ID verification (“IDV”)…is big business — according to a company in the space, Mitek Systems, it was worth an estimated $7.6 billion in 2020 and will grow to nearly $16 billion by 2025. Socure, a company offering IDV services, just raised $450m at a $4.5 billion valuation — an increase in value of ~2.5x from earlier this year.
What Apple’s Secret DMV Contracts Tell Us
I wrote about iOS 15 ID in Wallet earlier this year:
There is another aspect to consider, one that Apple certainly won’t divulge: who manages and runs the backend centralized mobile ID issue service that plugs into Apple Pay servers…There has to be a partner service company that sub-contracts mobile ID issue services to participating state governments…somebody that does the heavy lifting of linking various state database servers to provide a centralized card issuing service so that Apple can provide a seamless ID add card experience. But it must be an independent entity that can provide the same set of backend ID issue services to other digital wallet platforms (Google Pay, Samsung Pay, etc.) at some point. Because if it is not an independent entity providing those services, Apple is inviting more claims that Apple Pay is a monopoly. It’s a mystery worth digging into.
Beyond defining Digital Identity Credentials that are the key part of the ‘restrictive’ agreements between the states and Apple, there are no system details. Nada. Certainly nothing like the system diagram from the Japanese Ministry of Internal Affairs and Communications (MIC) English PDF document: First Summary Toward the Realization of Electronic Certificates for Smartphones, that outlines how the digital ID system architecture for the Individual Number Card (My Number) works. A white paper from Apple explaining how ID in Wallet works both on the device and in the cloud, is key to understanding how secure ID in Wallet is, and how restrictive the agreements are. Without one, Apple puts itself, and Apple Pay ID in Wallet at risk in the political environment that is state government contractor relations. Asking users to simply trust a black box doesn’t fly in this security risk adverse, privacy conscious age.
As nothing has been released yet, and we have no white paper or anything else from Apple, I think discussion is pointless at this point. Questions are a good thing but are CNBC and Mikula asking good questions? I think the sudden ‘we’re protecting the tax payers and good citizens’ angle is highly suspect when CNBC has been a highly partisan mouthpiece always on the side of establishment government and establishment corporate America… a media company who asked nothing about big pharma’s role in the COVID hysteria driven vaccination program for example, or why Pfizer etc. are exempt for any and all side-effects of their experimental vaccinations, all while demonizing the good citizens who want those questions asked.
After all, privatization of government services is so entrenched at this point nobody really questions it anymore. Wouldn’t it be better to ask why states want to sign up for ID in Wallet, what they want to get out of it and why, why, why? Could it be that states want a successful digital ID service people will actually use? Not sexy enough I guess. If you ask me, I think some government contractor in the IDV business, and their supporters, stand to loose out in a big way if ID in Wallet is a success and used some connections to slam a media outrage ball into Apple’s court. Let the games begin.
After a long gestation, and a COVID related delay, the good old swipe MetroCard replacement has finally shipped. OMNY card: a ‘truth in the cloud’ EMV bank payment card, not a MIFARE or FeliCa ‘truth in the card ‘ smartcard like London Oyster or Tokyo Suica. As MetroCard missed the transit smartcard revolution of the early 2000’s, MTA and ticketing system management company Cubic Transportation Systems decided to go all in with a new system built on EMV and open loop, i.e. using ‘open payment‘ EMV contactless credit/debit cards for transit fare foundation instead of dedicated transit cards. It’s a ‘one size fits all’ approach where bank payments cards are promoted for every kind of purchase. The coming addition of fare capping, i.e. OMNY card features without OMNY card, further reduces the need for OMNY card commuter passes and encourages credit/debit card use.
The piecemeal OMNY rollout has not been an easy transition for MetroCard users. One problem with one size fits all open loop is that different people have different needs: minors, seniors, disabled, daily commuters with set routes, people without credit cards and so on. Even with fare capping open loop cannot handle these well, if it did TfL would have killed Oyster card long ago. Hence OMNY card is a closed loop OMNY branded EMV card with CVV security number, likely from a Mastercard issuing agency, similar to the Mastercard closed loop Ventra and Opal digital cards. Like Ventra card, OMNY card comes in plastic and the digital version will come to Apple Pay and Google Pay ‘soon’, although MTA has not given any launch window for OMNY iOS and Android apps that will be necessary for adding OMNY to Wallet and for recharge.
As most of the open loop systems in North America, UK and Australia are designed and managed by Cubic it’s helpful to compare their ticketing system profiles.
When you carefully analyze the different systems and Express Mode transit support listed on the Where you can ride transit using Apple Pay support page, one condition becomes clear: current transit systems do not support Apple Pay Transit cards and EMV Express Transit when the system uses both MIFARE and EMV open loop. It’s a choice between supporting one or the other, not both. I suspect Apple does this because of the complexity supporting MIFARE and EMV mixed mode operations on the same transit system.
OMNY is a new system however, built completely on EMV and EMV only. When Apple Pay OMNY launches, OMNY will be the first system to support both EMV as an Apple Pay transit card and EMV Express Transit mode for credit/debit cards. There is a catch however similar to using Apple Pay China T-Union cards: turning on one card for Express Transit turns off other cards. This happens when cards share the same NFC ID number which would result in card clash at the gate reader. When cards share the same ID, only one card can be set for Express Transit mode at any one time. For EMV cards this applies to payment cards as well so Express Transit Card settings will likely turn off any activated payment cards when an OMNY card to turned on, and vice versa.
After OMNY card is launched on Apple Pay and Google Pay, the next OMNY challenge will be integrating Metro-North and LIRR commuter rail ticketing. A difficult task as none of the train line are equipped with NFC card readers. MTA has yet to unveil any commuter rail ticketing integration details. Ventra has the same problem, commuter rail ticketing remains the age old conductor visual inspection, no tap and go contactless for you. And as ever there are thorny open loop user data privacy issues.
OMNY truly represents the state American public transit as it tries to get on board with mobile payments. Progress is good and welcome but a real next generation vision with meaningful forward development of American public transit will continue to be a confused mess despite endless broken promises to fix it…simply because people with money and means don’t use it. If they did, things would have been fixed long ago.
First announced as ‘coming later this year’ in August, Apple Pay WAON and Apple Pay nanaco launched today October 21 JST. The popular prepaid e-Money cards are two of the last big three holdouts that have been on Osaifu Keitai mobile phones for some time: 2005 for Edy (now Rakuten Edy), 2007 for WAON, 2011 for nanaco. Google Pay support for all three was added in 2018.
Basic features Apple Pay WAON and nanaco require iPhone 8 or later running iOS 15, Apple Watch 3 or later running watchOS 8 and Apple ID set up for two-factor authentication. The cards are similar to rechargeable Suica and PASMO however there is one important difference: they do not support Express Mode and require Face • Touch ID when making payments. This is because the maximum stored value limits for WAON and nanaco cards is ¥50,000, much higher than the ¥20,000 limit for Suica and PASMO.
Earlier this year I predicted these cards would be added with apps, not directly in Wallet but was only half right. AEON and nanaco released apps today for adding and transferring WAON and nanaco to iOS 15 Wallet that require account registration. However: WAON supports direct Wallet adding without an app, both WAON and nanaco support plastic card transfers directly in Wallet. This direct Wallet support is why the Wallet add card screen has a new e-Money category.
This is big and also an Apple Pay exclusive as plastic transfers are not supported on Osaifu Keitai • Google Pay. Once a physical card has been transferred it cannot be used, just like Suica and PASMO. Mobile card migration from Android devices is also possible via the apps. Card creation is ‘free’ compared to the ¥300 deposit for plastic cards bought at stores but plastic card transfers to Wallet do not refund the deposit, unlike Suica and PASMO that refund the plastic card deposit automatically to the balance.
Remote WAON recharge with Apple Watch Family Sharing Even so, plastic card transfer is a very important point for younger users (Apple Pay in Japan can be used ages 13 and above) to load cards into iPhone and recharge with cash instead of credit cards. There is a unique feature of Apple Pay WAON when used with Apple Watch Family Sharing: remote recharge. This was demonstrated at the Apple Pay WAON launch media event and appears to be very similar to Apple Pay Family Sharing via Apple Cash using Messages. This is a first and unique to Apple Pay WAON. I’ve pointed out that Suica would greatly benefit from just such a feature.
Users outside of Japan report they can add WAON directly in iOS 15 Wallet with foreign issue credit/debit cards. Overall I’d say WAON delivers a full set of user friendly forward looking features (direct Wallet add, remote recharge) on Apple Pay while nanaco is conservative, lacks focus and vision.
What took so long? One reason it has taken so long for WAON and nanaco to join Apple Pay despite the ability to do so since the introduction of FeliCa capable iPhone 7 in 2016, is the account creation process for digital wallet cards. Mobile WAON and Mobile nanaco on Android require a cumbersome registration process when adding these cards in Google Pay Wallet. This is something Apple didn’t want to do. Apple certainly had to do a lot of negotiating with AEON and Seven & i Holdings to get them on board with the plan but the benefits are obvious: user privacy when adding WAON, and the huge number of plastic WAON and nanaco cards out there. Those cards finally have a migration path to mobile and it is iPhone.
But why now? The Japanese mobile payments market has been on a migratory path since the release of Apple Pay in 2016 which pulled all the various FeliCa payment threads into one slick and convenient service. This development, plus the VISA JP/SMBC feud with NTT Docomo, created an opening for code payment platforms wannabes with every tom, dick, yoko and harry creating their own ‘〇〇 Pay’ service and app.
Seven & i Holdings crashed and burned with their 7Pay disaster, meanwhile AEON launched AEON Pay code payments in August with the iAEON app that follows the Toyota Wallet model. That model is what every Japanese payment player is aiming for: a virtual financial service account with multiple payment options: NFC payment cards, code payments, reward points and so on, that lock users to their economic zone of choice (Rakuten Point, NTT docomo dPoint, SoftBank PayPay, WAON Point, etc.)
So the old reliable plastic e-Money cards are being repositioned as one payment option of many in sleek modern digital swiss army payment apps. To make this strategy work, the cards needed to be on Apple Pay. Unfortunately the very long delay getting WAON and nanaco on Apple Pay means they are less important now than if they had launched back in 2016 along with Suica. People always lay any delay blame on Apple and transaction fees, but my take is the account sign-up for mobile part and user privacy was the major sticking point. On the nanaco side, the 7pay code payment fiasco was also a major distraction as they planned to ditch the JCB managed nanaco card for their in-house QR.
As always it will be interesting to see how the situation evolves. One thing for sure, it’s only a question of time before the last holdout Rakuten Edy comes to Apple Pay…’if’ is no longer an option.