Dear Starbucks, please give us a NFC Starbucks rewards card

The Starbuck app server was down this morning. Fortunately my daily Starbucks has Suica payments and the staff kindly stamped customer receipts so everybody could get the Starbucks Card refill discount. I posted a silly throwaway tweet about it but received some thoughtful reader feedback that put things in perspective.

On the surface it’s true that Apple controls Wallet NFC card access with PassKit NCF Certificates. However, the Mobile Starbucks Card for Osaifu Keitai came out in March 2014, two years before FeliCa made it into iPhone 7. The mobile card was put out by Starbucks Japan which was not majority owned by Starbucks USA. USA corporate bought out the Japanese business partner at the end of 2014 and brought it under full control. Up until then Starbucks Japan stock was a popular item for the free coffee ticket goodies that came with it. The food was better too. Mobile Starbucks is a relic that will likely be ditched at some point, like the free coffee tickets and good food.

Starbucks USA has never shown any real interest in creating a NFC rewards card. They chose the barcode app route that supports direct bank card registration and recharge. Eventually they added in-app Apple Pay and Google Pay support. Silly market analysts announced that Starbucks app was ‘bigger than Apple Pay’, until they decided that Apple Pay was bigger than apps after all.

Starbucks has put real effort into protecting staff and customers during the COVID crisis. It’s an amazing effort that doesn’t get much attention. Despite this, physical Starbucks Cards are still mag strip cards handed over to staff and swiped at checkout. If Starbucks put out a digital wallet Starbucks Card, how should they do it?

The easiest way on iOS would be an Apple VAS NFC contactless pass. In Japan this is what PONTA and d POINT cards are. Apple VAS is NFC A but it works in combination with any Apple Pay payment protocol, EMV, FeliCa, PBOC, etc. Smart Tap is a similar rewards card NFC method for Google Pay.

This is what customers get when they pay with ‘Apple Pay’ on the Lawsons JP POS system: the reader polls the Wallet default payment card and rewards card, the payment transaction occurs and points are automatically added to the rewards card.

This flexible ‘2 in 1’ contactless payment + rewards package would be very nice to have with Starbucks Card. For app users it would eliminates the ‘open app, pull up barcode, make sure card has enough balance’ nonsense that happens far too often and is easily thwarted by a weak WiFi signal. It would also reduce handling physical cards at checkout.

Unfortunately this requires a POS system that supports NFC contactless, and Starbucks in Japan only supports popular contactless payment cards like Suica and PASMO when the store location is in a station retail area. Starbucks has demonstrated a lot of forward looking business sense in the COVID era so far. I hope they rethink their Japanese POS strategy and incorporate contactless payments and reward cards as standard at all store locations.

Advertisements

PassKit NFC Certificates and the Apple Pay EU antitrust investigation

The EU antitrust investigation of Apple Pay boils down to this: does Apple have the right to be the gatekeeper of its Embedded Secure Element (eSE) in the Apple A/S Series chip, does Apple ‘own’ it? As of iOS 13 any Apple Pay eSE transaction that involves payments, transit, identity cards and contactless passes requires a PassKit NFC Certificate.

Apple has put massive effort and resources into making Apple Pay an easy seamless experience. Users don’t have to think about EMV, FeliCa, MIFARE, or NFC flavors. It just works. The price for using this is that 3rd party card and pass developers have to obtain a NDA PassKit NFC Certificate, reside in Wallet, and share a transaction cut with Apple. Apps are free to use iOS 13 Core NFC tag reading enhancements but NFC eSE transactions are not allowed, unless they have inner sanctum NFC Certificate access.

Australian banks fought Apple Pay in 2017 and complained to the Australian Competition and Consumer Commission (ACCC), demanding that direct NFC access for their apps is a ‘right’ but lost. The EU antitrust investigation will likely follow a similar path and attempt to force Apple to: 1) allow apps to access the eSE for payment transactions without using Apple Pay or Wallet, 2) lower fees for the 3rd party players who use Apple Pay.

