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.

Advertisements

JAPAN CASHLESS: Cafe Veloce offers 5% cashless rebates

Finally! A cafe chain with JAPAN CASHLESS rebates and 5% at that. Sayonara Starbucks and hello Cafe Veloce, until July 2020 anyway.

UPDATE: as always some locations are not onboard yet even though Cafe Veloce parent company Chat Noir says they all are. Be sure to check for the CASHLESS logo on the door.

UPDATE 2: confirmed with Chat Noir that all locations are onboard.

Toyota Wallet: if there must be another Japanese Wallet app, please let it be this

As I have pointed out countless times on this blog, Apple Pay Suica is one of the best Apple Pay services that Apple has hosted on its platform so far. The first transit card on Apple Pay remains the best: it combines the speed of the Suica transit card FeliCa architecture, the convenience of the Mobile Suica cloud, and the flexibility of the Apple Pay recharge backend.

The Apple Pay Suica sandwich: an open flexible recharge backend, sandboxed stored value (i.e. not hot wired to an app account), NFC FeliCa frontend.

This last point is under appreciated. The deal Apple and JR East worked out is the secret sauce: Apple Pay cards in Wallet just work for recharge, from Japan or from abroad, with no extra fees across the board, users earn points for the card of their choice. And users still have the option to recharge with cash if they want to.

A new kind of Wallet app
Toyota Wallet for iOS unveiled on November 19 finally gets right what other QR/Bar Code apps like PayPay have not: a flexible backend matched with a flexible frontend. A version for Android is due in the spring of 2020.

Toyota Wallet is built using the PAYCIERGE platform from TIS. The user has a choice between payment with QR/Bar Code in the Toyota Wallet app with Origami Pay or Bank Pay accounts, or payment with a dual mode EMV/FeliCa iD Mastercard prepaid card in Wallet with the backend recharge hosted from Toyota Wallet.

An interesting side note here is that both PayPay and Line Pay have said that FeliCa cards are a possibility. Up until now this has just been lip service. It would be a welcome development if the Line Pay/Yahoo Japan merger produces a FeliCa payment option similar to what Toyota Wallet has done.

Toyota Wallet is still not open in the way that Apple Pay Suica is. All of the ‘recharge’ methods are in the SMBC orbit, even iD recharge credit cards have to be SMBC issue (such as Docomo dCard) Visa or Mastercard to avoid hefty recharge fees. It’s not perfect and remains chained to the SMBC financial ecosystem, but Toyota Wallet does point a way forward that I hope Toyota Finance Corp. continues to improve, and that other payment system operators follow.

Summary
The Toyota Wallet flexible backend/flexible frontend development is a step forward for digital wallet possibility. This is the first Japanese wallet app where the frontend technology is a simple user choice, not a straitjacket. It shows the innovation possible in Japanese payments market where the focus is on creative thinking. That this kind of innovation comes first on the Apple Pay platform says all you need to know about Apple Pay being open. Compare this approach to the Europe one where the focus is forcing others to solve problems that Europeans should be solving themselves. That approach is a political one, not innovation.

What’s the difference between iOS 13 Wallet created Suica and SuicaEng?

iOS 13 Wallet gained the ability to directly create a Suica card without an app. Judging from Twitter posts however, it seems inbound visitors prefer SuicaEng for adding Suica to Apple Pay. This is understandable: SuicaEng is a onetime use app that completely removes the ‘set Region to Japan’ to add Suica requirement that confuses people. The region change is only for adding Suica but many people seem to think that the iPhone Region must be set to Japan to use Suica, which is not true: Suica works regardless of the device Region setting. Apple clearly needs to improve the Wallet UI so that users can easily add different country cards without a confusing side trip to Settings and Region.

It doesn’t matter how a user adds Suica to Apple Pay but there are some interesting differences. There are 3 basic variety of Suica cards when buying a plastic one from a station kiosk or creating a virtual one in Suica App: non-registered Suica, registered My Suica, commuter Suica.

Non-registered plastic Suica cannot be re-issued if lost and the balance is gone too, but the arrival of Apple Pay Suica blurred the lines between non-registered and registered My Suica. Technically the distinction is still there and JR East is not obligated to refund or re-issue a non-registered Suica if it stops working on Apple Pay.

