Apple Pay usage dips; banks, take note

In a new report from PYMNTS.com, retail data analytics firm InfoScout is reporting Apple Pay usage has been on a steady decline since March 2015. Of the nearly 40 percent of consumers surveyed who said they had used Apple Pay to complete a transaction, only 23 percent still said “yes” three months later. What’s more, Apple Pay saw a 15 percent dip in committed users – down to 33 percent as of June 2015.

While many are dumbfounded, Apple’s steady decline is really not that surprising. What it instead reveals is the effectiveness of organic user growth over traditional  marketing – a critical, and potentially crippling, difference to successful mobile payments adoption. As the hype surrounding the launch of the iPhone 6 has dwindled, it appears Apple Pay usage has as well.

 

So why is this happening?  The payment experience alone of Apple Pay is too different from anything the consumer previously used for them to remember –or even care – about making it a habit unless they are constantly reminded to. In the iOS eco-system Apple is not flexible to mobile banking, which has forced all bank cards into an aggregated Passbook wallet that is very out of the context of the users’ typical banking application.

Unfortunately for the banks who are now locked into Apple Pay, the technology will continue to grow at a much slower rate than what they are paying for. They do, however, still have a chance to turn things around and take back control from Android Pay by deploying their own mobile payment solution.

Android Pay is deployed on only 5 percent of all Android devices. Bank product managers are faced with two distinct choices as a result: encourage mobile users to download and access their credit card accounts through Android Pay, or modify their existing banking app with their own tap-and-pay feature.

With option two, the conversion rate and lack of additional steps seems like a more practical and favorable approach. More importantly, banks don’t have to worry about competing with another application to keep users engaged and coming back. With option two, banks can take a low-cost approach and organically grow payments into their business.

Like Apple Pay, banks can spend as much money on promoting Android Pay but at what cost? The reality is tap-and-go payments will not see widespread consumer adoption without steady, frequent exposure via a familiar user experience. An initial high-profile launch or big marketing budget will only go so far.

For contactless payments to endure, banks are better off using their own apps to court users. They already employed this approach with the “remote check cashing feature” and experienced widespread success by continuously making users aware they could perform digital check deposits until the practice became second nature. A bank that deploys their own solution within their own app faces far fewer friction points than a bank that leans on Android Pay, Apple Pay or any other third party.

 

In the long run mobile payment adoption rates will improve over time. But ultimately it is the banks who have the most to gain by fostering consumer relationships and acceptance. While the opportunity may have passed for Apple Pay, it’s not too late for financial institutions to take back control of their tap-and-go experience on their own terms.

What are your thoughts on Apple Pay’s drop in usage? Do you agree, or disagree that things can be different for Android Pay?

HCE: The User Experience That Nobody Talks About

Host Card Emulation (HCE) is an incredibly enabling technology. For Android developers there are a few nuances to be aware of in the form of OS rules. Not understanding how these rules apply can have a negative impact and create an embarrassing or awkward customer experience if the system should render a 'payment failure'. Here are four scenarios to keep in mind to avoid point-of-sale issues.

Avoid The Embarrassment

The only limiting factor for the NFC radio in an Android device is whether or not the screen is lit up. What that means is that the NFC radio will turn on and could be ready for an HCE transaction is:

screen is dark:    NO
screen is lit:       YES

That rule alone is an Android rule, not an application rule, and so the application will have the ability to further limit this HCE experience if it wants to.

To support the best user experience, an application must be able to respond and complete an HCE transaction on demand if the screen is lit up. This should hold true even if:

1) application is running in the foreground
2) application is running in the background
3) application is NOT running at all because android has "repo'd" or removed it from running memory, or not started at all since a re-boot of the phone.
4) application is NOT running and a time based  Limited Use Key has expired since the application stopped running

The 1st and 2nd cases above are the easy ones as transaction data can be store in the running application memory space.

