Category: Apple Wallet

VISA blocking foreign issue cards for select Japanese in-app and online payments

Notice: latest VISA situation update here

SoftBank Payments network chart

When foreign issue VISA cards in Wallet stopped working for Apple Pay In-App Suica and PASMO recharge on August 5, the first people to howl in pain were Apple Pay PASMO users who suddenly couldn’t recharge with their Chase Sapphire VISA cards. Chase Sapphire users earned 3x travel points with a PASMO recharge, long time resident Suica users migrated to PASMO when JR East and VISA shut down 3x travel points in May 2021 when VISA finally signed with Apple Pay in Japan.

After confirming that my Wells Fargo Signature VISA stopped working for Apple Pay Suica recharge, I contacted Mobile Suica support. The official line: “There should be no problem with foreign issue cards, contact the card issuer.” My next stop was Wells Fargo card services support, official line: “There should be no problem with your VISA, contact the merchant.” Entirely expected of course but Wells Fargo confirm that Mobile Suica transaction attempts were not even showing on the Wells Fago system. They said it seems to be a ‘communications issue’ which meant something is not right on the VISA payment network merchant transaction authorization side. Everything was stopping there.

An Android Suica user confirmed the same non-JP VISA problem with Google Pay Suica recharge so it was larger issue than just Apple Pay. I contacted IT journalist Junya Suzuki who focuses on mobile payments. His first thought was something was going on with the VISA Japan payment network merchant acquirer side. For reference, the merchant acquirer handles transaction authorization from the merchant side, ‘this transaction is clear to send to the card issuer.’ The issuer then clears the transaction with the customer account, ‘this customer is good to pay for this charge.’

Merchant acquirer relations are very secretive, nobody knows who is the merchant acquirer is for Mobile Suica, Mobile PASMO and Mobile ICOCA though everybody is pretty sure it is the SMBC Group who are the banking group for all things VISA in Japan. Maybe they were tightening online transaction security…or something else. Suzuki san checked his sources and had this to say:

An acquirer made the decision stopping handling cards issued in other countries…In addition, that means JRE doesn’t know what’s happening on this problem.

In a his Japanese article he described JR East as a ‘victim’ of a situation forced by VISA, their hands are clearly tied. VISA payment network and their merchant acquirer are highly selective. For example: foreign issue VISA works fine for Apple Pay in-app purchases with the Starsbucks app, but not in-app purchase with JR East for Suica recharge. If foreign VISA cards were insecure, VISA would be stopping all In-App and online transactions, but they are not. This means the ‘security concerns’ excuse doesn’t wash, it’s a ruse for something else.

Security and Apple Pay Enhanced Fraud Prevention
It’s helpful to examine the impact of phishing and other security attacks targeting NTT Docomo, Line Pay, PayPay and other QR code mobile payment service users in late 2020, and JR East online service users (Mobile Suica, JRE POINT, Eki-Net and VIEW card) in early 2022. Security responses were varied and vague. Companies like to say they value customer security but hardly provide details of what they’re doing about it. Security details hashed out between the card brands, merchant acquirers and merchants are secret non-disclosure territory.

Japanese credit card issuers responded by upgrading to EMV 3-D Secure v2 (3-D stands for three domains: the merchant acquirer domain, the issuer domain, and the interoperability domain), for non-digital wallet browser and mobile app payments. EMV 3-D Secure is the EMV e-commerce browser and app authentication tokenization specification with the card brands using their own naming and implementing merchant support in their respective payment networks.

In addition to adding 3-D Secure v2 in their Mobile Suica and Eki-Net apps, JR East has beefed up security to fight Mobile Suica phishing attacks with tighter monitoring of Suica App recharge with the app registered credit card…not Wallet In-App recharge. It’s important to understand this key point:

  • 3-D Secure has nothing to do with Apple Pay and Google Pay, they and all other digital wallets like Samsung Pay, Huawei Pay, etc., do not use it. They have their own tokenization scheme. This is a common online misconception. Japanese issue VISA (and everything else), foreign issue Mastercard and Amex cards work for Apple Pay Suica • PASMO • ICOCA recharge without problems, without 3-D Secure.

