The VISA JP Apple Pay announcement and digital banking wars

MacRumors Sami Fathi: Customers with Visa cards…will be able to add their card to their Wallet on iPhone and Apple Watch.

Me: I like MacRumors but the writer here has no idea what the story is or that users have been using these cards in Apple Pay all along for store purchases.

MacRumors Sami Fathi: Hey! Could you elaborate on what you mean? Visa cards issued by those banks now have Apple Pay, correct?

Sure Sami, here’s the elaborate story. Do you know FeliCa? It’s the Sony created NFC standard that has been around a long time, long before EMV grafted NFC into contactless credit cards. When mobile payments launched in Japan back in 2004, Mobile FeliCa was the only technology that worked. So mobile payments for all major credit cards and Suica were built on Mobile FeliCa, the contactless payments infrastructure in Japan grew from that.

Fast forward to 2016. Phil Schiller announced FeliCa for iPhone 7 at the keynote and the launch of Apple Pay in Japan. VISA Japan didn’t sign an agreement with Apple but it didn’t matter much because VISA JP cards were available for Apple Pay thanks to previous Mobile FeliCa agreements covering the iD and QUICPay networks for store payments. The other card companies (Mastercard JP, JCB, American Express JP) signed with Apple.

It was a big success. But the Mobile FeliCa agreements only covered store purchases, they didn’t cover things like in-app purchases. Even though many Japanese users added their VISA cards to Apple Pay they couldn’t use them to recharge Suica cards because in app purchases were not supported.

Fast forward to 2020. VISA JP is a major sponsor of the Tokyo Olympics showering sponsorship money to promote ‘VISA Touch’ EMV contactless cards. They want customers to use VISA Touch at stores, not iD and QUICPay because the margins are nicer and EMV contactless is a world standard except for places like Japan (FeliCa) and China (PBOC). Most of the POS equipment in Japanese stores is multi-protocol ready so the customer NFC flavor is a moot point. For whatever reason, let’s say marketshare, VISA JP finally signed on with Apple Pay. The first indication something was up occurred in November when VISA suddenly appeared, and disappeared in the Wallet add card lineup.

What changed for all those VISA JP cards already working in Apple Pay Wallet these past few years? A VISA logo, in-app payments, dual mode NFC and Payment card Express Transit:

Did you get that Sami? Hello, anybody there?

Digital Banking Wars
Seriously though, it’s sad when tech writers don’t understand the story in the stories they write. All major Apple sites ran the same wrong story, it should have been: Visa JP Cards now fully support Apple Pay. Journalists do everybody a great service when explaining complex stories and connecting the dots in easy to understand ways, unfortunately nobody cares about getting it right. Which is a shame because there were other major things going on behind the VISA JP Apple Pay announcement that even the Japanese tech media missed: the very same day, NTT Docomo and MUFG announced a joint digital banking venture.

Let’s take a closer look at that VISA JP Apple Pay announcement, specifically the issuer launch list: APLUS, Cedyna (SMBC Financial), SMBC, Docomo, MICARD, Saison, JACCS, Rakuten. Do you see MUFG? Nope. MUFG brand VISA cards will join at some point, probably, but as VISA has put all their eggs in the SMBC basket, the companies are not on the friendliest of terms.

NTT Docomo and SMBC/VISA group feuded for years and called a stalemate. It was only a matter of time before NTT Docomo kicked SMBC to the curb, which they did yesterday with the MUFG joint announcement. Docomo and MUFG are going to leverage dPoint into an economic zone to rival Rakuten and SMBC/VISA V Point. It’s as simple as that. And here you thought that VISA JP announcement was only about Apple Pay. Think again, the economic zone mobile digital banking wars are just getting started.

SMBC VISA cards are EMV/FeliCa dual mode in Apple Pay but single mode EMV in Google Pay

The truth is in the tap