We’ll see how it plays out. We’ll also see if Apple has any iOS 14 Apple Pay changes in store. I agree with Junya Suzuki’s spot take, who’s knowledge of the payments market, the players and the technology is second to none, that the EU would never demand the same thing of Samsung or Huawei that they are demanding from Apple. In other words, politics.

iOS 14 Apple Maps Japan Wish List: filling the blanks

Apple Maps Japan can’t catch a break. Traffic has been available since September 2019 but only got listed on the feature availability page last week, June 2020. Handa International Airport is currently listed for indoor maps but the data isn’t there. And so it goes for the Apple Maps 2.0 reboot. Here is a quick list of missing features along with some new feature requests.

Missing Pieces

There are several iOS 13 Apple Maps features that have not made it to Japan:

Apple Maps 2.0
New maps were rolled out in America in January 2020 with Europe slated next. A rollout for Japan has not been announced but Apple Maps vans and walkers are in the field working on it. Justin O’Beirne posted screenshots of Apple Maps’ cartography evolution from 2013~2019. The basic design language for urban areas hasn’t really changed the entire time. Cartography for Japanese urban areas is already drowning in detail and screams for an overhaul to make it intelligent and easy to use: a more unified cartography that does a better job of incorporating transit instead of useless separate ‘views’.

More accurate detail is welcome but I don’t think Apple can ever get the whole picture by themselves. Google Maps real genius is it’s deft ability to synthesize disparate data suppliers in a seamlessly whole service. Apple Maps biggest single failure, from day one to today, is it’s utter inability to synthesize various data suppliers into a solid service.

It’s a chunky clunky Japanese product, from eternally 3rd rate map data from IPC on down to Foursquare. Top Japanese map data supplier Zenrin is the logical choice especially since Google dropped them, but Apple doesn’t seem inclined to switch, nor could they intelligently integrate it.

Justin O’Beirne: The Evolution of Apple Maps’s Cartography

Look Around
It would be very nice to have this feature in Japan.

Junction View
Navigating complicated elevated expressways in urban areas isn’t just in mainland China, it’s been a fact of Japanese urban driving since the 1960s’. Junction View like navigation has been standard in Japanese navigation systems for a long time, it should be standard in Apple Maps too.

Real-time transit
Another no-brainer transit feature for Japan, but Japan is a low priority and the transit system is complex. There are plenty of transit data suppliers but given Apple Maps limited ability to integrate different transit data sets, I think it will be a long time before we see the addition of real-time transit in Japan, if ever.

There are small tweaks Apple could make to transit directions that would make them much more useful such as transfer station platform numbers and crowd conditions, features that Google and Yahoo Japan have offered for a long time.

New Features

The iOS 14 Apple Maps wish list has some repeats from the 2019 wish list:

  • Adaptive transit times: car and walk navigation is adaptive: if you take a different road the navigation route updates automatically. Transit directions need to be adaptive too.
  • Crowding information: Yahoo Japan offers crowd heat maps for locations, both Yahoo Japan and Google Japan maps offer rudimentary transit crowd information. In the COVID era crowd information for transit and locations is a must have feature.
  • Improved Apple Watch transit integration: Apple Watch turn by turn navigation integration with iPhone is excellent but transit integration is weak and passive. The current iOS 13/watchOS 6 version ‘sits on the wrist’ without alerts, haptic feedback or much interaction, and it’s brain dead after switching to another watch app.
  • Indoor/Underground Station Maps: Last but not least real indoor maps for vital station hubs covering Tokyo, Shinjuku, Ikebukuro, Osaka, Namba, etc.
  • Offline navigation: Apple Maps turn by turn won’t be completely reliable unless it navigates in expressway tunnels instead of dying.

Transit Gate Evolution: why tap speed matters

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:

Japanese IT journalist Junya Suzuki tests OMNY transit gate speed…
and reliability

One hopes the NFC Forum works to increase NFC speeds and global specifications to “improve the overall user experience for NFC users.” We shall see.

With the exception of any Apple Pay news from WWDC20, this will be my last big post for a while. Stay healthy, stay safe and have a great summer.

One week in

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.

A12/A13 Bionic makes a big difference in NFC performance,