Blog article
See all stories »

How many apps for all your mobile payment needs?

This blog is really an outcome of the questions/ comments I received on my previous blog on Apple Pay. Every one has essentially 3 main tasks when it comes to payments - pay friends/ relatives/ other individuals, pay billers, and pay merchants. I had written about how Apple Pay does not help me with all of these tasks in a holistic fashion.

I received several comments/ questions that pretty much summed up to the following - why does Apple Pay need to do everything? You can use multiple apps for different aspects of your payment needs. My response:

This is true with caveats. Primarily I am thinking about this from the user experience point of view. Any company - whether it is the bank or Apple or anyone else can't be available at the forefront in all the digital contexts a user (especially a savvy millenial user) is likely to be in. So I get the point that one will necessarily have to use multiple apps for their payment needs. However, when a user is forced to use multiple apps for their different payment needs, there are some challenges which much be addressed.

First of all, there is the "linked domain" or "integrated user experience" challenge. Take the merchant payment for example. If the user has to use a different offers app to get the offers and use Apple Pay to pay the merchant, then the two apps better integrate and talk to each other. If they dont share data and automatically apply the chosen offers to the shopping cart, then how good is the user experience?

The "linked domain" challenge leads to the next one - "number of domains". There are physical limitations on how much a user can remember, how many apps they can switch between for their payment need. My belief is that for a given payment need, a user can live with utmost two domains in a digital context. The first domain could be "presence" or "availability" of the payment feature that the user needs. For example, even within paying friends or relatives, there are so many different domains that the user could be in - paying for dinner shared, paying for taxi ride shared, paying for family maintenance, giving a gift, etc. All of these contexts are likely to require an app that fulfills the specific need in focus. And that app will also provide other non payment related features that are critical for the digital context - e.g. Open Table that provides the facility to lookup/ reserve restaurants and order before going to the restaurant.

Once the details specific to the "presence domain" are captured, ultimately all payments boil down to knowing the sender, receiver, amount, and by when. When the payment enters this "transaction mode", it is entering the "trust domain" of the digital context. This is where the user gets skeptical about revealing sensitive data. This is the domain best served by banks.

My conclusion or recommendation - you can't have more than two apps in a digital context for a user to complete their payment need and the two apps better be talking to each other and share known/ common data to make the user experience smooth. Invariaby the first app will belong to the "presence domain" of the digital context and capture the context of the payment need better based on who the user is, where the user is, and who/ how/ when they want to pay. The latter app that follows will belong to the "trust domain" of the digital context. This is where sensitive data is shared with the basic payment details and the payment scheduled or completed through a financial network.

Corollary 1 - Invariably 3rd parties (app developers, alternative payment providers) will dominate the "presence domain" (being available whenever/ wherever the user needs help) of the digital context. Banks and financial institutions will dominate the "trust domain" of the digital context where the mechanics of the payment engine kick in and the payment gets validated, scheduled, cleared, and settled.

Corollary 2 - To make life easy for digital users, banks and financial institutions in the trust domain of the digital context should be thinking about using API's as a channel to allow payments origination through apps from 3rd parties in the presence domain of the digital context. This is predominantly how a digital bank can be available to a digital user whenever/ wherever required.

Corollary 3 - A bank or a financial institution will not be relegated to the back office and lose their brand identity simply because they are sitting in the trust domain behind the presence domain of the digital context. Users know all too well that the trust domain is the most important aspect of any digital context and will always value and depend on their service provider in that space.

What do you think?

a member-uploaded image

Comments: (5)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 03 March, 2015, 18:38Be the first to give this comment the thumbs up 0 likes

I think the adverse impact of multiple mobile apps on UX is overstated. It perhaps harkens back to imposing the desktop app paradigm to mobile apps, which is wrong because: 

  1. It's extremely easy to install a mobile app compared to a desktop app. 
  2. The homescreen of an Android smartphone typically has a Google Search bar. Like on a desktop, this presents search results from the WWW. However, unlike on a desktop, it can also be used to quickly reach a specific app on an Android smartphone. (In the absence of a similar feature, I concede that it could be quite painful to find a specific app on iPhone). 

That said, your architecture vision is interesting.

However, standard APIs don't seem to work to facilitate the required information exchange between a said page / section of Presence Domain App (PDA) and a said page / section of  Trust Domain App (TDA). Sophisticated "deep linking" technology will be called for. Not sure why, but I've never come across deep linking implemented in practice even inside a single app, let alone between two different apps owned by two different publishers. I'd expressed my frustration caused by the lack of this feature in a certain offer app in the following tweet:

Even after overcoming the above challenge, data protection laws may not permit information interchange between PDA and TDA from two different legal entities, even if the user allows it.

Overcoming these two challenges will be key to successful realization of your architecture vision.

A Finextra member
A Finextra member 04 March, 2015, 19:06Be the first to give this comment the thumbs up 0 likes There is no restriction on the number of apps in the presence domain. Given varying digital contexts users are likely to be in, there can be multitude of mobile payment apps in the presence domain. The idea just limits number of apps in the trust domain so that the user can share sensitive data only with trusted parties. Also the idea suggests that the user doesn't have to traverse more than 2 apps when they go from presence to trust domains. All related features for the given digital context the user is in should be ideally available in one app. For example it makes sense for a merchant app to bundle all related features such as offers, loading shopping cart, etc. When it is time to pay, the app would connect with the trust domain app either provided by the merchant themselves or a financial institution.
Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 05 March, 2015, 13:32Be the first to give this comment the thumbs up 0 likes

I totally forgot about a third challenge: How will the FI react to consumer handing over their "funding account" (NetBanking / card) credentials to a PDA to enable seamless payment? I know that Mint and other PFMs have persuaded millions of people in the USA to share their creds with them but that's only against an express commitment of "read-only" access. Whereas in your proposed architecture, PDA would need transaction access to TDA. Even assuming the FI doesn't disallow this, I wonder what would happen if there was a fraud. Would the FI continue to eat the fraud loss as at present or try to wash its hands off, saying consumer handed over transaction access to third party, so how can it be held responsible.

Jozsef Czimer
Jozsef Czimer - Inresoft Hungary - London 09 March, 2015, 14:19Be the first to give this comment the thumbs up 0 likes

The whole you all have written contains why people do not like mobile payments. What is more complicated than to tap your bankcard is useless. Ot is only an additional thing that Apple Pay and almost all mobile systems are wallet based with limited mearchants to accept them. So a real mobile payment system is as far as a wholly functioning Zapp

A Finextra member
A Finextra member 09 March, 2015, 19:58Be the first to give this comment the thumbs up 0 likes Good thoughts and well written. Thx. I have seen that the use og APIs is mentioned as a magic wand for financial institutions: As a bank you should offer a simple way to connect to your payment infrastructure. Then the bank get a rush of app providers to enable the API in their solution and everybody is happy. To make an API is dead simple (sorry IT friends) so why don't everybody just do it? First of all i think its because the approach is extremely risky. The bank takes care of MY money If they handed over a specification and a crypto key to anyone who asked for it - and allowed them access to my money without any quality control I would say they fail the risk management test. Someone would say that this is no different than what the credit card companies does. And they are right! But we don't need more fundring sources for terrorists and drug dealers. And luckily it seems like most banks agree.