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?