The Nankai Visa Touch test launch launched endless Twitter discussions about slow EMV contactless tap speeds and performance issues compared with Suica and other Transit IC cards. EMV contactless transit in Japan is novel so this is expected. But suddenly people are also referencing Junya Suzuki’s 2016 pre-Apple Pay Suica launch era ‘Is Suica Over-spec?’ piece. This has long been a favorite theme in Japanese tech media: Suica is more than we need, EMV contactless is ‘good enough’ so let’s do everything with one card, life is more convenient that way. Be careful what you wish for.

The 2016 launch of Apple Pay Suica was a great success of course, that changed the Japanese payments market and opened the door for the proliferation of QR payment services you see everywhere now. The one card must do it all concept is old hat but Tokyo Olympics sponsors Visa Japan and SMBC are trying very hard to convince Japan that Visa Touch cards are the transit future.

My position was and remains that one size never fits all. It doesn’t have to be a EMV or nothing choice portrayed in tech media, nor should it. Different technologies complement each other for a better user experience. Apple Pay Suica/Mobile Suica combines the convenience of EMV cards on the recharge backend with the speed and reliability of FeliCa based Suica cards on the NFC front-end, for a best of breed closed loop transit user experience. One interesting thing I pointed out in my retweet of Suzuki san’s Nakai open loop launch piece was that QR Nankai Digital Ticket gate performance in the his video is faster than Visa Touch because it’s closed loop.

The comment touched off an odd but interesting set of tweets from Suzuki san and his followers about gate design, reader performance and walk flow that boils down to this: if the reader transaction speed is slow, increase the distance between the reader and gate flap to keep people walking instead of stopping.

His follow up piece deconstructs ‘FeliCa is faster’ as half misunderstanding transit gate antenna design and RF communication distance because EMVCo reader certification dictates a smaller RF distance, the result of using the EMV contactless supermarket checkout spec on transit gates it was never intended for. All I can say is the truth is in the tap. In theory all NFC flavors and protocols offer the same performance but in real transit use they don’t. Better to get next generation Ultra Wideband Touchless gates in service and dispense with the ‘redesign transit gates for slow EMV contactless/QR transit’ debate nonsense. Design things for the future not the past.

The current Transit IC local stored fare model does have weak points as suggested in FeliCa Dude’s tweet: discount ticketing, rebates and refunds. If you purchase a Mobile Suica commuter pass, you can easily get a refund back to the bank payment card used to purchase the commuter pass. This is because Suica extras like commuter passes and Green Seat upgrades are supplemental attached services that don’t use the SF purse.

Rebates and refunds via the SF (stored fare) purse are a bottleneck. Suica App has a mechanism for dealing with some of this called ‘Suica Pocket’ for JRE POINT exchanges and refunds back to the SF purse. Mobile Suica card refunds are another matter and can only be refunded to a Japanese bank account. Octopus Cards Ltd. (OCL) has a special Octopus App for Tourists that refunds a card balance back to original credit card used for the initial digital card issue. OCL also charges tourist users an arm and a leg for Octopus Wallet recharge and refunding. It would be nice if JR East could do the same…without the outrageous OCL surcharges.

For inbound discount ticketing JR East has adopted a similar approach they use for Eki-Net Shinkansen eTickets: discount plans attached to plastic Suica cards. This is the whole purpose of the Welcome Suica + reference paper proving validity for inbound discount plan purchases at station kiosks. It would be great if JR East figures out a way to do the same thing on Mobile Suica.

Domestic discount ticketing and passes are still the glorious, mostly paper ticket mess that is Eki-Net and similar services. Eki-Net itself is still in a slow motion transition towards a Transit IC/Mobile Suica orbit with some things transitioning to QR paper ticketing that replaces expensive mag-strip paper. Eki-Net App is still limited to Shinkansen eTickets and ticketless express train seat purchases. The Eki-Net web site is where you access all the bells and whistles although the experience feels like navigating the Transit IC interoperability chart. Discounts are starting to change somewhat with Suica 2 in 1, totra is the first Suica for disabled users but exclusive to the totra fare region. Hopefully Extended Overlap will see wider use not only for Suica but across all Transit IC cards for more special, and interoperable, discount services.

