Blog article
See all stories »

How can I deploy my Android Wallet? tip: It’s already there!

Apple Pay is here and banks can finally enable NFC mobile payments for their iPhone carrying customers. However, the Apple smart phone user base, while considerable, is only part of the entire customer base of banks and merchants. How can banks serve their entire customer base, especially their Android-based customers?

And this is not a small problem. According to research firm IDC, 85% of smart phones shipped in the second quarter globally were running Android. And that market share is up considerably from 80% at the end of 2013.

If you are a bank, you want your mobile services to be available to 100% of your customers. Just imagine providing remote check deposit functionality to only your iPhone users, and none to your Android users.

Android opportunities

There are actually a lot more Android devices equipped with the same Near Field Communications (NFC) technology that allows for proximity payments. ABI research estimates a total of 320 million NFC-enabled devices to ship in 2014, the great majority of them Android smart phones.

But you would be hard pressed to find mobile payment solutions to fill the needs of banks and merchants on the Android ecosystem. The Android platform’s own “open” nature make it almost impossible for a single wallet to dominate the entire market. Just ask Google!  Google rolled out Google Wallet 1.0 in 2013, which depended on a secure chip called the Secure Element. But the operators blocked the service because they controlled the device and the Secure Element.

HCE: An Open Solution for an Open Ecosystem

But Google learned valuable lessons from the Google Wallet 1.0 experience and came up with an open solution to fit its open ecosystem. In the Kit Kat version of Android, Google adopted Host Card Emulation (or HCE for short) technology to enable mobile payments.

The ingenious way HCE was implemented in the Android OS prevents any mobile phone operator or phone manufacturer from blocking it. And it allows any app in the mobile phone to access credit and debit cards banks store in the cloud to make payments at merchants just like Apple Pay.

The “open” nature of the platform is an opportunity for banks and merchants.

Your app is your wallet

The big revolution HCE is bringing is that there is no need for a single “wallet”. A banking or a merchant app can itself access payment credentials and make payments in the physical world by just leveraging APIs. For example you could pay for your latte with your Citibank app or go to Home Depot and use your Home Depot app to pay, redeem offers and earn loyalty points in the process, much like the Starbucks app works today.

And Starbucks is succeeding beyond all expectations. Last fall Starbucks announced that 11% of their sales volume came through Starbucks own mobile wallet; a huge number for any mobile payments system.

But more than that, Starbucks turned their app into a priceless repeat use channel of communication with consumers. Starbucks leveraged this customer touchpoint to integrate loyalty and offers into the same mobile app to create an excellent all-around consumer experience.

Banks and merchants have the opportunity to repeat this model on the Android ecosystem with their own apps, already being used by consumers today. By powering their apps to become wallets they can manage their brand and user experience from beginning to end and create loyalty through their own apps.

What’s more, the cost of acquiring customers and getting them to download your wallet is almost nil. The wallet functionality can be added to a bank’s existing app by a simple app update, in the same way banks roll out check deposit and other functionality to their apps today.

 

5437

Comments: (1)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 03 November, 2014, 15:39Be the first to give this comment the thumbs up 0 likes

Many banks I've spoken to have told me that they've taken a conscious decision to release mobile wallet as a separate app and not as a feature of their mobile banking app.

This resonates well with mobile app best practices which prescribe that mobile apps should be designed at a lower level of granularity compared to web apps. As a result, a single web app will inevitably be broken down into multiple mobile apps. I've covered the reasons for this approach in a post titled titled SaaS Will Change The Outcome Of The Bloatware Versus Light Apps Debate (hyperlink removed to comply with Finextra Community Rules but this post will appear on top of Google Search results) on my company blog. 

For example, Oracle has split its single JDE ERP package into 60 mobile apps (https://twitter.com/GTM360/status/493600498482548739). The closest BFSI example of this I can think of is ICICI Bank's app store, in which 2 web apps have been split into 10 mobile apps. 

Now hiring