Domestic security issues do not apply to inbound visitors adding and using Suica cards in Apple Wallet. They do not use Suica App or have a Mobile Suica account. And yet VISA seems to be using domestic security problems to block foreign issue cards for Apple Pay In-App recharge.

JR East is fighting phishing attacks with stricter Suica App registered credit card use monitoring. Suspicious can lead to Suica being locked by JR East for credit card recharge but cash recharge is always available.

The tokenization that Apple Pay, Google Pay, Samsung Pay and similar digital wallets use is highly secure, some say more secure than EMV 3-D Secure tokenization. Despite this, Apple has been making some changes to Apple Pay to enhance security for online and in-app purchases, at the behest of VISA. Apple Pay quietly launched Enhanced Fraud Protection in April 2022 when Apple Cash switched from Discover to VISA. The updated Apple Pay and Privacy text added a new section:

For cards with certain enhanced fraud prevention, when you attempt an online or in-app transaction, your device will evaluate information about your Apple ID, device, and location if you have enabled Location Services for Wallet, in order to develop on-device fraud prevention assessments. The output of the on-device fraud prevention assessments, but not the underlying data, will be sent to Apple and combined with information Apple knows about your device and account to develop Apple Pay transaction fraud prevention assessments. These transaction fraud prevention assessments may be shared with your payment network, together with a shipping address identifier and IP address if available, in order to prevent fraud at the time of transaction. The shipping address identifier differs per payment network and may be used to confirm whether shipping addresses for different transactions using a particular card on your device are the same in a way that does not reveal the underlying address. You can check whether a card has this enhanced fraud prevention at any time by going to the back of your payment credential in Wallet. To prevent the sharing of fraud prevention assessments with your payment network, you can select another card.

Apple Pay & Privacy

This means that Apple Pay ‘might’ share iPhone/Apple Watch location information when making online or in-app purchases. So far VISA cards are the only ones that have Enhanced Fraud Protection but it doesn’t seem to apply to all VISA issue cards and it’s hard to tell which VISA cards use it.

Does enhanced fraud prevention have anything to do with Apple Pay Suica and PASMO recharge not working for foreign issue VISA? The short answer is no, but it’s a background development to be aware of because: 1) it’s limited to online and in-app purchases, 2) VISA is pushing for ‘fraud prevention assessments’ so they could obtain device location information and more. Only after VISA started pushing this agenda did we start having recharge issues with Apple Pay In-App payments.

The VISA open loop power play
So we circle back to foreign issue VISA use in Japan again. Why are cards cleared for Apple Pay, cards that worked fine up until August, not working? The timing is perfect when you also consider that VISA is heavily promoting ‘VISA Touch’ EMV contactless and open loop transit in Japan as a challenge to the home grown FeliCa based Transit IC card system. It’s very convenient for VISA Touch open loop marketing purposes when Apple Pay Suica and PASMO are kneecapped as easy payment and transit options for inbound visitors.

VISA has a history of not playing nice with Japanese stored value cards on mobile and not playing nice with Apple Pay. Japanese issue VISA cards didn’t work for Apple Pay in-app purchases and Suica recharge until May 2021, VISA waited 5 years to ‘resolve’ that issue. VISA cards still do not work with Mobile WAON and Mobile nanaco on Android and Apple Pay, they likely never will. My take is that VISA is not happy with people using VISA cards like an ATM to move money into stored value prepaid cards for making payments, earning points, etc., that are not VISA.

VISA has played hardball with Apple Pay in the Japanese market before, they are doing so again. Perhaps they refuse to be an ATM-like recharge backend for Japanese e-money cards…unless they also get ATM-like lending rate transaction fees. They certainly will use the opportunity to promote open loop VISA Touch and Stera Transit at the expense of Mobile Suica market and mindshare. The real question: is VISA making their own market opportunity here? I say they are not playing fair, as monopolies often do.