What’s next for PiTaPa?

Now that Nankai Railway Visa Touch and QR Code transit tests have started (April 2), it’s helpful to take a look at Surutto Kansai, the association of Kansai area non-JR transit companies that issue and operate PiTaPa. I covered PiTaPa problems previously but in addition to the Nakai Visa Touch and QR tests, there have been a few other developments among PiTaPa group members:

  • Nankai Visa Touch and QR Code Transit: the Nakai, VISA Japan, SMBC and QUADRAC Co., Ltd venture started in April for Visa Touch and Nankai Digital Touch QR, QR tickets are purchased and used via the Nakai App and can only be purchased with Visa brand credit cards.
  • Osaka Metro ICOCA: Osaka Metro started selling ICOCA commuter passes and regular cards from November available at all station kiosks. They are the last major PiTaPa member to add ICOCA commuter passes, other major members (Keihan, Hankyu, Hanshin, etc.) added them years ago and have finally retired mag-strip commuter passes. One clarification regarding TOICA: it’s sold at Shin-Osaka station by JR West not Osaka Metro. An interesting aside is that when you use TOICA on Osaka Metro the system recognizes it as ICOCA. In a separate development Osaka Metro wants to implement face recognition transit gates for the 2025 Osaka Expo that dump cards altogether.
  • Keihan ICOCA: Started offering ICOCA Points at the end of 2020 (discount fares for repeat transits in the same month).

In the Transit IC card 2020 ranking by issue/holder numbers PiTaPa was 6th at 3.3 million cards with the slowest growth. It will likely drop to 7th place in 2021.

Suica, PASMO and ICOCA represent 90% of transit IC card issue

Nankai Open Loop Tests
As expected the Visa Touch and QR gates are limited to certain stations and exits. From the on-site media presentation pictures it’s clear that Nanaki is doing open loop transit gates the right way by keeping EMV/ QR only gates separate and off to the side wherever possible (bolt-on jobs are used in narrow areas). If there is one thing we have seen these past few years it’s that all-in-one gates with multi-protocol readers are slow and error prone. They just doesn’t work well for transit.

Target users are inbound travelers from Kansai International airport and plastic contactless Visa brand cards as it does not support Apple Pay Express Transit or similar services on Google Pay, Samsung Pay, etc. The inbound angle is a tough sell in the travel restricted COVID era now that Kansai area hotels are closing and laying off staff. A few interesting inbound points: Mainland China visitors use Union Pay not Visa, QR tickets have to be bought with a Visa card, and Nankai Digital Touch QR tickets are faster at the gate than Visa Touch because they are closed loop.

Fellow transit otaku in Osaka run loops around the Visa Touch open loop gate at Nankai Namba station
Nankai Digital Touch QR tickets are faster at the gate than Visa Touch because they are closed loop

Taken altogether it’s mayhem. As FeliCa Dude says in his tweet, Surutto Kansai is done for. The interesting thing is that PiTaPa is a very similar to the digital Opal Mastercard debit with specific merchants allowed scheme: a closed loop credit card account instead of the closed loop digital Opal Mastercard debit account. Where PiTaPa failed was that Surutto never provided a plain old prepaid transit card option so that users could buy a commuter or regular one for cash and recharge it at any station kiosk. Opal of course still sells the good old Opal MIFARE prepaid card and they would be smart to keep it around. There will always be a need for cash based transit cards.

Why can’t Surutto Kansai to come up with this simple solution for PiTaPa? In a word, SMBC bank group. They are behind the PiTaPa card creation, and now they are pushing Visa Touch transit. It’s an unfortunate and awkward situation: transit companies forced to issue and use an ‘outside’ transit card like ICOCA instead of their ‘in-house’ PiTaPa brand. I suspect the impasse will continue until SMBC gives in and let Surutto create a prepaid card and own the float, or the major Surutto Kansai members stage a real revolt. Until something gives Mobile PiTaPa will be impossible. The pressure to do something will only grow as the Mobile ICOCA 2023 launch approaches.

