Garmin Pay Suica aka Google Pay on iOS

Garmin Pay Suica went live May 21, effectively breaking the 4 year Apple Watch/Apple Pay Suica monopoly. As any Apple Watch user in Tokyo will tell you, Apple Pay Suica is the killer Apple Watch app. The real secret of course is Express Transit payments. Even now I get the occasional oh and ah from store staff when I hold Apple Watch up to the reader. They really appreciate the speed and social distance. So do I.

Since Garmin only does smartwatches, there are inherent limitations and big differences from Apple Pay Suica: (1) there is no way to transfer a plastic Suica to Gamin Pay, users have to create an account and a new virtual Garmin Pay Suica card, (2) Garmin Pay Suica does not support Suica Commuter Passes, (3) Garmin Pay Suica can only be recharged with Google Pay, (4) Garmin Pay Suica is limited to Japanese Garmin models, it is not global NFC like iPhone and Apple Watch.

Outside of that Garmin Pay Suica is a regular Suica with ‘Rapid Pass’ instead of Express Transit, different name, same thing. It can be registered for SmartEX and Ekinet Shinkansen eTicket travel. iOS users setup and recharge via the Garmin Connect Mobile app.

Garmin Pay Suica limitations limit its appeal for iPhone users who already have the full range of Mobile Suica service on Apple Watch. It’s a boon for Android users who have lusted after a Suica smartwatch. It very weird that it has taken 4 years for Android based device makers to even attempt matching the killer combo of Apple Watch and Apple Pay Suica. I hope Garmin works to improve the service and remove the limitations. Android users would really appreciate having the full Mobile Suica experience on a smartwatch.

UPDATE: there’s some gray area whether all Asian models support Suica or just the devices sold in Japan. I’ll update any discoveries here. Other limitations like Suica Commuter passes are also interesting and suspect they shed some light on the Google Pay~Osaifu Keitai relationship. In many ways Google Pay Suica is a UI skin on top of the Osaifu Keitai stack. In the case of Garmin Pay, no Osaifu Keitai stack means no Commuter Pass support even though it depends on Google Pay for recharge.

The Transit Platform Argument

A reader asked some very good questions regarding the Suica Transit Platform model and Open Loop:

1) Thinking about this recently – is there a non-techie argument for introducing Suica-type cards in the current day in places with preexisting open-loop infrastructure, wide debit card adoption (even kids), and little overcrowding at ticket gates due to lower volumes?

2) As a tech & transit nerd, I obviously love them, but what could be a convincing, economically sound pitch to a transit operator for creating/adopting an integrated transit&e-money system, given the significant expense and questionable added value?

3) Answers to possible q’s about EMV contactless: 1. 定期券 (commuter passes) & discounts can be tied to card no.; 2. solution for visitors: in-app/paper/multi-trip tickets (like in SG). Obv., Suica has superior privacy & speed, but where speed is not an issue, what’s the killer argument?

I tweeted a response but Twitter is a terrible vehicle for long form discussion. I have many posts on the subject scattered over 2 years, it might be convenient to summarize a few things here.

Any argument for building a Transit Platform or going all in with Open Loop transit comes down to transit company priorities for safe operation, better customer service and long term business goals. A few crucial points to consider.

Whose customer?
A vital point that many people miss in the Open Loop debate is that transit users end up as the bank card customer, not the transit company customer. That might seem like an insignificant difference but ‘owning the customer’ is the whole game and key to growing any kind of business, in our era or any era. Which brings us to the next point because the best way to own the transit customer is…

Cards
Cards are the delivery vehicle for all kinds of service goodies from transit, to points, rewards and all kinds of services. The beauty of a non-bank transit pre-paid card is its flexibility, it can be a simple ticket that customers buy with cash from a station kiosk, it can be linked to an online account with credit cards, extended transit services and beyond. Cards are convenient but not transformative however, until they land on a smartphone…

Digital Wallets
The most powerful card incarnation is the digital wallet transit card with a flexible recharge backend, where any bank card can used, or even cash, and a flexible front-end that can be any flavor of NFC, UWB Touchless or even QR. I say it’s better for the transit operator to decide what payment technology works best for their needs and how to deliver better customer service with new payment technologies, not banks.

Value Capture
Value Capture applies to rail and transit operators with the rights to develop the land around their stations, I include station retail development and operations. Owning a transit + payment card like Suica or Octopus combined with retail opens up a whole new levels of value creation and capture.