Here is how android works on the 3rd and 4th scenarios. When the phone antenna engages the terminal antenna and the terminal requests a particular AID, then the android OS looks at that AID request from the terminal and decides which Card Emulation Service to startup based on the "Tap and Pay" menu options.  That service is NOT your app, it is a component of your application that is expected to respond to APDU requests from the terminal. An APDU stands for Application Protocol Data Units.  The challenge is that the service will most likely not contain the APDU data to respond with as the rest of the application is not currently running at that time and the data required may not be loaded. It would require that the APDU data that the reader is asking for actually must be persistent in some way on the device so that the service could get access to it and answer the terminal properly with card data.

There are a few ways to store data locally, but the point is that it must happen in order to respond to the reader in time for a proper user experience. We have noted that simply expecting the application to be running on the phone at tap time is simply not reliable and that in a 24 hour window, it the app is not used, then Android has likely removed that application from memory.

This is just food for thought as you are thinking of designing your own HCE application or using a vendor like ST.  By the way, the SimplyTapp SDK supports all 4 scenarios listed above. The 4th is slightly more complicated, but i'll leave it up to you to noodle at.

A Watershed Moment for the Payments Industry

Did you see the news? If you blinked, you might have missed it but its importance has ramifications throughout the payments industry.

Last Friday, Royal Bank of Canada (RBC) became the first North American bank to launch a pure Cloud Based Payments (CBP) solution utilizing Host Card Emulation (HCE) technology. Kudos to RBC! Read their release here.

An important aspect of the announcement is that the Canadian debit organization Interac was included with it’s Flash for Cloud Based Payments. Interac’s Flash seems to have beaten all other payments networks and their specifications to the punch by bringing a working solution to the market.

From our perspective, this marks the beginning of an anticipatory shift by financial institutions away from analog payments into digital. The shift will accelerate over the next several years as many financial institutions look for more effective ways to engage customers and distribute products to an ever more mobile and demanding consumer base. Juniper Research estimates mobile retail purchases to eclipse $700B annually by 2017. This transformation will not only impact the way banks engage with customers, but will drive what kinds of financial products and services are developed and how they are offered to customers throughout an ever evolving environment.

We’ve heard these predictions before, why now?

The payments industry ecosystem is at an inflection point. The meteoric rate at which innovation is happening foretells of much needed change and the necessity for more adaptive business models.

Enter CBP and HCE.

The concept of CBP and HCE did not exist until SimplyTapp introduced them in August 2012.  CBP is the framework for storing payment credentials in a virtual Secure Element (SE) in the cloud while HCE provides the path of getting those credentials from the cardholder’s mobile phone to the retailer’s Point of Sale (POS). Groundbreaking as that was, it only represented the first of several enablers that were needed before widespread adoption could take place within the industry. The next step that was needed occurred nearly one year later with the inclusion of HCE inside Android 4.4 (KitKat) in September 2013 which provided developers with a proven, widely distributed platform to build wallets and mobile banking applications. Earlier this year at Mobile World Congress in Barcelona, Visa and MasterCard gave their much needed support and endorsement for CBP and HCE providing immediate legitimacy and freeing up issuing banks for innovation. Only one critical requirement remained in order to drive adoption of this technology. A forward-looking bank needed to take the initiative and roll-out a live implementation with real data and real transactions. RBC’s announcement last week fulfilled that requirement.

With each of these key enablers firmly in place, the stage is set for mobile payment proliferation. Each day, consumers are expecting to do more with their mobile devices than ever before. The emergence of groundbreaking core technology and services, including the launch of Apple Pay, reveals a new and largely unmet demand for point-of-sale mobile purchases. More and more consumers will come to rely upon customer-centric financial institutions to help them conduct secure and convenient mobile purchases.

Being the first at anything is never easy. It requires vision, a smart assessment of the path ahead and a resolve to overcome any obstacles discovered along the way. For those who are willing, the rewards greatly outweigh the risks. We applaud RBC’s and Interac’s industry leadership and focus on the customer. And we join them in ushering a new year full of innovation.

Agree? Disagree? Let us know what you think.