Regardless of the variety, when any plastic or virtual Suica is added to Apple Pay the user Apple ID becomes part of the Suica card ID, permanently attaching it to the Apple Pay and Mobile Suica systems like a petrified barnacle. This is the reason why Apple Pay users must refund/delete all Apple Pay Suica cards and their Mobile Suica account if they migrate to Google Pay Suica (and vice versa).

The differences between SuicaEng and iOS 13 Wallet created Suica boil down to:

  1. SuicaEng creates a single non-registered Suica card in Wallet, it cannot create more than one.
  2. iOS 13 Wallet creates a registered My Suica and can create multiple Suica. It’s a very tight integration between Apple Pay and Mobile Suica.

Not that users will notice any difference because all Suica look and work exactly the same way. The differences are hidden away from the users on the backend, exactly as they should be.

What does open Apple NFC really mean?

The German law to force Apple to open it’s “NFC chip” is a confusing one. Why does an EU country with one of the lowest cashless usage rates single out one company’s NFC product in a last minute rider to an anti-money laundering bill? That’s not banking policy, it is politics. Details are few but let’s take a look at what it could mean because when it comes to NFC technology, details are everything.

Background stuff
The so called Apple ‘NFC chip’ is not a chip at all but a hardware/software sandwich. The Apple Pay ecosystem as described in iOS Security 12.3 is composed of: Secure Element, NFC Controller, Wallet, Secure Enclave and Apple Pay Servers. On one end is the NFC chip controller front end that handles NFC A-B-F communication but does not process transactions, on the other end there is the Secure Enclave that oversees things by authorizing transactions. The fun stuff happens in the Secure Element middle where the EMV/FeliCa/MIFARE/PBOC transaction technologies perform their magic with Java Card applets.

The A/S Series Secure Enclave and Secure Element are the black box areas of Apple Pay. The iOS Security 12.3 documentation suggests the Secure Element is a separate chip, but Apple’s custom implementation of the FeliCa Secure Element, and the apparent ability of Apple to update Secure Element applets to support new services like MIFARE in iOS 12 suggests something else, but it is anybody’s guess. Apple would like to keep it that way.

So what does ‘open NFC’ really mean?
It’s helpful to look at the issue from the 3 NFC modes: Card Emulation, Read/Write, Peer to Peer.

Peer to Peer
Apple has never used NFC Peer to Peer and I don’t think this is a consideration in the ‘open NFC’ debate.

Read/Write
This was a limitation up until iOS 12, but everything changed when iOS 13 Core NFC gained Read/Write support for NDEF, FeliCa, MIFARE, ISO 7816 and ISO 15693. Developers can do all the NFC Read/Write operations they want to in their apps, I don’t think this is a consideration in the ‘open NFC’ debate.

Card Emulation
Apple limits NFC Card Emulation to Apple Pay Wallet with NDA PASSKit NFC Certificates. This is what the ‘open NFC’ debate is all about. I imagine that German banks and other players want to bypass the PASSKit NFC Certificate controlled Apple Pay ecosystem. Instead, they want open access to the parts they want, like Secure Element, NFC Controller, Secure Enclave, and ignore the parts they don’t want like Wallet and Apple Pay Servers. They want the right to pick and choose.

The success of Apple Pay has been founded on the ease of use and high level of integration from a massive investment in the A/S Series Secure Enclave and other in-house implementations such as global FeliCa, etc. Outside players forcing Apple to open up the Apple Pay ecosystem represent not only a security risk to Apple but also a reduced return on investment. One commentator on MacRumors said it’s like Apple took the time and expense to build a first class restaurant and outsiders are demanding the right to use Apple’s kitchen to cook their own food to serve their own customers in Apple’s restaurant. It’s a fair analogy.

The NDA PASSKit NFC Certificate gate entrance rubs bank players the wrong way as they are used to giving terms, not accepting them. The Swiss TWINT banking and payment app for example is a QR Code based Wallet replacement that wanted the ability to switch NFC off, and got it.

My own WWDC19 Apple Pay Wish List did include a wish for easier NFC Card Emulation, but nothing appeared. It’s certainly in Apple’s best interest to make it as easy as possible for 3rd party developers to add reward cards, passes, ID cards, transit cards, etc. to Wallet. However given that the EU is hardly what I call a level playing field, the fact that bank players and politics go hand in hand in every nation, and the fact we don’t know the technical details of what the German law is asking Apple to do, all we can do is guess. In general, I think Europe will be a long rough ride for Apple Pay. At least until EU bank players get deals they are happy with.