If you use JR East regularly a BIC CAMERA VIEW card is the best investment you can make. So I was pleasantly surprised when the Crecolle (credit-kore) site posted a very useful piece about using Bic Camera VIEW card and Apple Pay. I love it when Japanese credit card sites analyze every reward point possibility in detail. The deep dives are always surprisingly useful.
BIC CAMERA VIEW is a dual function card that grafts a VIEW credit card with a Suica. The Suica part works just like any plastic Suica. The only difference is that users can setup the VIEW card part to auto-charge the Suica part at a VIEW kiosk, they can also setup the VIEW to auto-charge a completely separate plastic Suica, very handy. BIC CAMERA VIEW is also a BIC CAMERA store point card. When you add it to Apple Pay only the credit card function is added as QUICPay. The card comes in VISA and JCB credit flavors, mine is JCB so I can recharge my Wallet Suica with Apple Pay.
To test BIC CAMERA POINT reward rates, the Crecolle staff ran 4 purchase patterns with the same battery item:
Apple Pay BIC CAMERA VIEW QUICPay
Apple Pay BIC CAMERA VIEW QUICPay + showing the plastic card for BIC CAMERA reward points
BIC CAMERA VIEW (plastic credit)
BIC CAMERA VIEW (plastic Suica)
The return rates printed on the receipts showed the following:
1% BIC CAMERA POINTS
8% BIC CAMERA POINTS
10.5% BIC CAMERA POINTS
11.5% BIC CAMERA POINTS
So the lesson here is that if you want maximum points when buying at BIC CAMERA, use the plastic VIEW Suica. Why the big differences? The 8% vs 10% difference is the Apple Pay margin. The #1 and #2 difference between Apple Pay VIEW QUICPay by itself and showing the plastic card is simply that the BIC CAMERA point card is not hosted on Apple Pay as a NFC VAS rewards card. If it was you could do what you do at LAWSON: say ‘Apple Pay’ so that the purchase amount is rewarded via NFC VAS to a dPOINT card or PONTA card in Wallet. The #3 and #4 difference is the benefit of using Suica SF and the JR East Suica float in action bypassing the credit card companies. This last difference is the same force driving endless QR Code payment app campaigns, QR players bypass credit card network margins and pass the benefits to customers.
There is one pattern the Crecolle staff did not test: Apple Pay BIC CAMERA QUICPay and showing the BIC CAMERA App barcode point card, this gives the same 8% but without showing any plastic.
It’s that time of year again, to ponder the mysteries of Apple Pay, Wallet, PassKit and Core NFC in the next major iOS release. I wasn’t planning a list this year because all the things covered last year: UWB Touchless CarKey, QR Code Payments, etc., are still lurking in PassKit calls and internal beta test builds and have yet to see the light of day. And then there is App Clips, a solution that finally leverages the versatility of NFC tags and iPhone NFC with reader mode was the big WWDC20 story, but it didn’t come into focus either. Too many COVID distractions.
No, no, the only thing that mattered to users and developers was this: when will Apple do something about the Face ID with face mask problem? The eagerly awaited iOS 14.5 Unlock with Apple Watch feature will almost certainly be the most popular feature of iOS 15 too. There are some interesting new PassKit tidbits in iOS 14.5: PKRadioTechnology type properties for NFC and bluetooth, the later for UWB Touchless use. This is the same pattern we saw at the end of the iOS 13 cycle with PassKit Secure Element Pass references replacing NFC Certificate Pass.
So what’s on the slab for all things WWDC21 iOS 15 Apple Pay? I have no idea. UWB Touchless and QR payment support lurking in the background might see the light of day, App Clips might get some refinements. Nothing really new. So I asked readers what they wanted for iOS 15 Apple Pay and the answer was clear: a Wallet app reboot. I didn’t think much about it until I saw the list of China T-Union add card Wallet options for mainland China.
Wallet has a very simple rule: any card that loads a Java Card applet into the secure element has to reside in Wallet, the maximum number depends on how many Java Card applets it can hold at any one time. Any card or developer that wants to loads applets and use the secure element also has to have a PassKit NFC/Secure Element Certificate Pass. This is covered by NDA but a company called PassKit (not Apple) gives us an idea what Apple’s NFC/Secure Element Pass guidelines are:
Apple care a great deal about the user experience. Before granting NFC certificate access they will ensure that you have the necessary hardware, software and capabilities to develop or deploy an ecosystem that is going to deliver an experience consistent with their guidelines.
Yeah, the end to end user experience, the whole reason behind the success of Apple Pay. But the Apple Pay user experience has seriously declined in the Face ID with face mask era. The current Wallet with its card metaphor has reached a wall, stuffing digital ID and Code Payments into the mix along with non-secure element Wallet tickets, boarding passes and reward cards, all using same old card UI, will only break the user experience on top of the Face ID with face mask inflicted damage.
Even if Apple doesn’t add new functions to iOS 15 Apple Pay, they must lay groundwork for a new, flexible and far more useful next generation Wallet app, for adding, storing, configuring and most of all, using an even growing collection of payment cards, transit cards, CarKey, reward cards, passes and digital ID items. Anything to save us from the cacophony of payment services, apps and reward goodies chasing our money and slowing us down at checkout with finding, unlocking, displaying a reward code (if the WiFi connection is good, heaven help those waiting in line when it’s bad) and finally paying. Whew.
The whole point of Apple Pay Wallet was to free us from physical card clutter. After 7 years of Apple Pay and payment apps we have digital clutter that’s almost worse than the original problem that digital wallets and smartphones were supposed to free us from. Let’s get our eyeballs and attention spans back.
UPDATE March 16: The PRESTO UP Tickets and Fares page now lists EMVExpress Transit support, but no mention of any similar benefits using Google Pay. The Apple Pay Transit support page does not list Express Transit for Canada yet, but the last update was February 3. The PRESTO page also mentions an interesting iPhone issue: “Some iPhone models (8 and earlier), may experience an error message when tapped on a PRESTO device. If you tap with an older Apple device and see a message saying that multiple cards were detected, simply tap your device again and the PRESTO device should accept your tap.” Sounds like a pilot program for teething open loop use issues. No mention of a digital PRESTO card of course. I suspect that when it comes (much later), it will be a closed loop debit card like Apple Pay Ventra.
Apple did a similar Express Transit deal for NYC OMNY, which was basically a very long pilot program and gradual rollout. PRESTO UP is also a pilot program but has an advantage over OMNY in that the PRESTO contactless transit card has been in service since 2009. People are used to it, only the smartphone wallet aspect is new. Meanwhile OMNY is still nursing off the ancient mag-strip swiping MTA Metrocard without a replacement. It will be interesting to hear customer feedback regarding the PRESTO EMV Express Transit experience…for real.
The Metrolinx PRESTO UP service started an open loop contactless payment pilot program this past week. It’s the first step for open loop support across the entire PRESTO fare system. The coverage on MacRumors and elsewhere, and the PRESTOcard youtube video itself makes it look like PRESTO already supports Apple Pay Express Transit when it apparently does not. Apple is very picky when it comes to certifying which open loop transit systems support EMV Apple Pay Express Transit. There aren’t any in Canada. The U.S. has three: NYC OMNY, Chicago Ventra and Portland HOP.
Unfortunately the PRESTO video uses post-production tricks to fake Apple Pay Express Transit. There are three instances: the 1:14 PRESTO reader, the 1:30 onboard verification check, and the 2:16 PRESTO reader. Each of these require a Face ID without mask or passcode Apple Pay authorization. As a reader pointed out the post-production folks neglected to fix the Apple Pay passcode request screen to match the reader ‘Accepted’ screen. Metrolinx promoting PRESTO open loop rollout so people will use it is one thing, but deception isn’t doing users, or PRESTO, any favor.
It was just a year ago when iOS 13.5 introduced a small Face ID UI tweak that bypassed Face ID and went straight to the passcode entry screen but over time I did not find it very useful. Face ID took longer and longer to bring up the passcode entry screen, as if it was trying to look past the mask. While it was good that Apple finally acknowledged Face ID shortcomings with face masks after ignoring complaints from Asian users, it took a health crises to force Apple to do something about it. In the end it didn’t change anything.
And now we have iOS 14.5 with Face ID ‘Unlock with Apple Watch’, another stop-gap until Apple delivers a real solution. It will never work with Apple Pay, which it should not though many will wish for it fumbling with iPhone Face ID authorization in the checkout line. It’s probably most helpful when digging for point reward QR Code apps that don’t use Face ID for sign in. Will it help sell Apple Watches? Perhaps, but it also might dampen future iPhone upgrades with improved Face ID.
Some first impressions…it feels like what it is: a clever hack but a hack nevertheless, to do something Face ID wasn’t designed to do that re-routes the ‘chain of trust’ from one way to two way. This makes things much more complicated. Already there are complaints of Face ID unlock with Apple Watch not working when Apple Pay Octopus users are in transit. I also find it unreliable especially during Suica transit. Overall 1 out of 3 times it strikes out. I know the feature is beta 1, but I already get that iPhone X NFC problem vibe: deep down this feature isn’t going to work reliably…ever.
A happy new year to everybody. When reading Junya Suzuki’s year end Apple Pay and contactless history in Japan article, I was irritated by its ‘rah rah for open loop’ ending that seemed to conclude EMV isn’t very slow and tap speed differences don’t really matter. After reading followup tweets with other IT journalists I realized that wasn’t his point at all. What Suzuki san was really saying was the total transit gate experience counts more than any particular technology package (MIFARE, FeliCa, EMV Open Loop, etc.).
Steve Jobs said the same thing about technology and products in the famous, “you have to start with the customer experience and work backwards to the technology,” 1997 WWDC video. In other words, the whole (the product) has to be larger than sum of the parts (the technology pieces that make up the product) to be a success. It’s all about how they integrate as a product into the larger whole ‘vision’ thing. JR East transit gates are great because the total experience is greater than sum of FeliCa, Suica, JREM reader and gate design technology parts added together.
There is also constant pressure to eliminate Japanese FeliCa contactless payment networks in favor EMV using the old bait and switch tactic of promoting a proprietary industry standard when the real end game is eliminating local competitors. These are issues that few journalists bother to analyze deeply and also what got Jack Ma in trouble when he blasted the Basel Accords, the traditional banking system, as an exclusive old men’s club that stifles innovation.
Power games in the world’s greatest free-for-all payments market I’ve said this many times but one of the great things about Japan many western journalists completely miss, is that Japan is the world best guinea pig test market. Especially useful for observing new payment trends at work. The market is a perfect not too big not too small size, super cohesive, and it has a long history of Osaifu Keitai mobile payments with a wide foundation of payment technologies encompassing FeliCa, EMV and QR. And there is lots of money sitting in bank accounts. This unique mix affords the careful observer a virtual front seat on the power games playing out right now after the introduction of QR based payment services like Line Pay, PayPay and dBarai (dPay).
When Docomo unveiled their dBarai app service it confused many users. What was the point of using code payments when Docomo already had dCard and the whole Mobile FeliCa iD network in place for promoting contactless payments? But it wasn’t long before Docomo linked the 2 payment services together. dBarai users can pay using 3 different backend payment choices: direct dCard billing, monthly Docomo billing, a rechargeable stored value dBarai account with cash recharge options via ATM or linked bank account.
From the user point of view it doesn’t matter when they pay with a Docomo code payment app tied and charged to their dCard on the backend, it’s the same monthly bill. But to Docomo it is very different: instead of using the iD or SMBC VISA/MC payment network on the front end, it’s the Docomo dBarai payment network. I suspect Docomo pays less of a transaction cut to the bank because they have the cash flow to assume some of the risk that banks usually assume in establied credit card network transactions. Docomo likely also leverages the daily transaction float. In short the AliPay model. The next logical step for Docomo dBarai will be P2P payments that leverage Docomo’s Mercari connection.
The value of code payments in dBarai isn’t the technology, it’s a expedient tool that Docomo leverages to circumvent the limitations and fee structure of banks and card networks to create their own flexible payment network. This wiggle room is the essential margin that drives QR Code payment empire cashbacks, point giveaways and new services. This is the epicenter of the cashless payment turf wars that pits new mobile payment players against established card and bank networks. And Apple is about to dump delicious chunk bait into this shark tank.
The Toyota Wallet multi-payment model In the Apple Pay 2020 wrap-up I mentioned Toyota Wallet as the most important trend: a Wallet app that lets users pay with a QR code or with NFC via an instant issue prepaid Apple Pay Wallet card. The Toyota Wallet iD/Mastercard has 2 Apple Pay device account numbers, one for the iD payment network and one for the Mastercard payment network. This is common for most Japanese issue payment cards on Apple Pay but it is less about NFC protocols (FeliCa, EMV) and all about dual payment network support in a single payment card. And it is not limited to Japan. In Australia there are dual payment Apple Pay cards that support both Mastercard and EFTPOS payment networks in a single card.
With Apple Pay Code Payments on the way, possibly with iOS 14.4, we have another option for multi-payment network cards: code payment and NFC payment. Apple Pay Code Payments are thought of as being only for AliPay and WeChat Pay support in China, but they are much more than that.
Apple Pay Code Payments gives mobile payment players the ability to move QR/barcode payments from an outside app and integrate them directly into an Apple Pay Wallet card. In the Toyota Wallet example below, Toyota could simply add another device account number for the QR Code payment network:
This might seem trivial but it’s important to remember some key differences of Wallet payment cards:
Direct side button Wallet activation with automatic Face/Touch ID authentication and payment at the reader.
Device payment transactions handled by the eSE without a network connection.
Ability to set a default main card for Apple Pay use.
In the Japan market Line Pay, PayPay, dBarai, Rakuten and all other new players will have the tools to create better services tightly integrated in a Apple Pay Wallet card. Docomo for example could incorporate dBarai into dCard with an additional device account number. Mix and match payment networking in one card.
In the payment network world where market share is all, card networks have held too much power for too long, exactly what Jack Ma was complaining about. I see competition as a good thing that encourages innovation and choice, mobile payments are doing that.
Looping back to the open loop beginning of this piece I think it makes sense now to realign the debate points away from focusing on technology (EMV vs FeliCa, NFC vs QR, etc.), i.e. things that can change and evolve, and focus on payment network turf wars, i.e. things that are hard to change until you see the battles lines clearly enough to create a better strategy and get where you want to go.
In the public transit arena it always comes down to this. Moving people quickly and safely by transit, managed wisely, is licensed cash flow from the fare gates. A transit company can keep control of that license to build something of greater long term value for the users and businesses of the transit card region, which can cover the nation. A transit company can give control away to someone else and let them take their cut, but just like Jack Ma pointed out before he disappeared, will there be innovation when going all in with traditional card and bank payment networks?
I still say a transit platform, especially in the mobile era of chaotic opportunity, is the best approach if a company wants to achieve the former: a system where the whole is greater than the sum of the parts. Start with the best customer experience you want to deliver and work backwards to the technology.