Examining VISA’s moves in the Japanese market proves one thing: payment network issues are never simple or solved quickly because they often come down to market politics. VISA has never played nice with Apple Pay in Japan since the very beginning, they continue to do so. At the very least we can mark this down as another skirmish in the ongoing digital payment turf wars.

This post was originally posted 2022-08-08 and has been updated to reflect a changing situation. The post date reflects the latest major update.

Non-JP VISA cards cannot be used for select Apple Pay In-App payments for Mobile Suica, Mobile PASMO, Mobile ICOCA and Apple Pay online payments for Universal Studio Japan advance tickets.

A warning sign for Japanese open loop transit operators: when the EMV payment network goes down, FeliCa networks keep working

Mobile Suica has had a rough 2 weeks. On June 24 a construction error during server center power supply expansion work left JR East Mobile Suica and Eki-Net online reservation services offline for 12 hours (0:00~12:00). It was an embarrassing mishap but the actual damage was small, limited to refunding Eki-Net ticket holders who couldn’t change ticket reservations. Mobile Suica was offline so no refunding was necessary because nobody could use the Mobile Suica credit card recharge service. No need to refund what people can’t buy.

A shorter but much more problematic outage happened on June 27. Media mistakenly reported that Mobile Suica was down but this was not the case as Mobile Suica on Android was working just fine. It was an Apple Pay problem: Apple Pay servers went down from heavy demand on Apple Pay ICOCA launch day, taking down not only Apple Pay Suica recharge but also PASMO, ICOCA, nanaco, WAON, Octopus, China T-Union, adding credit cards and other Wallet services worldwide. As the outage took place during the Japanese business day, JR East had to refund iOS Suica App users who attempted to buy or use Suica Green Car tickets during the Apple Pay outage.

Just as things were settling down, another even shorter 40 minute period of trouble occurred on July 8 at 12:00~12:40 JST. Again the media reported that Mobile Suica was down, again they were mistaken, and again it wasn’t an JR East or Mobile Suica problem, it was a much wider, and unreported, EMV credit card payment network outage. EMV transactions on readers everywhere were not responding, and they were not working for Apple Pay or Google Pay. However FeliCa payment network cards were working.

And finally there was, yet another, Apple Pay and Wallet outage on July 14 from 17:45 to 18:30 JST, with another round of Japanese media bashing poor old Mobile Suica without checking for the wider Apple Pay outage.

Mobile Suica caught the media blame because they were the only company duly reporting the problems on Mobile Suica support SNS services. JR East never lays an outage blame on Apple Pay, or any other service partner because they know Mobile Suica users don’t care, they only want to know when things are not working and when they will be fixed. This is the way it should be done because they are giving their users fast, accurate, service information…even if that means they have to take the media and SNS blame that comes with it.

But despite all the Mobile Suica outages including the EMV payment network one, the Suica card itself always remained working, both digital or plastic versions. As long as there is money on the card it works for transit and payments, and cash recharge is available 24/7. This is an under appreciated but very important aspect of the Transit IC system: there is always a non-network fail safe cash backup. Japanese never put all their household finances in one basket, cash is always the one thing that works after an earthquake, typhoon, natural or manmade infrastructure damaging disaster strikes.

In the EMV credit card payment network outage there was, without doubt, unreported trouble with open loop system test deployments on Nankai, Fukuoka Metro and other QUADRAC • stera transit operated systems, which all open loop systems in Japan use: it’s the only open loop player in town.

Unlike Mobile Suica however, when the credit card payment processing network goes down, open loop doesn’t have a fail safe cash backup. And while that’s not a problem now with small installation test sites and a tiny user base, it will be when open loop goes big time. The transit companies deploying open loop have an obligation to take care of their customers, but will they take JR East-like responsibility when QUADRAC goes down, or stera goes down, or NTT Data CAFIS, payment processing centers, or mobile carrier networks? Because believe me they will. All highly connected, interdependent networks do. That’s why we always need alternative methods and networks. Too bad that VISA is working to remove the non-EMV transit gate competition in Japan.