It’s also important to remember a few other dynamics, (1) Transit is the golden uptake path for contactless payments, (2) Contactless payments are most successful when a transit payment platform, like Suica, is matched with a mobile wallet platform, like Apple Pay. The key is building better services tied to transit cards that benefit customers and businesses of the entire transit region.

Other Details
Regarding detail questions such as attaching commuter passes to EMV cards and special ticketing, I am no systems design expert but a few things come to mind. First of all we have not seen Open Loop commuter passes because the EMV spec doesn’t store anything locally and there are always security and performance issues to consider when everything is done in the cloud with soft-linked registration to system outside numbers.

The classic catch 22 here is that when the soft-linked number changes on one system, everything attached to it on the other system stops working. This is a constant weakness of the SmartEx and new JR East Shinkansen eTicket service. And what happens if the bank pulls a card mid-transit? These things happen. They are endless headaches when linking to any outside system, for this reason Open Loop sticks with the simple stuff while transit operators keep the more complex stuff in-house. In general the more complicated the fare configuration, the less likely it can be synced with an outside system or be hosted on Open Loop.

For low volume specialty ticketing QR Codes are the easiest step up from paper but they can be printed on ordinary paper for transit users without smartphones and needs to be there. This is why JR East is deploying QR code readers in some gates as they prepare to end mag strip ticketing.

NFC Contactless Passes might sound like a good idea but Apple Pay VAS and Google Pay Smart Tap were designed more for retail in mind, and the transit gate reader system would have to juggle a different protocol that isn’t EMV, FeliCa or MIFARE. It could be done, but judging from my experience of using Apple Pay VAS PONTA and dPOINT cards, QR Codes are faster and likely easier to implement.

In the long run there are no easy solutions. The risk of Open Loop is that it is sold as a general easy ‘fix all’ and mobile solution, which it’s not. This lulls transit operators into complacency instead of improving Closed Loop ticketing systems and extending them to the mobile digital wallets. The bigger and more complex the transit system, the less Open Loop can accomplish.

Relevant Core Posts
The Contactless Payment Turf Wars: Transit Platforms (an intro)
Transit Gate Evolution: Do QR Codes Really Suck for Transit? (a deeper dive into transit cards, gates and technology)
Value Capture and the Ecosystem of Transit Platforms (the bigger picture)
The Japanese Transit Platform Business Model (an outside perspective)

Fields of Dreams: the endlessly looping open loop vs closed loop transit debate

MacRumors reported that Apple Pay Express Transit support is finally arriving, bit by bit, on the TfL system after being announced back in May. I only noticed the piece because somebody threw a link to my site in one of the forum comments and the discussion has some interesting, and deliciously snarky, open loop bank cards for transit vs. native transit card debate.

The ‘Japan has a transit IC card problem’ angle is interesting. Yes, Japan does have a transit IC card problem, if you work for a bank credit card operation that wants to promote open loop, which I suspect is the case in the forum debate. The counter argument presentation-like power points are just too glib: to date no major transit system has junked native transit cards for bank cards, not even Oyster. Transit is a license to print money and the huge transaction volumes in Tokyo alone are mouth watering. The ‘problem’ for bank card players is how to angle for a bigger cut of the action.

The debate perfectly represents the plastic era transit card vs credit card mindset. More interesting to me are the things people don’t discuss: the impact of Apple Pay and Google Pay digital wallet platforms and transit business models. My take is that smartphone digital wallets do away with old plastic era distinctions and create new business opportunities for transit companies, if they chose to pursue them. Most don’t.

Tech analysts love to talk about ‘value capture’. The current cashless payments frenzy in Japan is all about capturing users to sign on with a payment platform then growing the ecosystem with more and more services that users, hopefully, want to pay extra for. Nobody talks about this in the open loop vs closed loop debate. The bank that owns the credit card owns the customer going through the transit gate, not the transit company. Put it this way, JRE POINT that go back into free Suica recharges, Green Car upgrades, etc. are vastly different from bank card points, as are the business platforms they feed customers back into. Moving people are money in motion, who gets a cut and what businesses do with that cut is everything.

It an interesting paradox that Europe and America talk about privatizing public transportation in various degrees but to date only Japan and Hong Kong have built highly successful businesses based on ‘value capture’. The endless open loop vs closed loop debate always comes down to this: you can argue all you want about the parts but in the end it is meaningless. To truly understand things, you have to examine the whole business model, how everything fits together, and how that can benefit everybody while growing and evolving.

Apple Pay Global NFC Lineup Updated with iPhone 11/Apple Watch 5