The Open Loop transit privacy question

In 2013 JR East faced a crisis over selling Suica ridership pattern data analysis to Hitachi. The Suica data was stripped of personal information and was used to analyze popular transit routes and create general user profiles based on age group, gender and so on. Media outcry resulted in JR East drafting an opt out data policy followed by Japanese Government laws and regulations covering personal data privacy.

That was then, this is now. Line, the popular messaging service plus Line Pay payment platform, came under attack this week for storing user and transaction record data outside of Japan, in South Korea and China. This is not a surprise since Line started in South Korea and storing data on cloud servers there was always an open secret. Why the brouhaha now? The recent complicated Z Holdings acquisition maneuvers of Line are a factor. With PayPay and Line Pay QR payment empires now in the same house some kind of streamlining is bound to happen. The data scandal could be a convenient excuse to start it.

The constant drip of privacy concerns regarding social networks and QR payment systems like Line Pay, and where user transaction data is stored, makes the old JR East crisis look small and silly. Everything is more connected now in unexpected ways than even just 8 years ago.

It doesn’t matter how secure transaction protocols are when user transaction record data is stored on leaky servers or sold to outsiders for profit. I wrote about this earlier, the so called popularity of QR Code payment services in Japan is really about big data. In that vein we have a timely blog post on Open Loop ltransit rider privacy from Transit Center.

For a professional advocacy organization dedicated ‘to improve public transit,’ the Transit Center privacy publication is surprisingly amateurish. It raises valid concerns but reads like open loop advertising from credit card companies (Transit Center soft sponsors?), where open loop is the golden cure-all future, and the only future at that, of every transit ill with closed loop invariably portrayed as a dead era of tokens, punchcards and mag strip swipe cards. They also make MTA seem like the only transit system in America that matters because idiosyncratic MTA problems apply everywhere. Right? Wrong. Let’s take a look at their privacy blog post…<<with comments>>.

Transit agencies around the country are adopting a new generation of fare payment systems. Agencies including New York’s MTA, Boston’s MBTA, and Houston METRO are in the process of switching to what’s known as “open-loop” systems that enable riders to tap into the system using digital wallets on their phones or with their credit cards…

<<more banks handling transit fare concessions sounds like a good idea for privacy, wait until the TC folks figure out that ‘closed loop’ bank card accounts for digital wallet OMNY is the next step in the game>>

These technologies come with clear benefits for riders, but they also carry the risk of exposing more personal data…

<<here it comes>>

The switch to these new fare payment technologies can accelerate access to riders’ trip data by other government agencies. In New York, for instance, individuals’ MTA trip data can be retrieved much faster with the new OMNY system than with the older MetroCard system…

<<retrieve trip data quickly on a fare system where users don’t tap out…what? privacy concerns are not just government agencies btw with multiple 3rd party companies handling and processing transit fare data…which brings us to>>

The increased involvement of third parties in fare payment underscores the need for better data collection and management policies within transit agencies.

<<better as in more big data details?>>

How to Implement the Next Generation of Fare Payment Without Shredding Riders’ Privacy

Anybody experienced in dealing with bank and card company customer service could see this coming. Bank and transit operating cultures are different and they don’t mix well with outside companies running the transit gate fare concession. If you think transit privacy is a concern now, wait until face recognition transit gates become the next transit future thing.

Let’s make this simple. Open Loop (EMV and QR) and bank card EMV Closed Loop means that banks and outside payment platforms run their services at the fare gates They have transit user data, as does the transit company, so does the fare system management subcontractor like Cubic. The more places data is stored the more it’s gonna leak. This is exactly what is playing out in Japan right now because Line Pay Japan user transaction data is stored in South Korea which does not, putting it mildly, have a good secure data reputation.

That doesn’t mean that closed loop is automatically more secure, but keeping data in-house with its own closed loop transaction card in the country of origin, as JR East does for Mobile Suica, does mean that outside company access is tightly controlled. At the very least there is only one company in the country of origin to take the blame when something leaks, and only one place to plug it.

