The first problem was the iPhone lineup. iPhone 8 didn’t fit because only A12 Bionic and later support NFC background tag reading. This was solved with the release iPhone SE with A13 Bionic and the deletion of iPhone 8 from the lineup.
The second problem was the clunky ‘launch an app’ or ‘launch Safari’ problem. This has been a problem for NFC tag solution providers like SmartPlate. User interaction needs to reside on the pop-up sheet on the unlocked screen. The new iOS 14 App Clips framework that works hand in hand with iOS 14 Core NFC to load just what is needed to take care of the NFC tag transaction at hand, is the right solution.
The pieces appear to fit very nicely now: the NFC background tag sheet pops-up ‘while the screen is on’, the right code snippets load in the sheet, the user can Sign In with Apple ID if needed, and pay with Apple Pay. Simple, uncluttered action; no apps, no Safari launch. And we have background NFC tag reading on every current iPhone model.
There are a few flies in the ointment:
(1) Face ID in the face mask era is not a great unlock or Apple Pay user experience, App Clip powered NFC background tag reading is gonna rock on iPhone SE with Touch ID.
(2) a network connection is required, Apple Pay transactions at the NFC reader works without a network connection but App Clips + Apple Pay transactions need a network connection for the obvious reasons of loading app clip content, and because of this…
(3) a weak borderline WiFi connection can jam the above process even with WiFi Assist turned on.
The NFC advantage over QR Codes here is that background tag reading automatically pulls up the App Clip sheet ‘while the screen is on’ while QR Code users have to manually pull up the QR reader app to join the fun.
The combination of App Clips, NFC tags and Apple Pay will be extremely disruptive in markets where NFC and QR payment players are very competitive. Places like Japan. PayPay and Line Pay will lose their edge. If they are smart, they can add NFC tag support in their payment apps. And they can bypass Apple Pay if they want to, though it won’t be as slick. Ultimately they are not wedded to QR codes and have always said they would add NFC if customers want it.
App Clips finally unlocks the power of background NFC tag reading and is the other big Apple Pay development, in addition to CarKey, announced at WWDC20. App Clips puts NFC tags on equal footing with QR Codes for the first time with the added edge of the ‘when the screen is on’ background tag read sheet pop-ups. This will be huge.
As COVID restrictions are eased and the world slowly goes back to work, school and hopefully slightly more normal life, avoiding crowds will be key in keeping COVID from becoming resurgent in the months ahead.
For commuters in Japanese metro areas avoiding crowds is no easy matter. Fortunately the Japanese transit gate infrastructure is a great help. FeliCa based IC transit cards (Suica, PASMO, ICOCA, etc.) with fast transaction speeds combined with open gate flap design maximizes people flow: people walk through gates at normal pace. This is very important for Japanese stations that have to make do with large crowds in limited spaces and smaller gate areas.
It’s wrong however, to think that this only applies to Japan. The benefits of fast tap speed combined with intelligent transit gate design are relevant everywhere and very necessary in this day and age: fast gate tap speed is essential in keeping gate crowding at a minimum. It makes things safer not only for train operation, but also addresses crowd control health concerns in the COVID era.
A reader sent a link to a good discussion of NFC protocols and gate tap speeds that was apparently deleted when YouTube comments were turned off. I retyped the comment below from a screenshot with some light editing for clarity. If I find the author I’ll link to the original. The videos have already appeared in other posts but it’s good have them in one place. A previous installment already covered QR transit code gate issues, this post will focus on NFC.
While transit gates and NFC processors are found worldwide, what makes the Japanese gates different from the rest of the world is they don’t use global standard ISO 14443 (never mind Type A which uses Miller bit coding, the least efficient bit coding method) protocol which is common in many transit and bank cards issued worldwide.
The tap time with ISO 14443 Type A (née Philips) and B (née Motorola) varies greatly: from 200 to 500 milliseconds (ms) with 200 ms only achievable with Type B/Calypso. But it never reaches the short as 100 ms which is only achieved with Felica developed by Sony, also designated NFC-F and NFC Tag Type 3 by the NFC Forum and compatible with ISO 18092 which is commonly found in smartphones and NFC wearables since 2013. In this following video passengers maintain their walking pace but never overshoot and trigger a gate closure nor slow down not even a bit:
It may seem like a minor difference but due to the high volume of passengers per gate and to reduce gate maintenance requirements, tap times really matter.
Companies such as JR East have specified tap time of 200 ms but Suica is actually faster and this allows real life speed tolerances: some passengers tap faster than others due to walking pace, the higher speed tolerances are only possible with the 100 ms tap time of FeliCa. A comparison example of large crowds at gates in Malaysia and Japan below:
Open Loop NFC ticketing in its current form is based on EMVCo Contactless specifications adopted in contactless bank cards issued worldwide including China UnionPay QuickPass which is PBOC derived from the EMVCo Contactless spec. All of these use ISO 14443 Type A at 106 kbps only for 500 ms tap time, which is adopted in cities worldwide such as London, New York, Moscow and Rio de Janeiro where normal walking speed is never supported.
But as seen here, transit cards in Japan such as Suica, PASMO and ICOCA are supported for ultra hight speed and precise account verification and fare processing. Transit cards use offline Stored Fare (SF) which includes the amount of funds stored in the card’s IC smart chip data storage, NOT backend on a server like a bank card, and stored commuter passes. Here are walk flow comparisons for Tokyo and London, and MTA OMNY Open Loop performance:
The tempest in a teacup over Marukame dropping QR Code cashless payments at some restaurant locations turned out to be parent company Toridoll Holdings updating their POS system. QR Code support will return with the same cashless payment lineup supported at all locations.
The brouhaha is a good opportunity to catch up with an issue I have been meaning to blog about for some time: cashless transaction fees. The ever reliable Junya Suzuki did everybody a favor reporting the Toridoll situation with his usual levelheaded expertise. He also puts out a wonderful series called ‘Pay Attention’ that covers Japanese cashless and payment issues with a unique on the ground reporting style.
In a recent installment, “The Cashless Transaction fee paradox” he discusses the complex Japanese cashless transaction fee landscape. Actually it’s complex everywhere because listed transaction fees are not necessarily what merchants end up paying. It’s an ever changing game of negotiation. And it’s a shell game of POS equipment rentals, extra software services and consumable gotchas like paper receipt printer rolls.
Let’s make a deal The real issue is transaction fees. AirPay and other middle range mobile based POS system players like Rakuten Pay and J-Mups all offer similar transactions fees that range between 3.24~3.74%. As Suzuki san explains, this works out to be roughly 0.5~1.0% higher than a cashless transaction in America using Square.
Those fees are not what all merchants end up paying, but real rates are kept secret. Even Suzuki san, who has comprehensively covered the cashless scene for over 10 years, has no hard numbers, just ballpark estimates. In general 3~5% for goods, 5~8% for services. Low margin but large convenience store chains, i.e. merchants with clout, are aggressive and negotiate lower transactions fees with their large sale volumes.
Super low margin businesses like family owned supermarkets get caught in a catch-22 situation where the more cashless is used, the more that transaction fees eat into their margins (razor thin 1% margins for smaller chains). It’s fascinating stuff and you should read the original Japanese article if you have the ability or translation software.
This complexity makes me skeptical of article claims like, “Apple’s arrogance angers Korean card issuers.” The reality is plain old fee negotiation, by any means necessary, to get the upper hand. I suspect the fact that only 30,000 or so Korean merchants out of some 2.8 million are equipped with NFC readers, is the bigger reason for Apple Pay Korea not launching. Nobody wants to buy new POS hardware just for Apple Pay, so it’s back to the negotiation table.
stera all-in-one cashless platform The stera terminal cashless platform is launching July 6. FNN has a nice overview video of stera and what it hopes to accomplish. All major protocols (EMV, FeliCa, QR) and payment networks are supported in an all-in-one reader. The difference between stera other mid-market solutions is the integration of hardware and software frontend all the way to the GMO internet based transaction backbone and gateway. SMBC and Visa Japan will certainly use stera to promote EMV and Visa Touch, but it’s a smart solution that runs on Android OS so it can be updated and tailored for multiple POS systems. It will be interesting to see what the impact of stera is and how CAFIS based payment solution providers compete with it.
Apple Pay Octopus has been in service for a week so I asked for some Apple Watch field impressions on Twitter. Overall, users seem pretty impressed:
I am using it daily and it is really out of this world. I use it on my watch and now I can literally go out for a jog or hike with just wearing the watch.
It works perfectly on my AW so far. But from I’ve heard on LIHKG, there some users facing the difficulties on the express mode. Mostly are requiring passcode when going through the gate.
It’s mostly positive. However there’re times where the reader isn’t sensitive enough and need to linger the watch longer. Also going to work first thing in the morning but forgetting to enter pass code in the apple watch is frustrating since it doesn’t inform you need to unlock.
Been using AW Octopus everyday. Use cases include MTR, tram, ferry, 7-11, eating meals at all sorts of restaurants like Tai Hing, Ki’s Roasted Goose, Pret etc. Octopus on Apple Pay drastically improved HK’s cashless experience. It’s definitely okay for me to go out with only AW. Not even with my phone. Feels really good. The speed of payment is also very remarkable. However, the reader in Tai Hing seems to need an extra second to detect my AW, not sure why. Plus AW users might want to wear it on the right wrist, which makes passing MTR gates easier.
Using it everywhere. All good and same speed as physical card, expect bus and some small shops were like a heartbeat slower. Also twice there was no “ping” confirmation sound. Tried AW on my right for mtr, its only good for that, imo left is more comfy for other occasions…
… after so many years of waiting, finally an apple pay suica experience in HK.
You can follow the Twitter thread here. I have noticed a few small gate lag hiccups on my Apple Watch Suica since upgrading to watchOS 6.2.5/6.2.6. The lag is especially noticeable if a workout is in progress. The passcode request at the gate could indicate that Express Transit is deactivated somewhere along the way, either by a loose band activating the wrist detector into thinking Apple Watch was taken off the wrist, or it could be something else.
My Apple Watch insisted that I create a 6 digit passcode recently and disabled the 4 digit passcode option for a few days. Who knows, the passcode requests that some HK users are seeing could be a watchOS bug or an Octopus reader side issue that can be addressed with a firmware update.
Apple Watch is still prone to OS version performance issues that disappeared from iPhone with A12 Bionic and Express Transit with power reserve. Apple Pay transactions on A12 Bionic and later bypass most of the iOS layer and are directly handled in the A12/A13 Bionic Secure Enclave and Secure Element. It makes a big performance difference for Suica and Octopus.
Hopefully the next watchOS update will improve Suica and Octopus performance. Better yet let’s hope that Apple Watch 6 introduces a Apple S6 chip with Express Transit with power reserve. That would solve the watchOS version NFC performance issues for good, just like it did for iPhone.
Apple Pay Octopus launch day was a big success, so successful that Octopus apologized for their servers buckling under the demand. What’s next for Octopus, Google Pay? There are some possibilities but when it comes to Android there is the matter of the Secure Element (SE), where it resides and what transaction protocols are supported.
From the NFC hardware angle everything has been ready to go on all smartphone hardware for years, NFC A-B-F is required for NFC certification. The problem has been on the SE side, the black box where all the transaction magic happens. From Global Platform the SE certification organization:
A SE is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the rules and security requirements set by well-identified trusted authorities.
There are different form factors of SE: embedded and integrated SEs, SIM/UICC, smart microSD as well as smart cards. SEs exist in different form factors to address the requirements of different business implementations and market needs.
SE Wars and Google HCE ‘SE Pie in the Sky’ In the pre-Apple Pay mobile carrier hardware era, carriers used SE SIM or embedded Secure Elements (eSE) + SIM combos that chained customers to service contracts for the privilege of using mobile payments. This is the classic Osaifu-Keitai textbook maneuver pioneered by NTT Docomo: leave those pesky SIM Free whiners in the cold world of plastic cards and hard cash, or crippled digital wallets until they give up and buy an overpriced carrier SIM. This brain dead approach is one reason why Mobile FeliCa ended up being ridiculed as ‘galapagos technology’ even though everybody copied it with inferior crappy me-too products.
This carrier SE hostage situation, i.e. the Mobile Wallet SE Wars, led Apple and Google to follow different strategies to address the problem.
The Apple Pay Way Apple’s answer of course was Apple Pay. A unique in house strategy of putting a Global Platform certified Secure Element in their A Series/S Series chips then building it out from there. Most eSE go on the NFC controller, but doing it the Apple in-house way has advantages over a NFC chip vendor bundle: control of the eSE applets and ability to update them and the Apple eSE for new protocols in iOS updates. We saw this in action with the addition of FeliCa in 2016, PBOC in 2017 and MIFARE in 2018. We may even see the addition of Ultra Wideband (UWB) Touchless in iOS 14.
The Google Pay Way Google’s answer to the carrier owned SE problem was the more convoluted evolution from Google Wallet (2011) to Android Pay (2015) and finally Google Pay (2018). Google first salvo was Host Card Emulation (HCE): “NFC card emulation without a secure element” hosted on Google’s cloud. Later on Google attempted to do the same for FeliCa with HCE-F.
But then something happened that put an end to all this: Google decided to get into the hardware business. And now we have Google Pay and Google Pixel with it’s own embedded Secure Element (eSE). With Pixel, Google decided they didn’t want to be the Secure Element cloud provider for every Android OEM out there especially when the Chinese OEMS are all rolling their own eSE based digital wallet services anyway, completely ignoring HCE. Sure, HCE/HCE-F is still there in the Android developer documentation but it’s a dying vestigial relic of the SE wars.
But Google Pixel depends on vendor bundled eSE + NFC controllers and this makes global NFC support more complicated because Google doesn’t ‘own’ the eSE, at least not in the Apple sense of making their own all in one design. This is one reason why Pixel 3/4 only support FeliCa in Japanese models even though all worldwide models have the same NFC A-B-F hardware.
The end result of all this is the Android market is a very fragmented landscape, there are no global NFC Android smartphones: a device that supports EMV, FeliCa, MIFARE, PBOC out of the box in one globally available package.
Google Pay Octopus and the Android Global NFC Installed Base Back to our original question, can Google Pay Octopus happen? We already have Google Pay Suica right? Let’s assume that Octopus Cards Limited (OCL) has everything in place for it to happen. Here we run into the problem just described: there are’t any global NFC Android smartphones available globally. Samsung sells them in Japan and Hong Kong, Google only sells them in Japan along with Huawei, Oppo, Sharp, etc.
For OCL this means the potential Google Pay installed base that can support Hong Kong Octopus consists of Samsung Galaxy smartphones that are already using Smart Octopus in Samsung Pay; not exactly a mouth watering business opportunity worth the support expense. If Google Pixel 5 goes deep instead of cheap Hong Kong would have a potential Octopus non-Samsung Android device, but that’s only one new device not an installed base. I only see Google Pay Octopus happening if Google foots the entire support expense.
There is a way forward however for OCL: Garmin Pay Suica. The same Garmin APAC models that support Suica can also support Octopus, the recharge backend is entirely Google Pay. Garmin smartwatches work with any Android 5 and higher smartphone, a much larger installed base that bypasses the fragmented Android landscape. Garmin Pay Octopus would offer Android users a way in, who want to use Octopus on a mobile device but who don’t want to use Samsung or Apple devices.
The conclusion: forget Google Pay Octopus for the time being. Hong Kong is a golden opportunity for Gamin Pay Octopus….if Garmin can get Garmin Pay clearance from Hong Kong authorities and banks, and cut a deal with OCL. It’s certainly in Octopus’ best interest for OCL to help turn the negotiation wheels. It’s also in Google’s interest as Google Pay would supply the recharge backend as it does for Garmin Suica. Big hurdles all, but I hope it happens.