The Apple Pay Japan page has a special place in Apple’s web site galaxy. It is the only page that lists global NFC specs for Apple devices. This was the page where we learned about global FeliCa iPhone 8/iPhone X/Apple Watch 3 because Apple didn’t announce anything. So the Apple Pay Japan page check is a ritual and final word of global NFC support for every new Apple device.

There were no surprises after the latest new iPhone announcement. We all knew the Apple Pay Japan device spec list would be updated with iPhone 11/iPhone 11 Pro/Apple Watch Series 5 at some point, which it finally was this week. The ritual and peace of mind is always a good thing.

Just one last little question for Apple: when does the Hong Kong Apple Pay page finally join the Apple Pay Japan page for global NFC device specs now that iOS 13 Hong Kong Wallet mentions travel cards and Apple Pay Octopus is coming soon?

Pixel 3 Global NFC Evolution

Reader feedback and discussion from my earlier post analyzing the fuzzy state of iPhone 7 FeliCa and its possible support of Apple Pay Octopus, resulted in some interesting discussion about the Pixel 3 Japanese FeliCa model. From FeliCa Dude’s epic Reddit Octopus on iPhone 7 post:


<reader comment> Regarding the Pixel though, are you sure that the non-Japanese Pixel 3 models even have an eSE <embedded secure element>? I was under the impression that these were HCE <host card emulation> only.

<Felica Dude answer> All the Pixel 3 devices have an eSE, but it might not be able to be enabled by the end-user, and even if it is possible, it won’t be provisioned. A teardown of the global edition Pixel 3 XL (G013C) reveals a <NXP> PN81B.

The NXP PN81 announced in February is all-in-one off the shelf global NFC chip that includes both the frontend NFC A-B-F hardware and the necessary embedded secure element (eSE) + keys for EMV, FeliCa and MIFARE. The odd thing is that the Google Pixel 3 Japanese model apparently doesn’t use the PN81 for FeliCa, and has a separate FeliCa chip sitting in the fingerprint sensor assembly inside the back case.

Google Pixel 3 JP SKU iFixit teardowns do not exist but I did run across an interesting article from the Keitai Watch site showing a Pixel 3 JP SKU being taken apart for repair at an iCracked repair shop.

Just for kicks, I called the iCracked shop and asked about repairing a faulty FeliCa Pixel 3 device. The Pixel 3 repair technician explained that a FeliCa chip replacement was not expensive because it is not on the motherboard, “it’s attached to the fingerprint sensor assembly.” Look carefully at the picture from Keitai Watch piece and you can see the back case with fingerprint sensor assembly that the technician was referring to.

Disassembled Pixel 3 JP model from Keitai Watch

This presents a very strange situation. All Pixel 3 SKUs have the FeliCa ready PN81 chip but don’t use it, while Pixel 3 Japan SKUs might have another separate FeliCa chip attached to the back case finger sensor assemble. Google alludes to this on the Pixel 3 support page: If you purchased your Pixel 3 or Pixel 3a phone in Japan, a FeliCa chip is located in the same area as the NFC. There is also the recent batch of Pixel 3a Japan SKUs with bad FeliCa chips, but reports of bad NFC (EMV) Pixel 3a international SKUs have not surfaced; this also suggests a separate FeliCa chip. Why have two FeliCa chips in a device when one will do?

My take is different from FeliCa Dude: the Pixel 3 does not use the PN81 eSE or ‘pie in the sky’ HCE for anything. Instead, Google Pixel 3 uses the Titan M chip Secure Enclave as the virtual eSE for EMV and MIFARE, similar to what Apple does with the A/S Series Secure Enclave. Titan M FeliCa support was either not ready, or Google wanted to test the Japanese market before making a custom hardware commitment.

The point of all this is that Google has laid the foundation for a global NFC Pixel 4 made possible by a custom Google chip. The Titan M is Google’s answer to Apple’s A/S Series Secure Enclave that can host any kind of virtual embedded secure element for any kind of transaction technology, from EMV to PBOC.

I might be wrong, but even if my virtual eSE on Titan M take is incorrect, taken all together with the NXP PN81 development, I think Pixel 4 will finally be the global NFC Android device that many have hoped for.

UPDATE: extensive testing by FeliCa Dude did not support my eSE on Titan theory. The chip in question is the FPC1075 chip interface between the fingerprint sensor and the SPI bus. Pixel 4 is not global NFC, which says it all and knocks everything back to square one: there is no separate FeliCa chip, it’s a NXP PN81 chip all the way. Google hardware support page wording is very misleading, nothing more.