Japan Cashless 2021: the Wireless Android NFC Reader Suck Index

You too can have the whole transaction world in your hands with the Android based Square Terminal for just ¥46,980

Now that contactless is everywhere, wireless contactless readers have become very fashionable and popular. Nobody wants wires or checkout lines. All of these systems are built around an Android based reading device connected to the internet payment service via Bluetooth, WiFi or 4G with a main terminal, an iPad or a laptop running payment network software. Convenient though they may be, compared with hard wired NFC reader performance they all suck with different levels of suckiness:

  1. stera: this lovely little ‘NFC antenna under the screen’ piece of shit from SMBC, GMO and Visa Japan is so slow that checkout staff put their hand over the stera screen/reader to keep customers waiting until the device is ready to go. This is followed by the instruction ‘don’t move your device until the reader beeps.’ It’s a 2~4 second wait until it beeps. This is 2014 era ‘you’re holding it wrong’ garbage nonsense. I teased one store manager about the hard wired JREM FeliCa readers that were swapped out with stera, “Those were too fast,” he said. Too fast?!
  2. PAYGATE: Another payment provider associated with GMO, slightly faster than stera but still slow, PAYGATE does’t like Apple Pay Suica•PASMO Express Transit very much. Have of the time it ignores it altogether forcing customers into the 2016 era ‘manually bring up Apple Pay Suica’ authenticate and pay maneuver. Another ‘you’re holding/doing it wrong,’ when the fault is on the checkout system side. Passé and totally unnecessary.
  3. AirPay: It’s weird that the cheap AirPay hardware performs better than PAYGATE or stera, it’s even weirder that AirPay performs better than Rakuten Pay which uses the very same reader but is stera shitshow slow.
  4. Square Terminal has gotten lots of media attention in Japan. Too early to experience it in the field yet but I’m not hopeful. Square Terminal is Android based after all and the NCF antenna under the screen design is the worst performing reader design out there. As one Brazilian reader wrote: “I just don’t like the ones running Android because at least here the software is less reliable and I managed to crash a few one by just taping my phone.”

Yep, that observation matches my experience. Payment network providers need better Android readers, the current crop is too slow getting the payment transaction ready to tap. In this era of endless subcontractor layers in the development process, creating a fast reliable Android based NFC wireless reader might be a tall order, if not impossible. The all over the place wireless NFC reader experience certainly doesn’t boast well for open loop advocates.

UPDATE
I ran across another crappy reader experience (above) and retweeted it. A reader had some questions about it, answered here by an anonymous expert. It basically comes down to poorly executed reader polling or not following Sony polling recommendations for FeliCa cards. This is what is happening in the above retweet. It is also what is going on with PAYGATE Station readers, half of the time the proper code hasn’t loaded correctly although this issue seems to be fixed in new PAYGATE Station checkout installations. Which brings us to the point I was trying to make: these performance issues can be fixed with reader firmware updates or transaction system software updates, but never are.

Wildcard polling involves the reader making a request for system code 0xFFFF and expecting the card/device to list all the system codes that it supports. Wildcard polling won’t work on an Apple Pay device in Express Transit mode – instead, the system code must be explicitly polled for (0x0003 for CJRC, 0x8008 for Octopus). You can cause Suica/Octopus to be automatically selected by sending SENSF_REQ (Polling command, 06) for those services explicitly.

I have verified that doing so with Apple Pay will cause the emulated card to be switched out as appropriate – the IDm value will also change, since Apple Pay emulates each card separately, instead of with a common IDm as with Osaifu Keitai. If you read the Sony documentation, you will see that developers are cautioned to also poll for the specific service codes they want to access if there’s no response to a wildcard poll.

Perhaps your reader doesn’t do this, but it’s fairly big omission…it should be doing explicit polling. Simply polling for service code 0x0003 should wake up Suica if selected as an Express Transit candidate, even if you don’t send any other commands. I’ve verified this with an RC-S380 reader and NFCPay.