Now that the CASHLESS Rebate program is over with transaction rates said to be going back to ‘normal’ (an estimated 1% rise over program rates), JP media outlets report that some smaller merchants might go back to cash to keep profit margins intact. Real transaction rates are always hush-hush but we can get an idea from the QR payment rates recently revealed in connection with the Japan QR (JPQR) unified code scheme:
NTT Data already lowered basic CAFIS transaction rates in response to the stera payment co-venture from SMBC-Visa Japan-GMO. As the JPQR transaction rate chart makes clear, banks and payment players have plenty of transaction rate wiggle room. The Japanese government is pushing cashless. If necessary the push will become shove for lower rates and yet another cashless program but where do things stand right now?
July 2020 is the proverbial “X-Day” crossover point: Japan is cashless now, even though it’s an uneven, ongoing and very messy transformation. On the customer side cashless is the mindset and survival behavior for many Japanese, even for older folks who under normal circumstances would prefer cash until they day they die.
Faced with the reality of handing money that carries the risk of infection, people are going cashless instead, especially with contactless smartphone payments. Junya Suzuki was right all along, Apple Pay turned out to be “the black ship of payments” catalyst that finally nudged Japan from cash to cashless. That and COVID.
Market analysts who want a neat set of chart data that clearly explains and quantifies the transformation before declaring ‘the winner’ have a long wait. The said transformation is sloppy, all over the place and happening right before us, but also an afterthought. Priorities are different, getting accurate market survey information in the current environment will be extremely difficult.
The Tokyo Olympics was supposed to be the event heralding the new era but the COVID crisis has forced much more rapid change. Evidence is best found in the countless little rituals of daily life that have evolved and are not going back. Merchants who do go back to cash face the risk of fewer customers: when offered a choice people choose cashless.
This realization hit me yesterday when my partner complained about his Docomo dPAY points taking a hit because the Summit supermarket staffer tapped a wrong payment button on the new POS cashless menu options added on July 1. He wanted to pay with iD. A year ago he never used iD, dPAY or Apple Pay and never wanted to, but life changed.
These days I hear contactless reader sounds everywhere, FeliCa chirps and EMV beeps are common as clear plastic sheeting and foot position floor stickers at checkout. If there’s anything that defines this sea change it is this: it’s not a ‘victory’ over cash that the media sometimes depicts, nor does it feel like progress. In the COVID era it merely feels like survival.
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:
As of June 2020, Express Transit can be used with 8 transit networks: Japan (Suica and compatible nationwide), China (Beijing, Shanghai and China T-Union), Hong Kong (Octopus), United Kingdom (Transport for London), New York City (MTA OMNY compatible stations and buses) and Portland (HOP). Here are some Express Transit card tips and other observations for Apple Pay Wallet users that I have learned from years of daily Express Transit Suica use.
1) Face ID Express Transit use with face masks and tight pants
The most important thing to remember is that Express Transit only works while Face ID/Touch ID is ‘On’, when Face ID/Touch ID is disabled Express Transit is ‘off’.
Express Transit doesn’t care if you are wearing a face mask. However it is easy to disable Face ID iPhone without realizing it, resulting in a rude passcode request at the transit gate. Face ID face mask users need to be extra careful as five misreads disable Face ID and Express Transit. The passcode is required to re-enable Express Transit.
Users can mitigate some of this by turning off Raise to Wake in option in Settings > Display & Brightness. If you still have problems the last resort is turning off Face ID for unlocking iPhone, be sure leave it on for Apple Pay.
All iPhone users, both Face ID and Touch ID, need to be aware when putting iPhone in tight pants pocket: pressure on the side buttons initiates shutdown/SOS mode which disables Face/Touch ID and Express Transit. This is worse with a case because iPhone in a case is thicker and tighter in pant pockets, with more pressure on the side buttons.
2) Apple Watch Express Transit works for 10 minutes off the wrist
Suica and Octopus on Apple Watch are the ‘killer’ watch app that quickly becomes second nature. Its nice in colder months because Apple Watch works at the gate under layers of clothes, it beats digging iPhone out of a pocket. The biggest complaint I hear is from left wrist Apple Watch users. Most transit gate readers are on the right side so the user has to reach over to the reader. This will be a bigger pain with new JR East transit gates that place a slated reader on the right side. Some commuters migrate Apple Watch to the right wrist to deal with it.
One interesting aspect of Apple Watch Express Transit is that it works for 10 minutes off the wrist. This is by design in case the transit card needs servicing by a station attendant. After 10 minutes, Express Transit turns off and requires the passcode to work again.
3) Multiple Express Transit Cards
The addition of EMV Express Transit in iOS 12.3 introduced the concept of having multiple Express Transit cards, one payment credit/debit card for transit use and one native transit card for each transit network (Suica, Octopus, Beijing, Shanghai, HOP, etc). The fine print tells a different story: if you have a China mainland transit card set for Express Transit, all other NFC-A protocol cards (EMV, MIFARE) are turned off.
There’s more to the story not covered in the Apple support doc: China T-Union Express Transit cards are incompatible with all other Express Transit cards. A set of reader images shows the issue. Turning on Express Transit for China T-Union turns off all other cards, both native and EMV payment cards. China T-Union cards are a bit messy in that older card formats like Beijing City Union are migrating to the new spec that does not support plastic card loading for mobile. Shanghai remains with the old spec with plastic card transfer for now but will also likely migrate in the future.
Shenzhen cards are also migrating from the legacy FeliCa (blue and orange) cards to the new China T-Union (red and green) cards. This is probably one immediate reason behind the ‘one at a time’ Express Card issue that Apple will hopefully fix it in a future iOS version. It’s not a problem as most users only use one Express Transit card at a time and can turn them on and off as needed. It’s interesting to developers because it reveals some current architectural limits of iOS 13 Apple Pay.
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.