Sometimes it takes Apple support pages a while to acknowledge the current reality of iOS. iOS 15 Wallet brought ‘region free’ transit cards with an improved UI so that allowed Apple Pay users from anywhere to add transit cards directly in Wallet. Apple support document HT207155 “Add a Suica or PASMO card to Apple Wallet“ removed the ‘device region set to Japan’ requirement in an April 29, 2022 update, some 6 months after the iOS 15 release.
‘Region free’ transit cards are not all equally region free however: some transit cards only accept locally issued Apple Pay cards for adding money. This is the case for Hong Kong Apple Pay Octopus and all Chinese T-Union brand transit cards (too many to list). Octopus does offer a surprisingly user unfriendly iOS Octopus for Tourist app for tourists add Octopus to Wallet, that unfortunately locks in usurious currency exchange rates.
There are also some interesting tweak updates in the companion support doc: Use Suica or PASMO cards on iPhone or Apple Watch in Japan. The first is Apple going all in with the UK English ‘top up’ as the default English word for adding money to prepaid cards. Why not stick with regional differences? Does Apple want America to become a cultural extension of Great Britain or something? Recharge was used previously in the US doc version though I suspect most Americans use reload. ‘Top up’ is too quainty UK English for my tastes, sounds like drinking. I’ll stick with recharge.
The other change is an expanded Check the balance section that now includes If your Suica or PASMO card balance doesn’t update, with a link to a fairly new support doc, “If your transit card balance doesn’t update in Apple Wallet.” If there is one common complaint from Suica and PASMO users it is that the sometimes sluggish Apple Pay recharge process, usually due to a poor internet connection, occasionally results in the balance not updating. As the Apple doc states: the truth is always in the recent transactions list.
The last new tweak is a new section: Get a refund for purchases made with your Suica or PASMO. It has good advice that should have been there from Apple Pay Suica launch day, “return the item to the same terminal where you made the purchase before you use Suica or PASMO to make another purchase using Apple Pay.”
Unfortunately Apple failed to update has the Use the Suica or PASMO app section, leaving some very outdated and incorrect information. Shinkansen eTicket service in Suica App ended back in March 2020, and Green Car tickets were never available in PASMO app.
I guess they were too busy swapping American English with British English to notice the errors.
(The) Digital Markets Act will…require companies designated as gatekeepers to ensure effective interoperability with hardware and software features they use themselves in their ecosystems. This includes access to NFC for mobile payments.
Today’s case addresses a conduct by Apple that has been ongoing since Apple Pay was first rolled out in 2015 <sic, 2014 actually>. This conduct may have distorted competition on the mobile wallets market in Europe. It prevented emergence of new and innovative competition that could have challenged Apple.
Both pieces miss important context surrounding the debate however…and with this issue context is all, especially how Apple Pay is playing out in other global markets. Most of what follows I’ve covered in earlier posts but hope to pull the various issues together in one post. Yet again, we kickoff with an updated Apple Pay diagram.
The so called Apple ‘NFC chip’ is not a chip at all but a hardware/software sandwich. The Apple Pay ecosystem described in iOS Security is a collection of tightly integrated polished pieces: Secure Element, Secure Enclave, NFC Controller, Wallet and Apple Pay Servers, all wrapped into a slick, easy to use UI with a final security wall of ‘secure intent’, a double-click side button hot-wired to the Secure Element. This approach has been so successful that people divide mobile payments history into pre-Apple Pay and post-Apple Pay eras.
Apple Pay has a very simple rule: any card that loads a Java Card applet into their embedded secure element (eSE) has to reside in Wallet app. The maximum number depends on how many Java Card applets it can hold at any one time, the previous limit was 12, the iOS 15 Wallet limit is 16 cards. Developers have two ways to access iPhone NFC: 1) Core NFC framework for NFC operations that don’t use the secure element, 2) Secure Element pass certificates for NFC operations that need secure element transactions (payments, keys, ID, passes). Any developer who wants to run applets in the eSE has to apply for a PassKit NFC/Secure Element Pass Certificate. This is covered by NDA but a company called PassKit (not Apple) gives us an idea what Apple’s Secure Element Pass guidelines are:
Apple care a great deal about the user experience. Before granting NFC certificate access they will ensure that you have the necessary hardware, software and capabilities to develop or deploy an ecosystem that is going to deliver an experience consistent with their guidelines.
The end to end user experience, the whole reason behind the success of Apple Pay. But this gatekeeping is what riles banks and financial service providers who want to load their applets into the secure element without the Apple Pay gatekeeping, without the Apple Pay ecosystem and without the Apple Pay commission. They want to do their own transactions with their own app for free. This is what the EU Commission means when Vestager says: “Evidence on our file indicates that some developers did not go ahead with their plans as they were not able to to (sic) reach iPhone users.” It should read: when they were not able to reach iPhone users for free. Either the developer didn’t apply for a Secure Element Pass, didn’t pass the certification process, balked at Apple’s certification conditions, or couldn’t agree on Apple Pay commission rates.
Secure element gatekeeping is not new, it is an essential part of the secure element system:
A Secure Element (SE) is a microprocessor chip which can store sensitive data and run secure apps such as payment. It acts as a vault, protecting what’s inside the SE (applications and data) from malware attacks that are typical in the host (i.e. the device operating system). Secure Elements handle all sorts of applications that are vital to our modern digital lives…
Mobile Payments Here, the Secure Element securely stores card/cardholder data and manages the reading of encrypted data. During a payment transaction it acts like a contactless payment card using industry standard technology to help authorize a transaction. The Secure Element could either be embedded in the phone or embedded in your SIM card.
Lifecycle management It’s crucial that SE-embedded devices are secure throughout their lifecycle. That’s why Secure Elements need to have an end-to-end security strategy. It’s no use developing a robust security solution for a device which becomes obsolete after a period of use. This is why Secured Elements can be updated continuously to counter new threats.
Few people, especially a PayPal or EU Commission vice president, discuss the crucial secure element lifecycle management aspect. It’s not convenient for them to say the secure element ‘gatekeeper’ is responsible for keeping it secure. Far more convenient for their arguments to omit this, portray gatekeeping as unnecessary and gatekeepers as evil. In the end however, Apple has to maintain secure element updates from the various licensed secure element providers (EMV,FeliCa Networks, MIFARE, and so on) if secure payments are going to work at all This is what people who say, ‘it’s my device, we should be able to use NFC how we want,’ do not understand.
People also forget that nothing is free, you get what you pay for. With Apple Pay as gatekeeper, users get simplicity, innovation and feature updates. Simplicity: users get NFC they can use out of the box without Android-like NFC complexity such as secure element positions and obscure express mode settings.
Innovation: Apple Pay has features like Global NFC. iPhone and Apple Watch are the only smart devices that come with FeliCa built in as standard to use in Hong Kong or Japan, while Android limits functionality by market region. It’s astounding that Android, not even Google Pixel Android, has matched this basic functionality yet. We’re seeing more innovation as Ultra Wide Band (UWB) extends Wallet functionality to include ‘Touchless’ car keys and eventually, UWB enhanced automatic card selection as you approach the reader; more helpful than you might think.
Japan is key to understanding what’s really going on in the Apple Pay monopoly debate. Japan was the first market with an established mobile payment platform in place, long before mobile EMV contactless payments took off in Europe. iPhone also has a much larger marketshare in Japan than it does in Europe. It’s a shame people pass up the opportunity to learn from the successes and failures here.
So what’s the EU Committee vision for ‘open NFC’? I think it’s a rehash of the secure element wars when carriers locked mobile payment services to SIM contracts. In 2013 Google incorporated SimplyTapp HCE (Host Card Emulation ‘secure element in the cloud’) technology as a NFC ‘workaround’ to ‘free’ NFC from the evil clutches of mobile carriers. Sound familiar? Android NFC has never been right since.
How little things change, swap ‘evil mobile carriers’ for ‘evil Apple’ and you have the same self serving ‘open’ vs ‘closed’ NFC chip nonsense that people are debating today. FeliCa Dude, the ultimate industry insider who has experienced it all, said it best: ‘It’s all eSE or nothing now.’
And yet we now have Île-de-France Mobilités (IDFM) turning back the clock, circumventing the eSE on NFC equipped Android devices and going all in with HCE for IDFM’s Smart Navigo service for Android. To me this says all you need to know what European priorities are regarding the ‘open NFC’ model: eliminate eSE gatekeepers by forcing the less secure network dependent HCE as a required option. Good luck with that. From a transit perspective, based on Mobile Suica user experiences, I don’t think HCE Smart Navigo will be a smooth ride.
The EU Committee ‘open NFC’ vision might look ideal…to Apple Pay competitors. Regular users however, will have to deal with the ugly reality of multiple NFC apps, multiple NFC secure element modes and clashing updates that cancel out NFC services. Apple Silicon eSE space is limited to 16 cards. If that sounds like a lot now, wait until you have credit cards, transit cards, home, car and office keys and ID installed along with ‘open’ NFC apps wanting their own eSE space too. Services will be squeezed out forcing the user to intervene. If the EU Committee thinks this environment fosters competition and innovation while growing mobile payment use, dream on.
Japanese tech journalist Junya Suzuki has covered NFC mobile payment developments in Europe, America and Japan for over 2 decades. He doesn’t think the EU is playing an even hand here, in his opinion Samsung and Huawei would never face the scrutiny that Apple now faces. In typical European cultural fashion, EU motives pay lip service to fair open markets while playing an underhanded game of chess to make Apple do what EU banking interests want Apple to do. In other words, a double standard.
What does Apple need to do? I’ve always said that Apple needs to make the Secure Element Pass application process as transparent as possible. Keeping the blackbox NDA process as it is now makes Apple Pay a target, increasingly difficult to defend the status quo. Secure Element access on the level of Core NFC is a long shot, the very definition of a secure element means there has to be a developer certification process similar to EMVCo, FeliCa Networks, MIFARE, Calypso Networks Association, etc., that protects the privacy and business interests of all parties. But it would be great if there is a middle way where Apple can securely open things up for iPhone as a digital wallet, and iPhone as a payment terminal. We’ll see if Apple has anything to say about the subject at WWDC22.
Here’s the thing, most people assume that killing PASPY card means Hiroden and Hiroshima region PASPY transit partners will rip out all the FeliCa readers and replace them with optical code readers. I don’t think so. FeliCa PASPY cards will disappear but not the transit IC readers. If you listen carefully to Hiroden’s bitching and moaning about having to shoulder PASPY system costs from the PASPY/FeliCa fare processing server side (that the PASPY partners don’t help us enough with…boo-hoo-hoo). Dump that and get out of the plastic card issue business, leave ICOCA / Transit IC readers where they are and let them handle their own fare processing, retrofit a QR scanner or install Denso Wave QR+NFC readers, toss out a QR PASPY app and the PASPY associates can call it a day.
PASPY had all the limitations of region transit cards: no e-money functions for store purchases to juice the recharge business side, slowly declining ridership, and the card could not be used on JR West ICOCA and larger Transit IC network…limitations that the Suica 2 in 1 Region Affiliate program resolves. Too bad JR West doesn’t have a similar program for the ICOCA region but it says something about JR West and local government relations that Hiroshima City and prefecture officials have kept quiet.
Nevertheless, there are way too many ICOCA and Mobile Suica users out there and Mobile ICOCA goes live 12 months from now. PASPY partners will want to keep those users riding no matter what Hiroden ends up doing. And local government transit subsidies will help keep the Transit IC readers in place. The whole point of transit is encouraging people to use it…right? And if it all works out, for QR based PASPY MaaS with Transit IC support, all the better.
I ran across an untidy but interesting Twitter thread that mentioned Apple Pay Suica in the larger context of evolving NFC smartphone services.
Suica (Metro card / digital money in Japan) now lets you transfer the card to Apple Pay. Some thoughts about the future of FOBs, cards, and wallets…You use NFC to transfer your Suica by tapping the card with your iPhone, the same way you’d tap to use Apple Pay.
Devices support some kinds of NFC but not others. Until now, you couldn’t tap to use credit cards — it was blocked by the device.
But this is changing! Apple will support card payments now, in an app that IT will make & provide to vendors. This lets Apple compete in new hardware markets: first phones, now point-of-sale, payments, inventory mgmt, etc.
Physical cards are on the way out. But not everyone is on-board. FOBs, subway cards, ID cards, drivers licenses, and building security cards have been slow adopters of mobile. I’d love to copy my building FOB to my phone 😁 There’s nothing stopping me other than that I can’t.
Apple is moving into those markets….Airports, Driver licenses (in 30 / 50 US states). How far this tech goes & the speed of adoption depends on iOS, Android, and the people at ID / security / FOB / card companies adopting the change. They may need help! And there may be startup potential in that space… if anybody is interested!
The intention was discussing the implications of Apple’s recent Tap to Pay on iPhone announcement, but it stumbled over a rarely discussed but vital point about the extremely slow migration of various physical card services to mobile devices. Why can’t we just load these in Wallet…all the technology is in place right?
The mobile chokepoint is not technology but the backend systems to seamlessly deliver, verify and securely manage individual ‘card’ services (payment cards, transit cards, ID cards, keys, etc.) in digital wallets. Those systems are not up to the job. You can be sure that Apple wants to get iOS 15 ID in Wallet driver licenses out quickly as possible but corralling all those state run systems into a coherent user friendly whole that holds up to the high expectations and massive base of iPhone users eagerly waiting to use it, is a very big challenge. It’s a similar challenge behind every kind of digital wallet service.
This backend weakness is easy to see with transit cards, there are relatively few on mobile with most of the cards exclusive or limited to certain digital wallets like Apple Pay and Samsung Pay. There are special challenges too as a mobile transit card service hosts all the functions of ye olde station kiosk card machine (card issue, adding money, pass renewal, etc.) and more, on the cloud, pushing it out to apps and connecting to digital wallet platforms like Apple Pay.
Despite the challenges, the rewards for going mobile are clear. If there is one lesson Apple Pay proved in Japan with Suica it is that building a mobile foundation early on is key to future success. Mobile laggards like Hong Kong Octopus have paid a heavy price. Unfortunately for regions where transit is operated as a public service instead of a sustainable business, spending money building transit card mobile service systems is often considered an extravagance.
Banks have had an easier path to mobile thanks to the strength of EMV payment networks, but only on the payment transaction end. Mobile card issue is another matter up to individual banks. Look at the Apple Pay participating bank list for the United States. The long list didn’t happen overnight. It has taken years for mobile backend systems to be put in place to make this happen.
It’s all about the backend A sadly overlooked aspect of the Japanese market is the crazy collection of contactless payment options: Suica, iD, QUICPay, WAON, nanaco, Edy, PayPay, LinePay, dBarai, VISA-mastercard-AMEX Touch payments and more. The reason for this is Japan’s early lead in creating the first mobile payment platform, Osaifu Keitai, in 2004.
Not everybody used Osaifu Keitai early on, but it grew the mobile payments foundation so the market was ready for new mobile payment platforms when Apple Pay launched in 2016. More importantly, the early lead also meant that bank card issuers, payment networks and transit companies had backend systems firmly in place servicing a large installed base of various digital wallet capable handsets (Symbian) and smartphones (Android) that quickly extended to Apple Pay and Google Pay.
The backend flexibility is easy to see on the Mobile Suica page that shows all the different Mobile Suica flavors: Android (Osaifu Keitai), Apple Pay, Google Pay, Rakuten Pay. Mobile Suica is also on Garmin Pay, Fitbit Pay and is coming to Wear OS.
Success or failure for any mobile wallet card service depends on reliability, simplicity and the speed for adding cards and using them. From VISA:
When it comes to digital onboarding, the average amount of time after which customers abandon their application is 14 minutes and 20 seconds. Any longer than this, and 55 percent of customers leave the process.
There is also context. Futzing for 14 minutes might apply for people setting up a bank app, but a transit app user trying to get through a ticket gate at rush hour is a completely different matter. Judging from the large number of negative Suica App user reviews and complaints on twitter, Japanese transit users probably give it 2 minutes before giving up and calling it all crap. Speed is the key.
How long does it take? The speed of adding a card to Wallet depends on a number of factors, what kind of wallet service are we dealing with (car key, hotel key, home key, office key, payment, transit, ID), does the user need an account first, can a physical card be transferred, what kind of user verification is required.
User verification with digital credentials is still in its infancy which is why driver’s licenses and state IDs in Apple Wallet is fascinating and important. How does one authenticate their own ID card? Apple explains the process but doesn’t say how long verification takes or reveal backend details:
Similar to how customers add new credit cards and transit passes to Wallet today, they can simply tap the + button at the top of the screen in Wallet on their iPhone to begin adding their license or ID… The customer will then be asked to use their iPhone to scan their physical driver’s license or state ID card and take a selfie, which will be securely provided to the issuing state for verification. As an additional security step, users will also be prompted to complete a series of facial and head movements during the setup process. Once verified by the issuing state, the customer’s ID or driver’s license will be added to Wallet.
The verification process is similar to the recent addition of Mobile Suica student commuter pass purchases where students take a picture of their student ID and upload it. Online verification takes ‘up to 2 business days’ because Mobile Suica has to manually verify the ID information with the school. Hopefully the Face ID setup-like ‘additional security step’ is the magic iPhone ingredient for instant verification by the state issuer. However notice that Apple doesn’t spell out where the face and head movements are stored. Hopefully it will stay in the Secure Enclave and never be stored on a server. We shall see when ID in Wallet launches with the iOS 15.4 update.
As you can see from the table below, the journey from backend system to Wallet varies widely by the type of service. The easier additions are the ones done in Wallet app: card scans for payment cards and ID or simply tapping to add transit cards.
Physical card scans are the primary way to add payment cards but this is changing, apps will replace plastic card scans over time. In Japan there are a growing number of ‘instant issue’ credit/debit digital cards from top tier banks that can only be added to Wallet with an app and account. Digital onboarding is the direction banks are going, where everybody has to go to an app first to add a card to Wallet. This leaves transit cards as the only card that can be added without an app or account.
Who owns the thing in Wallet? Physical keys, fobs and plastic cards may seem inconvenient at times but they are personal property we carry on our person. One downside of digital wallets is that convenience carries a risk that the thing in Wallet isn’t necessarily ours. What is added with a simple tap can also be taken away by a technical glitch, or in a worst case scenario, without our consent. As backend systems improve and integrate, more services will migrate to our digital wallets. Without doubt much of this will be convenient but read the fine print and always keep your eyes open to the tradeoffs and risks. In other words don’t let your digital wallet be a potential chokepoint of your life.
Suica 2 in 1 Region Affiliate Transit Cards have a problem: it would be great to have these cards available on mobile wallet platforms (Osaifu Keitai, Apple Pay, etc.) however, the whole point of region cards is to promote region affiliate transit companies and service benefits for the people who live there. There are region affiliate transit points and services for everybody, discounts and point rebates for elderly and disabled users, commute plans and so on, subsidized by prefectural and local city governments.
Hence despite the Suica logo on them, region affiliate cards are not available from JR East. They are only available from region affiliate bus offices. But it’s a pain getting them, commute plan renewal requires another trip to the bus office and cash recharge is the only option. Suica 2 in 1 would be infinitely more useful and user friendly on mobile. Region affiliate users are certainly happy to have a card that covers all of their transit needs but it doesn’t bring them into the Mobile Suica era.
But mobile is a two edged sword. On one hand you want the convenience of Mobile Suica, on the other hand region cards need to promote subsidized services for a particular location, keeping them local on a wide mobile platform and restricting access for special services with certain eligibility requirements (local disabled and elderly residents) is a challenge. How does one promote targeted regional services on widely available mobile platforms like Mobile Suica on Apple Pay?
The Suica App mobile fix Hmmm, this sounds like a similar problem with student commuter passes. JR East and customers want to do away with the drudgery of going to the local JR East station ticket window to confirm student ID validity, nevertheless, student ID validity must be confirmed before a student commuter pass can be purchased. Mobile Suica has supported student commuter passes but students have to go to a local JR East office to validate and activate it.
Mobile Suica will address this problem on February 13 with a system update and new version of Suica App (v3.1.0) that adds support for in-app purchasing and renewing student commute plans. Another Mobile Suica update on March 12 will add Tokyo region day pass purchase support. Think of these as selective local services on a widely available mobile platform. Let’s see how this approach can be applied to Suica 2 in 1 Region Affiliate cards.
1) Region affiliate mobile issue When I made my Apple Wallet transit card wish list mockup, I thought it might be nice to have all the new Suica 2 in 1 cards available directly in Wallet app along with Mobile ICOCA (coming in 2023).
Apple Pay WAON deals with this problem in a smart way: regular WAON can be added directly in Wallet app, regional WAON cards are added to Wallet with WAON app. The beauty of issuing specialty WAON cards in the app is they have region specific goodies attached: a portion of the region WAON card transaction goes to a local government development fund.
This approach is a perfect fit for region affiliate Suica cards on mobile with local perks, bonus local transit points and so on when issuing cards on mobile.
2) Suica2 in 1 commuter pass purchases and limited eligibility card issue There are a few more hurdles to clear before Suica 2 in 1 can join the mobile era: region affiliate commute plan purchase and renewal, limited eligibility card issue (for elder and disabled users).
Let’s say you are a totra commuter who rides a region affiliate bus and a JR East train. In this case you need 2 separate commute plans on your Suica 2 in 1 totra card, one for the region affiliate bus, one for JR East. The commuters plans must be purchased separately: the region affliliate commuter pass is bought at the bus office, the JR East section is then purchased added at a JR East station ticket office. It’s a complex hassle. JR East stations are all cashless but only a few region affiliate bus offices take credit cards…and so it goes. How nice it would be to do this with an app and pay with Apple Pay.
Mobile Suica already hosts this kind of complex commute plan configuration but not in Suica App. Mobile PASMO and PASMO App are hosted on the JR East system, basically rebranded Mobile Suica, and easily configure complex bus + train commute plans from multiple transit operators for mobile purchase.
This leaves limited eligibility card issue. The February 13 Mobile Suica update adds student commuter pass pre-registration and ID verification uploading via the Mobile Suica member website. The student reservers a pass entering school information, commute route and uploads a picture of their school ID. Approved student commuter pass reservations are then purchased in Suica App. This ID verification method can be used for issuing elder and disabled Suica 2 in 1 cards. It’s still a manual authentication process that digital My Number cards will, hopefully, transform into a simple automatic one with instant verification of necessary personal information.
One of the really interesting things about Suica 2 in 1 is that the next generation format is the very first Suica card that supports disability fares. Up until now disability fare users have been limited to paper passes inspected at manned transit gates.
JR East plans to drastically reduce the number of manned transit gate areas. Before this happens, mobile support for all Suica cards of every kind, especially the new Suica 2 in 1 features, must be in place. The pieces of the solution are there, it only a matter of JR East integrating them into a Mobile Suica system and Suica App update.
One Suica App to rule them all If we are promoting region affiliate Suica cards does it make sense to do it all in Suica App or have individually branded local apps for totra, nolbé, cherica, et al? One main goal of Suica 2 in 1 is cost reduction and infrastructure sharing. Despite all the different names and card artwork these are Suica cards with all the Suica benefits and JR East managing the Suica infrastructure for region affiliates.
I’d argue it doesn’t make sense nor does it fit with cost reduction goals to do a bunch of re-skinned local Suica Apps when JR East is making a bunch of replicas. Better to focus efforts on making Suica App a streamlined easy to use app with all the necessary tools for managing mobile region affiliate cards. And because physical cards remain an important part of the Suica platform strategy, Suica App must also add a physical card iPhone recharge feature similar to what Octopus App and Navigo App offer.
All in all I expect that 2023, which will see the launch of the highly anticipated JR West Mobile ICOCA service, will be a big year for Mobile Suica and Suica App too.