The growing popularity of Google Pay and Apple Pay encourages banks to implement these new payment systems. However, the whole process is not easy and can take months.
Apple decided to introduce its payment system in the UK four years ago. As you may expect most major banks decided to sign up to the scheme and made Apple Pay available at its launch. However not everyone made it according to the plan. HSBC, one of the four biggest British banks, was hit by delays and it “got absolutely killed on social media for the slip up”. When its clients learned they would need to wait a few more days, negative tweets about HSBC outnumbered the positive ones 5 to 1. Here’s one of the worst:
@HSBC_UK_Help I’ve been banking with HSBC for 15 years, but I’ll be signing up to @natwest_help today because of Apple Pay.— Richard (@rchrdctswrth) 14 lipca 2015
There are many other examples of how banks failed to keep up with the promise given to customers. For instance, the implementation of Apple Pay in Bank Millennium was postponed for a few months. Millennium is one of the leading banks in Poland, so the delay was widely discussed in the industry and among the bank’s clients. Delays also occurred in the German Deutsche Kredit Bank or the Polish PKO and Bank Pocztowy.
In consequence, the delays have affected banks reputation.
We are offering our selected products FREE of charge for the period of the pandemic. Learn more.
Why isn’t the implementation of Apple Pay or Google Pay straightforward?
First of all, the bank needs to remember that the implementation consists of two separate stages.
The goal of the first stage is to allow the bank’s clients to add their card to Apple Wallet or Google Pay App. From the client’s point of view, this process looks as follows: a client opens up their Google Pay or Apple Wallet application and then types manually the details of the card in the app’s form or simply by scanning (OCR) the card data with the phone’s camera. To make the above possible, banks need to first integrate with a token service provider (TSP) which provides card tokenization services (more about it later in the article). Banks are mainly choosing well-known providers like MasterCard (MDES) or Visa (VTS).
In the second stage banks are obligated to ensure that their clients can also add their credit or debit card to Apple Pay or Google Pay via mobile banking apps. In this step banks have to meet two important requirements: enable the initiation of Provisioning through the bank application and allow user verification by means of the bank app in order to activate a payment pass.
What is provisioning? For those of you who are not familiar with the term provisioning — it is a process in which a new virtual card is created and then added to a digital wallet on a mobile device for instant availability of funds. In the second stage of Google Pay and Apple Pay implementation, provisioning is initiated from the mobile banking application, so it is also called In-App Provisioning (in Apple’s terminology) and Push Provisioning (in Google’s terminology).
Why is the second stage so important?
First of all, it is important because banks have signed agreements with Apple and Google under which they are obliged to implement both stages. As the second stage seems to be easier to manage, it might be underestimated. After all, to make the provisioning work bank needs to “only” establish a connection between mobile banking app and the token service provider. That’s where challenges come up.
Challenge #1: Many parties involved
In order to make the implementation of Google Pay and Apple Pay possible, banks have to cooperate not only with Google and Apple.
Other parties involved in the process are Token Service Providers like MasterCard or VISA. They deal both with tokenization, offering their own specific systems, namely MasterCard Digital Enablement Service (MDES) and VISA Token Service (VTS). Thanks to tokenization customers can easily pay with various devices such as smartphones or smartwatches. In other words, MDES and VTS help transform any connected device into a commerce device to make and receive payments. (It seems that we live in times where nearly every electronic device is becoming a shopping device at some point, but this is a topic for another article.
In order to implement Apple Pay and Google Pay solutions, banks will have to continuously collect necessary business requirements from several parties involved in the process, i.e. Google, Apple, MasterCard (MDES) and Visa (VTS). Communication, arrangements and confirmation of data acquired in one source with the other party takes time.
Challenge #2: Technical expertise
The crucial point of the process is to select an appropriate format of the data and ensure that it is being supported. Moreover, it is important to maintain adequate cryptographic standards (if you do not have competence in the area of PKI, symmetric and asymmetric cryptography, and NIST cryptographic standards, it would be better to ask an expert). The ability to follow these standards is essential to securely transfer data from the bank to the mobile app and then to the chosen pay system, which in consequence will initiate the card provisioning process.
Challenge #3: Trial and error method
The most problematic thing in the implementation process is incomplete technical documentation, which forces the bank to base the whole project partly on the trial and error method. The key to implementing the solution in the optimum time and without any additional costs is the know-how. Lack of this knowledge may delay the whole implementation for several months.
For instance, banks need to decide:
- which elements could be reused to avoid overpaying,
- which of the available in-app verification paths should be adopted,
- which card identification sent by the server is necessary to correctly perform the Provisioning function.
And this is only a part of the bigger picture.
Challenge #4: Terminology
Factors such as imprecise documentation and strategic decisions regarding possible implementation variants play a major role here. The thing the bank should particularly look out for is the consistency of terminology used by different parties associated with the project.
For instance, Apple calls provisioning “in-app provisioning” and Google calls it “push provisioning”. In Apple’s dictionary verification is called “in-app verification”, while in Google’s “app-to-app verification”. It’s only the tip of the iceberg. For instance, the ‘’unique identifier of the tokenized card” has different names in Google, Apple, Visa and Mastercard documentations, and it can take a little while to understand that those are actually the same thing.
Challenge #5: Testing
Before the bank can deploy a ready solution on a live server, it has to pass tests conducted by external auditing companies and be approved by Apple and Google, which further complicates the process. A bank that does not pass the tests will have to implement the improvements imposed by Google or Apple. Every time the bank will also have to cover the high cost of taking the test – usually several thousand Euro per attempt – and wait another few weeks for test results.
It is an open secret that cooperation between a bank and Apple Pay or Google Pay is a love-hate relationship. Even if the banking industry has to deal with higher risks and costs associated with implementing a mobile payment solution, in order to stay relevant, issuers have to follow customers’ needs.
And there is no turning back. Google and Apple Pay services are continuously gaining traction among users. Apple’s CEO Tim Cook said in March that Apple Pay would be available in more than 40 countries and regions by the end of 2019 and Google Pay (which seems more dynamic in its actions) is now available in nearly 140 countries.
To make the whole situation as seamless as possible for banks, we created Google Pay and Apple Pay Provisioning and Verification SDK (Software Development Kit). The solution enables the bank to implement in their mobile application the functionality of initiating the Card Provisioning process and the ability to verify the user and activate a payment pass. Please contact us to learn more.