Secrets of iOS 17 Apple Wallet: laying a foundation for open NFC

Now that WWDC23 has come and gone, it’s time to take stock of what’s changed, and what’s not, for all things iOS 17 Apple Pay and Wallet. On the surface nothing much appears to have changed. Despite some lame last minute Wallet predictions from Mark Gurman, nothing much has changed in the iOS 17 Wallet UI, only a few modest tweaks for the iOS 17 life cycle. But just like iOS 15 Wallet, the fun stuff that tells us what’s happening and how it will play out over the digital wallet landscape in the years to come is hiding below the surface.

One of the things nobody has noticed or pointed out is the interesting connection with the iOS 17 compatible device list and the embedded secure element (eSE). Let’s take a look.

iOS 17 clears out the last of what I call embedded secure element v1 iPhone models, iPhone 8 and iPhone X, that do not support Power Reserve. The importance of Power Reserve eSE v2 cannot be overstated: eSE v2 handles Apple Pay transaction process completely independent of iOS. This is why iOS can power down into power reserve mode and let eSE v2 continue to handle Express Mode transactions. iOS 17 code no longer has to babysit the whole Apple Pay and Secure Element transaction process that previous iOS versions had to do for eSE v1 iPhones.

The Power Reserve ready eSE v2 iPhone list

With these legacy devices cleared out, we are left with eSE v2 iPhone models. What can iOS 17 do without all that legacy eSE v1 support cruft? A lot evidently, the old 16 Wallet card limit is gone, blown to bits. The sky is the limit, actually the eSE memory is the limit and that’s a lot because iOS 17 beta 1 users are adding way more than 16 Wallet cards, even more than 40. Card and payments ‘otaku‘ in Japan are rejoicing of course but why is Apple doing this? What’s the point?

Wallet needs secure element space obviously because Apple’s long term strategy has lined up big end user services encompassing payment cards, transit cards, digital keys for home, office and hotels, driver’s licenses and eventually all kinds of IDs including passports. Apple has also lined up merchant side services: Tap to Pay on iPhone, and now Tap to Present ID on iPhone. More on those in a bit. All of these services need eSE space. But there’s more: when iOS 17 beta 1 eSE memory becomes full and the user tries to add a new card, Wallet presents a new screen that displays a list of installed cards, how much memory they consume and the option to swipe delete cards:

From Twitter user @RayistaW: “iOS17 eliminates the fixed maximum number of cards. As long as the eSE has enough space, you can add unlimited cards. Moreover, after it is filled up, it will prompt the space required when adding a card and the space occupied by each card. Cards that fail to be added due to lack of space will be displayed when they are added next time.”
Twitter user sk32751ibj posted screenshots of the iOS 17.0 error screen when attempting to add a Wallets card when the iPhone Secure Element is full. 39 Wallet cards in this case. It’s interesting that multiple FeliCa cards are grouped as one big virtual card, likely the same if the user has multiple VISA cards, etc.

If people are looking for evidence that Apple is preparing iOS for EU regulatory purgatory, this is it. Letting customers deal with an overcrowded eSE instead of iOS taking care of everything is…very un-Apple like. Let’s face it, who the heck knows or cares what a Secure Element is?

Apple has cleared the eSE deck for mandated ‘open NFC’ (which really means open eSE) regulation. Apple has an iOS that no longer has to manage and police eSE transactions, if so forced iOS 17 can step aside. Side loaded apps and similar can load whatever eSE applets they want and do their own thing. If they stomp on somebody else’s eSE applets and create mayhem at the payment terminal, well that’s the price of government regulations that remove Apple as eSE gatekeeper. Let users deal with the mess of managing which cards can be safely loaded into the eSE. Dear EU iPhone user…welcome to the Android NFC experience.

