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?

Are you a Tier 1 or a Tier 2 token requestor? (It matters)

With all the talk about Token Service Providers (TSP) and token requesting, I felt it was worth describing a bit more about the role of a "Token Requestor." The way the term is bandied about would lead most to believe that this is a single entity that works to pull temporary or dynamic transactional data from a master TSP for use on the mobile device, but you are about to find out it's a bit more complicated and the decision you make around this topic can have serious consequences in the future.

We all know that the current normalized TSPs or Master Token Service Provider services are the domain of the card networks - presently MasterCard, Visa and AMEX. I don't expect that role to change overnight or in the next year or for some banks, maybe ever. But if banks expect to be able to control their own destiny with the decision, they’ll need to understand some important differences about the term “Token Requestor.”

What’s really going on under the hood

Contrary to what some providers may tell you, “Token Requestor” isn’t a single entity but actually two separate roles which work in tandem. The goal of this article is to help readers understand the roles better because in reality the roles are as different as comparing apples and oranges (or more appropriately stated "service" and "consumer of service").  And more importantly, the selection of the roles dictate the end result of the service and in that, how “locked in” or “not locked in” you are to one provider.

Here is a high level diagram that depicts how tokens are issued to help better understand the 2 tiered roles of token requestors.

Let’s break down the "Token Requestor" blob we have above into two distinct roles before identifying the practical examples of entities that fill those roles.

Tier 1 token definition: The root token requested from the Token Service Provider which is static data for the life of the issued card.  A Tier 1 token has the ability to be autonomous from the TSP and service individual transaction level Tier 2 token issuance because all data required to create many Tier 2 tokens are available in their respective parent Tier 1 token.  So basically, the Tier 1 token is the creator for all Tier 2 tokens.  It is a parent->children relationship.

The tier 1 role is that of being the primary service provider for individual cards and can be summarized by these tasks:

• Requesting the static token from the TSP which includes the tokenized PAN and the card master key
• Protecting the card master key
• Generating all Tier 2 tokens from the card master key
• Responding to service requests to receive new Tier 2 tokens
• Responding to issuer triggers for card life cycle events such as:
• card personalization
• card termination
• card disable
• card enable

Tier 2 token definition:  The secondary or child token that is generated from the root or parent token and used for individual payment transactions. This token is considered limited use and is deemed "ok" to be housed in the mobile device application.

The Tier 2 role is to protect and deliver the tokenized payment information to the acquirer for individual transactions and can be summarized by these tasks:

• Requesting the dynamic token from the Tier 1 service
• Protecting the dynamic token
• Managing the lifecycle of the dynamic token
• Delivering the dynamic token to the acquirer when requested

Some practical examples of the token request process are listed below and include some current day entities who are performing those roles:

It is especially important to note in the diagram above how both the Master Token Service and Tier 1 Token Requestor are the same entity in some cases.  THEY DO NOT HAVE TO BE AND THEY PROBABLY SHOULDN'T BE.  For example both Visa and MasterCard offer the master TSP service but are also performing as a Tier 1 service requestor to their own TSP at the same time.  That would mean that a service like we provide as a Tier 1 requestor consumes MasterCard or Visa TSP services, but then ALSO COMPETES directly with them as a Tier 1 requestor. Essentially, what some card networks have proposed greatly reduces your ability to chose competitive service offerings if your needs change in the future.

If this scenario makes you uncomfortable, you have reason to be concerned, the implications could be very costly to your mobile payments strategy in the long run.

The key business driver and need for a company like SimplyTapp in the Tier 1 Requestor role is that we offer a configuration option for the Master TSP services for each card brand which in turn can offer autonomy from the card networks similar to what Apple is able to do through Apple Pay (once they request a token from the networks, they run the service on that token through securing the token master key on the Secure Element).  This helps maintain the existing card issuance relationship with the networks status quo when comparing to the existing issuance model of plastic.  

Does the Tier 1 Token Requestor service you use allow you to configure or dictate the Master TSP?

See this chart:

You are a Tier 2 token requestor and

Your Tier 1 Requestor Service is:	You Can Configure and change the Master TSP mid-service	Switch From TSP without card by card migration
Visa	NO, use Visa TSP only	NO
MasterCard	NO, use MasterCard TSP only	NO
3rd Party	Yes, use VISA, MC, or even your own later	YES

So, the 3rd party Tier 1 Requestor service helps issuing customers with greater migration control.  If an issuer has aspirations to run it's own TSP at some point, or select a different TSP, this is an important point NOT to miss.

If a group of cards has been issued through the TSP service to a Tier 1 Requestor, changing that Tier 1 requestor leads to a MIGRATION process rather than just a switch over of the entire card set.  This further impacts the mobile application itself as it would be required to be a Tier 2 Requestor to possibly multiple Tier 1 requestors during the change over.  

In the event the Tier 1 requestor offers TSP configuration, that configuration to use a different TSP can be changed very similar to a DNS registration which makes the switch overnight and designed not to impact anything downstream (no impact on Tier 2 requestor --mobile app--, or existing cards).  

In the event the Tier 1 requestor DOES NOT offer a TSP configuration option, then the only way to move TSP would be to move Tier 1 requestor services, which has a dramatic impact downstream to the Tier 2 requestor / mobile app and also creates a migration switch rather than immediate.

The key question that needs to be asked:

Does your Tier 1 Token Requestor service offer independent configuration of the TSP master service?

If the answer is NO, then you are mostly likely locked-in for the long haul.

If the answer is YES, then you will have more flexibility to some day:

• Run your own or change to a different TSP.
• Negotiate better rates because there is no technical limitation to an immediate switch instead of a slow and resource consuming migration.