The state of online payments is far from ideal, it’s full of glitches, gotchas and different kinds of authentication that don’t always work well. We all have experience with cards that inexplicably fail for online purchases and verification. 3DS authentication and Apple Pay were supposed to fix this but they have not. 3DS v1 was a bust, 3DS v2 that was supposed to fix everything does not, and Apple Pay is not universally accepted despite offering a far easier and more secure transaction. Even on the Apple Pay side there are rough spots. Wallet cards that should work for payment do not.
There are security and privacy concerns too. We’ve seen the rollout, rollback and re-rollout of Enhanced Fraud Prevention for in-app and web purchases with VISA issue cards without any idea of what it really does or what extra user data Apple is giving to VISA. In Japan we’ve also seen the long running VISA lockout saga of select in-app Apple Pay transactions for Apple Pay Suica, PASMO and ICOCA with non-Japan issue cards.
Apple Pay Code Payments for the rest of you
Fortunately iOS 18 is bringing some subtle but important improvements that will address some of these problems over time and extend Apple Pay web payments to any device with a browser using those nifty but seldom seen App Clip codes. Think of it as Apple Pay Code Payments. You might not know it but Apple Pay has been flirting with QR Code Payments since iOS 14 (code name Aquaman).
Aquaman never developed beyond the planning stage, but it shows how serious Apple was about the concept. We don’t know why Apple dropped it but I suspect it was the challenges of connecting web dependent QR technology with the on-device only NFC dependent embedded secure element technology. The context wasn’t right, or at least connecting QR in with the embedded secure element playing the central role that it does for all things Apple Pay didn’t make sense. In iOS 18 Apple seems to have finally found a way to deliver Apple Pay Code Payments in the right context: Apple Pay on the web on any non-Safari browser that is far more easier to use and authenticate than non-Apple Pay 3DS web transactions.
It’s very simple: hit the Apple Pay button, the browser device displays a unique App Clip-like payment code, scan the code with iPhone, the Apple Pay payment sheet appears, double click the side button to confirm with Face ID, and you’re done. It copies the same scan and pay experience of popular QR payment apps in China (AliPay), Japan (PayPay), etc., except for one big difference: Secure Intent hard linked secure element transactions. Apple Pay handles of all the security and transaction tokenization that QR Payment apps have to do on their own over the internet, leveraging highly secure on-device authenticated Apple Pay transactions. The important stuff happens on the iPhone but it’s also clever because web shopping on another device guarantees that iPhone has the same network connection which neatly avoids the bane of using QR payments apps in stores: a crappy network connection.
This is a big difference because as Noyes Payment Blog points out, banks want to provision cards on smartphones, not computers, and online merchants don’t like large purchases made on computers either. China doesn’t allow Apple Pay on the web for macOS, there is also the EU Secure Customer Authentication (SCA) requirement. Apple Pay is SCA compliant but 3DSv2 is sometimes not compliant as implementation is left up to the banks. Noyes (the only blogger in America who understands the significance of Apple Pay Code Payments) estimates that current Apple Pay web transaction share is about 3%, the slick Apple Pay Code Payment strategy could grow that transaction share to 20% in 3 years. That’s a lot of growth. Going forward I think we’ll see more developments with Apple Pay Code Payments.
Merchant Category Code Support
This small background change can pay big user feedback dividends with in-app and web purchases. Think of it working hand in hand with Apple Pay Code Payments. Going back to the VISA block of non-JP cards issue, users see an Apple Pay payment sheet listing ‘Available’ VISA payment cards that are in reality not available for the purchase at hand. The end result is a payment incomplete error. This is a big problem with Apple Pay, it only shows static card information: it doesn’t update and provide real-time user feedback when a payment card won’t work for a particular web or in-app transaction. If the payment card shows as Available, it should work. When it doesn’t it breaks user trust in the system. The issue boils down to the way merchants, acquirers and issuers communicate merchant information in the transaction chain and how that relates to the card account.
iOS 18 merchant category support can help fix this problem by improving communication flow along the entire Apple Pay transaction chain that provides real-time feedback in the Apple Pay payment sheet, showing exactly which payment cards are valid for the payment at hand. The fewer unexplained ‘payment not complete’ errors, the better the user experience.
Improved Apple VAS experience
Apple VAS (Value Added Service) is the forever under-delivered promise of NFC that attempts to do everything beyond payments from smart reading (using Apple Enhanced Contactless Polling) for smart delivery of rewards, event ticketing, passes, etc. Scanning QR codes may not be sexy or fast, but they deliver cheap mobile pass action that pricy Apple VAS and Google Smart Tap have not. There are practical ways to improve the NFC user experience that leverage what’s already in place, like background tag reads, instead of waiting for NFC Forum fairy dust. Fortunately improved Event tickets are the former: they are not gaining any NFC functionality but they will be more useful in iOS 18 with enhanced detailed event information, map and local weather integration, and more.
Goodbye Apple Pay Later, hello card issuer buy now pay later
Immediately after WWDC24, Apple killed the iOS 17 Apple Pay Later feature in favor of iOS 18 “installment loan offerings from eligible credit and debit cards” for in-app and web purchases, aka good old buy now pay later from your local bank. Apple is giving issuers the options to offer what they want to offer in the Apple Pay payment sheet instead of being straitjacketed by Apple. The “ability to redeem rewards for a purchase with Apple Pay” seems like the same deal. It’s not an Apple VAS reward card transaction, it’s a regular Apple Pay transaction handled by the card issuer. An option they and their service partners control, a concession to soften banking industry criticism of “Apple Pay is a monopoly”. I sure hope this doesn’t mean we’ll eventually be seeing in-Wallet bank loan and reward point bonus ads.
Tap to Provision for EMV cards
Tap to provision has been around since 2016 as a central feature of the Apple Pay Suica launch. It’s the basic method for users to transfer plastic transit card to Wallet. This feature is finally coming to EMV cards and is long overdue even though iOS 17 Multi-device provisioning is way more useful: tap to provision is usually one-time thing but multi-device provisioning takes care of shuffling cards between devices.
Tap to Cash
People have been pining for NFC Peer to Peer mode (P2P) transactions on iOS ever since iPhone 6. Is Tap to Cash the P2P nirvana they seek? Are you kidding, this is Apple after all. It’s an exclusive private API feature for Apple Cash users (Green Bank VISA Debit), just like the private dynamic card art stuff for Apple Card (Goldman Sachs Mastercard). Nobody else will get it…ever.
Hands-free unlock
This is an extension of the Express Mode UWB (Ultra Wideband) chip service that first appeared with Car Key, now available with iOS 18 Wallet Home Key. Keep iPhone in your pocket and your home door unlocks as you walk up to it. I keep hoping for hands-free transit gates, much better than awful face ID transit gates if you ask me. But it will probably never happen.
Tap to Present ID on iPhone in Japan
There wasn’t much movement with IDs in Apple Wallet in the iOS 17 cycle. People complain but the reality is that government programs move at their own pace. The rush, rush pre-WWDC 24 announcement of the Japanese ID card for Apple Wallet came as a surprise. Coming late in the iOS 18 cycle (iOS 18.5?), the Japanese Digital My Number ID card will land in Wallet after long and winding negotiations, and I expect longer preparations than anticipated. There are a bunch of new PassKit framework calls just for My Number ID though some people point out the syntax is basic enough to, possibly, implement other national digital ID cards. The Japanese government has been pushing My Number ID as a kind of solution for every digital security problem, which is a little scary. Even if My Number for Apple Wallet launches on target, I think it will take a lot of time before iPhone users will trust it enough to really use it, barring government promoted ‘incentives’.
That wraps it up for iOS 18 Wallet. Have fun kids. Oh, and what about Apple HCE? To quote Steve Jobs at his best: What about it? Seriously though, to paraphrase Noyles again, why use HCE when users end up with a less secure, less integrated experience? Apple Pay is the go to user experience for iPhone users. If you want to go cheap and easy, go with QR but as iOS 18 Apple Pay Code Payments make clear, Apple does the code scan thing way better too. Using Apple Pay instead of HCE is a business 101 no brainer because once people are on board with it, they use it…a lot.
We’ll see how it turns out this fall. Until then have a good summer and thanks for taking the time to read this blog.
You must be logged in to post a comment.