As for business as usual, iOS 17 Wallet has a few nice tweaks, the most important of which is multi-device provisioning. All the other ‘new’ features simply build off of what’s already there and are currently limited to the USA only Apple Card and Apple Cash. Multi-device provisioning is for everybody and will make life much easier. One of the easiest ways to see it in action is that Wallet Previous Cards will display any cards that are on one device but not the other. In the above example I have transit cards (Suica, PASMO) and e-Money card (WAON) on Apple Watch but not on iPhone. This is because stored value cards that keep the value on the card itself can only exist on a single device.

This has been caused a lot of confusion over the years for Apple Pay Suica users who assume that all cards work like a credit card. It also caused panic when users upgraded to a new iPhone. Pre-iOS 17 Setup Assistant would only transfer credit cards to the new iPhone but not Suica and similar cards. Thanks to iOS 17 multi-device provisioning, iOS 17 Setup Assistant seamlessly moves everything, credit cards, transit cards, keys, ID, *everything* so that you don’t have to.

Features like multi-device provisioning that make Apple Pay and Wallet so easy to use, are very hard to do. It is the greater sum of the parts that will keep customers, and developers too, choosing to stay with Apple as gatekeeper no matter how many rules the EU masters dictate.

Tap to Pay and Tap to Present ID are merchant targeted business services that showcase Apple’s integrated Wallet ecosystem built on the embedded secure element and secure enclave

The greater sum of parts will keep growing. Tap to Present ID showcases how Apple continually builds and integrates new services into a compelling whole. A slow burn focus thing. First we got ID in Wallet that was almost useless: Present your license or ID at a TSA checkpoint (do they really exist?). The first real use case arrived with iOS 16 ‘Share your license or ID in an app’ for in-app ID verification. And now we have iOS 17 Tap to Present ID which can transform any iOS 17 eSE v2 iPhone into a cheap payment and ID verification terminal. This combo has a lot of potential, if government ID issuing agencies get their act together, and other government agencies don’t get in the way.

Take Japan’s My Number ID (Individual Number Card) for example. The digital version finally launched on Android in May, after significant delays, but there are significant problems with the whole My Number ID card system. At the same time a different branch of the Japanese government wants to mandate open app stores. When Tim Cook met up with Japanese Prime Minister Kishida at the end of Apple’s Japanese charm offensive tour this past December, Tim gently waffled on committing to support My Number ID in Wallet due to unspecified ‘privacy concerns’. As in ‘you can forgot about privacy, security and My Number ID in Wallet if your government mandates side loading apps’.

Unveiling Tap to Present ID on iPhone now, well before the service actually launches ‘later this year’, works as a defense strategy against such government attempts to recklessly remove Apple as gatekeeper of their own devices. iPhone customers won’t trust using a digital ID unless they can be assured that Apple is playing gatekeeper. No Apple gatekeeper, no digital ID for the rest of us, it’s that simple. It all comes down to privacy and trust.

Mobile payments don’t solve the wallet mess, they only make it worse

Ha, ha, thanks to the proliferation of code payment apps with coupons, checkout takes longer than ever.

Way back when Tim Cook first unveiled Apple Pay, the main sales point was the convenience of doing away with messy wallets. My mom’s wallet for example was always stuffed full of credit cards, point cards and the latest store discount coupons clipped out of newspapers and flyers. The promise of Apple Pay was, “look ma, no more messy wallet.” Except it didn’t work out that way.

The rise of code payment point economic zone like PayPay, dPoint and Rakuten Point has resulted in mobile payments that take longer than mom’s messy wallet ever did. I was reminded of this recently getting lunch at Doutor Coffee. A youngish woman paying in front of me wasn’t really paying. With smartphone flat on the counter, lavishly nailed fingers leisurely tapped away for 5 full minutes as she completely ignored the cashier waiting to read the QR code, everybody else waiting in line be damned. Instead of getting read to pay she was signing up for some pissy small payment app discount coupon. And when that was done she finally paid with a QR code for a cup of hot cocoa, face full of discontent. Or maybe that was her normal character.

