The details are interesting. On the MIFARE side, Ultralight, Plus and DESFire are supported, the security weak Classic is not. FeliCa is there of course, but the weird thing is that all devices from iPhone 7 and above are supported. You might remember that from the Apple Pay point of view iPhone 7 is not a global FeliCa iPhone, but it is from a iOS 13 Core NFC point of view. I guess FeliCa support on all iPhone 7 models was really there all along, Apple just didn’t tell us…until now.
The Apple Card rollout due this summer is a head scratcher. There was nothing new for PassKit or Wallet at WWDC19, but there are lots of things Apple Card can do in Wallet that other cards, as yet, cannot do. It feels too big and important for just a press release and a new web page. And yet, by itself, it’s too small for a full blown Apple event. I think the Apple Card rollout is going to be a very interesting release for all things Apple Pay.
Now that full 3rd party NFC access is reportedly coming with iOS 13 tag support for ISO 7816, FeliCa and MIFARE, does this mean developers get supercharged Core NFC and PassKit NFC Certificates generously handed out like condoms at a gay sex party? Probably not, the only new things in those rumors are ‘full access’ and ‘ISO 7816’, but let’s take a look at some possibilities based on the 3 NFC Forum defined NFC Modes: Card Emulation, Reader/Writer and Peer to Peer.
It’s useful to remember that A12 Bionic powered iPhone is one of the most compelling ‘Global NFC’ devices on the market, with all the important technologies in one package sold everywhere: NFC A-B-F hardware and EMV, FeliCa, MIFARE, PBOC and VAS (value added service protocol) software. Android is fragmented, especially when it comes to FeliCa support.
The big frustration for developers has been that iPhone NFC is all dressed up with no place to go. iOS 12 NFC supports Card Emulation and Reader/Writer but severely limits the Secure Element access necessary for Card Emulation with NDA covered PassKit NFC Certificates, while Core NFC is a limited Reader/Writer Mode sub-set.
The Apple Card UI and Wallet UI design language in iOS 12.2 and later, is so different from the rest of iOS 12 that I’m surprised nobody in the Apple tech blog space picked up on it. There are lots of useful card options and information that can be piped into Wallet cards from the card provider cloud, instead of sitting in a separate app.
This applies to card artwork as well. Static card artwork in iOS 12 doesn’t do anything and gobbles up precious screen space. The dynamic card art of Apple Card UI can be used to give important information to users while solving the wasted space problem.
Multiple Express Cards in iOS 13 Wallet There are major Japanese eMoney prepaid cards on Android that are missing on Apple Pay: WAON, Rakuten Edy and nananco. One ‘missing on Apple Pay’ reason is that iOS 12 Apple Pay Wallet lacks a smart way to deal with multiple Express Transit and Express eMoney Cards. Wallet can hold multiple Suica cards but only one of them can be Express Transit. It’s the same for eMoney cards.
iOS 13 Wallet will complete the journey, hopefully delivering a vastly improved and unified Wallet UI that elegantly solves the multiple Express Transit/Express Card issue, and eliminates card clash. At a transit gate the user should only have to tap, at checkout the user should only have to select a payment logo on a screen or tell the sales clerk Suica, Mastercard, etc., and pay.
Easy Card Emulation I am less sure how Apple plans to make card emulation easier for developers:
New functions in PassKit that do more
Less stringent and easier to obtain PassKit NFC Certificates
A combination of the two or
Something new altogether
Whatever the approach, I hope it keeps everything secure while making it easy for developers to add all kinds of non-EMV cards to Wallet, the major categories include…
Transit Cards: Transit cards have been tricky because up to now each one has been a kind of custom in-house job by Apple in cooperation with the transit company. HOP launched May 21 and Ventra will arrive this summer.Clipper has been rumored for Apple Pay inclusion for some time. Hong Kong Octopus (FeliCa) and Los Angeles area TAP (EMV only?) should arrive shortly after the iOS 13 launch in September. It would be great if iOS 13 PassKit makes it easy to add all kinds of native transit cards like Taiwan EasyCARD and Melbourne Myki (both MIFARE) and more (like Calypso for example) to the mix, with Apple having to do less for a real transit card coming out party. Unfortunately I don’t see Singapore’s EZ-Link card ever joining the party unless iOS 13 PassKit makes it very easy to support customized payment technology like the Singapore only CEPAS.
Regular Reward Cards: There are tons of these everywhere, mostly mag strip. My real wallet has JRE POINT, WAON POINT, Tomod’s, plus a crazy collection of stamp/point cards. How nice it would be if it was super easy for developers to port these to Wallet with NFC capability.
ID Cards: This is where ISO 7816 tag support fits in. Contactless Student ID cards in iOS 12 were a MIFARE only custom in-house job, transit cards without transit, by Apple in cooperation with Blackboard. Hopefully Apple will greatly extend ID card support in all NFC flavors for many companies and institutions, for all manner of ‘company only’ Wallet ID cards.
VAS: Apple Value Added Service protocol has been around a few years but uptake has been slow, almost as slow as VAS works on NFC readers and POS systems. This is more of an performance issue on the POS side than PassKit, nevertheless anything Apple can do to help increase VAS performance would be welcome. So would VAS working with Express Transit.
Android has a huge advantage over iOS because Android apps have the NFC access to do what they want. From RFID Insider:
Below are all the abilities/formats available for writing to a tag:
Business Card Link/URL Wi-Fi Bluetooth Email Telephone Number Geo Location Launch an Application Plain Text SMS
A fully functional Core NFC could do all this, but the important question is how would Apple want to do all this. NFC tags are great technology but they remain deeply geeky for the majority of users. The key is making NFC tags as friendly, easy and secure to use as Apple Pay. This is exactly what Apple plans to do.
The easiest way to think of it is that instead of tapping a dedicated NFC reader to pay with Apple Pay, NFC tag Apple Pay turns your iPhone into the reader. An NFC tag and iPhone is all that you need to Apple Pay at a store.
What does this sound like to you? Yep, this is enhanced Core NFC Read/Write for NFC tags that does exactly what QR Codes do. NFC tag Apple Pay is aimed right at the ‘but the store doesn’t need an expensive NFC reader to use QR’ sweet spot that QR Codes have occupied up to now. NFC tag Apple Pay levels the play field, neatly eliminating the QR advantage while offering security that QR Codes cannot match.
However don’t assume that the QR players are chained to QR Codes, it’s an inexpensive and convenient technology for building payment system app services, nothing more, not particularly sacred. Enhanced Core NFC and NFC tag Apple Pay works in an app and this offers Japanese QR Code payment systems such as Line, PayPay, etc., a way to incorporate Apple Pay NFC support in their app, if they choose to do so.
A12 Bionic iPhone XR/XS are the only devices that support background NCF tag reading and the native ability to read tags without an app. The big question in my mind is how Apple plans to implement enhanced Core NFC and NFC tag Apple Pay on older devices
Peer to Peer
iOS 12 does not support NFC Peer to Peer. I don’t see that changing in iOS 13 if it can’t be part of a new Apple Pay or related service. AirDrop already works well across devices that do not have NFC capability. That’s probably enough real world peer to peer for most people.
The Apple Pay theme for WWDC18 was ‘move Passes into Wallet, get rid of the QR Codes and replace them NFC.’ The new Apple Card UI improvements in Wallet and NFC tag support suggest the Apple Pay theme for WWDC19 will be: ‘move card functionality out of apps and into Wallet cards with new iOS 13 PASSKit controls, or get rid of apps altogether and replace them will all kinds of NFC enabled cards and NFC tags.’
It certainly makes sense. Apple Pay is NFC for the majority of iPhone users, the NFC thing that people use. Apple devoting iOS resources into making card emulation easier and better for 3rd party developers to add all kinds of cards to Wallet, and migrate functions out of separate apps to the Wallet card itself, will give the most bang for the development buck. NFC tag Apple Pay will finally bring NFC tags into the mainstream while eliminating the remaining advantages of QR Codes. It’s going to be a very interesting WWDC for all things Apple Pay.
Year over year contactless payments use in the first slide basically covers the same period of the MMD Labo report but with different questions. The Rakuten data shows Rakuten Pay in the lead, naturally, at 15.2% and Apple Pay in 2nd place at 12.9%. The MMD numbers showed Rakuten Pay at 13% and Apple Pay at 20%. Google Pay only added Japanese payment support in May 2018 so the full impact will take time to play out, the 30% Osaifu Keitai use figure from the MMD report suggests a possible outcome.
As I explained in the earlier post, Apple Pay use is highly regional and tied to Suica compatible transit routes. In major metropolitan areas Apple Pay use is higher than Rakuten but Rakuten has done a good job building an ecosystem of e-commerce, travel reservations and other services that offer members large discounts and points. That’s the reason behind the robust growth from 3.4% and the larger nationwide average use figure.
Apple Pay Suica is the entry point for Apple Pay use, the more incentives that customers have to use Suica the faster Apple Pay use in Japan will grow. Sachiko Watatani pointed out that only 27% of Apple Pay Japan capable device users actually use Apple Pay, that represents a lot of potential users sitting on the fence. The Rakuten Pay growth rate shows that points and discounts are great incentives but Apple Pay Suica, convenient as it is, doesn’t offer that. At least not without going to the trouble of getting the right Apple Pay credit cards for the right points. And even then, as setting up and using the JRE POINT app makes clear, it’s not user friendly.
The next big opportunity for Apple Pay Suica growth is ‘Super Suica’ that will unite transit cards, commuter passes and various transit point systems in a single format for plastic and mobile. Unfortunately this doesn’t happen until April 2021. Until then Apple Pay Japan needs to add the other e-money prepaid cards (WAON, nanaco, Rakuten Edy) and as many point system reward cards to Wallet as possible to keep growing. Not only that but also make them work better together than they do on their own. Think PONTA card with the kinks ironed out.
Open Loop EMV It is very strange that the TfL Oyster card, which completely transformed London area transit still isn’t hosted natively on Apple Pay or Google Pay. Other MIFARE based cards are hosted on both digital wallet platforms and TfL has an Oyster app for account management and online recharge (top-ups). From a technical standpoint there doesn’t seem to be any particular problem preventing them. Perhaps it is a political thing.
TfL decided in 2011 to put their resources into the emerging EMV contactless standard. The reason was simple:
The current Oyster system, though very popular, is expensive and complex to administer. Contactless bank cards use existing technology, responsibility for issuing cards would lie with the banks rather than TfL, and the operating costs should be lower.
That is politician think, not business think: everything is a budget problem, not a business opportunity that needs investment, reduce costs by letting someone else pick up the tab but let them take their cut first. I wonder if TfL publishes how much they pay out in transaction processing fees to banks and Cubic? Perhaps not. Meanwhile budget pressures are not letting up as Londonist notes:
In 2017 there was a push to nudge people away from their Oyster cards and towards contactless. One announcement rang out all over London’s tube stations: Why not use your contactless bank card today? Never top up again, and it’s the same fare as Oyster.
The die was cast in 2014 and probably won’t change. Instead of putting resources into hosting Oyster on Apple Pay or Google Pay, TfL and Cubic already have a mobile solution which is ‘open loop’ ticketing with EMV contactless bank cards. Open loop does not address the finer issues of different fare schedules (children, seniors, etc.), commuter passes, season tickets, nationwide transit interoperability, regional promotion, nor does it offer the business advantages of a transit payment platform, Express Cards with power reserve or any kind of future vision. That’s the end of the open loop story because EMV contactless is a very dumb smart card.
It’s a shame really because TfL loves to say they generate the most transactions in all of Europe. To me that’s a gold mine to build an empire, budget problems solved. Unfortunately TfL gives that gold mine away to banks and Cubic.
You can see the same thinking with Oyster’s Australian cousin, the Opal card system, built and managed by Cubic, just like Oyster. Opal is also going the ‘open loop’ route instead of transit cards on mobile.
Hong Kong going the QR Code route shows how badly AliPay wants in on Hong Kong transit, and MTR Corporation in on China transit, bad enough that Hong Kong will sacrifice a great transit payment platform for AliPay, another gold mine giveaway. Judging by the AliPay branding and retrofitted QR Code readers on Hangzhou Metro gates in the pictures above, what AliPay wants, AliPay gets, but the fast FeliCa based Octopus smart card stands in the way. Instead of improving Octopus or extending mobile Smart Octopus, it looks like Hong Kong will invest in very slow and very dumb QR. The Hong Kong Economic Journal had this to say about the development:
MTR has set its sights on a major revamp of its fare collection system, accepting new electronic payments methods rather than just single journey tickets and Octopus Cards. From the passengers’ perspective, it means there will be no need to have an Octopus card on hand for a journey on local trains, if MTR’s new fare collection system supports all the mainstream contactless payment methods such as Visa payWave and MasterCard PayPass, or mobile payment means like Apple Pay, Samsung Pay and Google Pay.
Japan in the middle TfL/Oyster and Transport for NSW/Opal, Octopus, EZ-Link are government held transit authorities, not private independent companies. Publicly run transit authorities are subject to politics and special interests like any government agency, this sometimes leads to poor decisions and short-term thinking.
The ubiquity and scale of interoperable transit IC cards sets Japan apart from all other countries. China copied the Japanese model for China T-Union but the cards cannot be used as e-money and have been upstaged by AliPay and WeChat Pay which, surprise, can be used for e-money and transit.
Japan occupies a very unusual middle ground between EMV contactless from the West and QR Codes from China, neither of which play well together. The scale of Suica provides the breathing space for Japan to pick and chose what works best for, and enhances their transit payment platform. The result is an incredibly rich and varied contactless payments market anchored around Suica and similar FeliCa prepaid cards.
Low-cost QR Codes certainly make sense for lightly used rural transit operations but they have a fatal weakness: they don’t have plastic card versions that work anywhere and seniors prefer the simplicity of plastic, QR Codes require a high cost network connected smart device, an app and are strictly one way read with no offline processing.
Update: Open Loop QR Code Security Risks One issue that was in the back of my mind while writing this post was the privacy and security implications of letting AliPay inside with direct transactions on transit gates. Japanese customers are very sensitive about where and how transaction records are held and used but I have yet to see any security discussion in connection with Hong Kong MTR opening up transit gates to AliPay and WeChat Pay. QR Code transactions are very different from offline FeliCa Octopus transactions. Where and how does the QR Code transaction data from Hong Kong MTR transit gates get stored, does the Chinese government has access to it to gather intelligence from transaction and location records?
If there is one thing we do know about Chinese companies is that they do what they want when nobody is looking. Witness China Telecom spoofing the BGP protocol to poison internet routes and suck up massive amounts of American and Canadian internet traffic for intelligence analysis. If I was living in Hong Kong I would be concerned about the privacy implications of MTR going open loop with QR codes.
The Apple Wallet Ponta card launch at LAWSON presents another dilemma: just what exactly is Apple using for iOS 12/watchOS 5 Apple Wallet Passes and Student ID cards? Student ID cards and Apple Wallet Ponta have the same device eligibility specs: iOS 12/watch OS 5 running on iPhone 6 and later/Apple Watch Series 1 and later.
You might assume that Apple Wallet Ponta is FeliCa but the eligible device list tells a different story. You might also assume that everything in Japan is FeliCa but this is also not the case. Doutor Coffee shops sell a handy little Doutor pre-paid card that is MIFARE and it works flawlessly side by side with FeliCa flavored Apple Pay Suica on the same NFC reader.
Altogether we have an interesting spec list for Student ID and Mobile Ponta cards.
The same eligible device specs that only support NFC A-B across all devices
I’m calling it (again): the only technology that fits this profile along with Express Cards (for Student ID cards but not Ponta) is MIFARE iOS 12 PassKIT Wallet passes are simply MIFARE. Only Apple could pull this kind of ‘under the hood thing’ off in iOS 12 without anybody suspecting and it neatly puts all the major NFC technology pieces on Apple Pay: EMV, FeliCa, MIFARE and PBOC China Transit.
Blackboards’ push to adopt NFC in addition to their existing MIFARE-based solutions, back in 2012 showed incredible insight into the potential of this technology. The security, convenience and flexibility that NXPs NFC and MIFARE solutions bring truly reflect the student lifestyle. Now access to campus services can be simply enabled via a smart watch or smart phone.
Based on this and the fact that it came 2 years after a FeliCa demo of Blackboard Student ID cards with a rumored migration from FeliCa to MIFARE, plus the eligible device specs, my conclusion is that Student ID cards on iOS 12 are MIFARE card emulation which is NFC-A.
Wallet supports the value added service (VAS) protocol for transmitting data from supported passes to compatible NFC terminals. The VAS protocol can be implemented on contactless terminals and uses NFC to communicate with supported Apple devices.
This is also NFC-A. Contactless passes have been around for a while on iOS but adoption has been slow. With iOS 12 PASSKit, Apple is encouraging developers to migrate from QR Codes to NFC contactless passes and hopefully lowering the NFC Certificate requirement bar a little. Part of the reason for the slow uptake is poor NFC reader support. LAWSON has a new POS system built around Panasonic JT-R600CR readers which are Apple Pay savvy and Apple Wallet Ponta cards only work correctly when you tell the LAWSON cashier to use “Apple Pay”.
UPDATE A highly trusted NFC engineering source contacted me that I got it partly wrong. The correction edit above explains that Wallet Ponta cards are Apple’s implementation of the VAS protocol and not MIFARE. Student ID cards are certainly MIFARE/PASSKit NFC Certificate card emulation, Apple has not publicly announced MIFARE support but it is the only technology compatible with Blackboard IC card formats that could power the express card features of iOS 12 student ID cards across all eligible devices. Research and confirmation efforts are ongoing.