You see that kind of checkout line behavior everywhere in Japan these days: half losing oneself digging around in an app to find a coupon or campaign special, half ‘screw you’ that often skirts on taking pleasure from somebody else’s pain. People literally loose themselves in the moment.

Who’s to blame for this state of affairs? QR Code payment apps that offer all kinds of coupons certainly deserve some of the blame, along with crappy in-store wifi, or lack thereof. Apple Pay deserves some blame too. Let’s face it, Apple Value Added Service (VAS) NFC protocol has been abysmal failure in the Japan market despite dPOINT and PONTA support. And who’s the biggest culprit of all? All of us of course…all of us who actually believed that technology could fix human behavior. In short this issue isn’t going to be fixed. All we can do is remember to chill, pay attention to our surroundings and be polite in the checkout line.

mobile myki madness

If I had an Australian dollar for every online complaint of Mobile myki, the mobile version of Public Transport Victoria’s (PTV) myki transit card in the Melbourne region, I could probably purchase a nice bit of property there. Reddit forums regularly erupt with mobile myki mind melting nonsense, invariably bashing Apple for refusing to put myki in Apple Pay because Apple ‘doesn’t support HCE’ or because they charge a ‘30% commission’. Neither of them true. myki is MIFARE which has never used HCE and Apple Wallet already supports lots of MIFARE transit cards.

The whole HCE thing is a straw man anyway: embedded secure elements (eSE) are standard on NFC smartphone chips these days. The reason why Île-de-France Mobilités (IDFM) chose HCE for Smart Navigo on Android for example, had nothing to do with Android devices lacking an eSE, it was simply that IDFM didn’t want to deal with Android manufacturer ‘gatekeepers’. Imagine the nightmare of asking every Android manufacture to issue firmware updates for older devices to support Calypso on the eSE. There was no chance in hell they would listen or do it for free, so IDFM and Calypso spent a lot of time and money creating a special HCE version of Calypso, that doesn’t support Express Transit Mode, just for Android (but not for Samsung Pay devices which use native eSE and support Express Transit Mode).

Why IDFM and Calyspso did this is all you need to know about the chaotic mess that is Android NFC. When Smart Navigo comes to Apple Wallet later this year, it will run on iPhone 8/Apple Watch 3 and later without a hitch in full Express Transit Mode glory because firmware, eSE and software are upgraded in a single iOS update. That’s the advantage of having a good gatekeeper who’s on the job.

As for the 30% commission straw man, Apple Pay doesn’t ‘charge a commission’ for using transit cards, they only take a negotiated commission when a credit card is used to add money to the transit card. Why PTV and Apple haven’t reached an agreement yet is a mystery, but judging from myki user complaints, the mobile myki backend system might not be up to Apple’s user experience high-bar. And the myki system is about to get much more complicated: PTV is hitting the reset button.

Open loop envy
PTV has Opal open loop envy and want EMV contactless cards to replace most of myki. This is certainly doable but there is the issue of the native MIFARE myki already on mobile. Oyster and Opal cards are MIFARE too but those systems added EMV contactless support as the foundation for ‘mobile’, relegating MIFARE as legacy plastic. By doing this they offloaded the card issuing operation to VISA/Mastercard/AMEX card issuers, who already have digital card systems in place and agreements with digital wallet operators. myki having come this far with mobile however is going to be a real juggling act, can PVT, or whoever wins the service contract, keep all the service balls in the air while going forward?

There is also the problem of Express Transit Mode support. Look carefully at Apple Express Transit Mode small print and you’ll notice that mobile EMV and mobile MIFARE transit card Express Transit Mode don’t coexist on the same system. It’s one or the other, never both. I suspect a smart Express Mode that chooses the right transit card for the job depends on smart modern transit gate reader hardware with the latest firmware and updated backend software. Getting the latest, greatest transit gates/readers installed takes time and money. Mostly money. Buckle up myki users, it’s going to be a bumpy ride to mobile transit card nirvana.

Apple Wallet Express Transit Mode is basically limited to native transit cards