Mobile contact - less payments: A simple guide to issuers | Part 1.
If you have been following the mobile payments development, you probably noticed the increasing number of different wallet solutions from both individual banks as well as big-name companies like Apple, Samsung and Google. Some seem to be doing good while others have not left the pilot stage, some are making money while business reasoning for others may not be immediately clear. Many issuers are currently thinking about entering the fray, while others are still looking from the sidelines to see which products and strategies will prove to be best.
This is also true with our customers. In one of the recent Tieto customer events I was asked if issuer branded wallets have a fighting chance against the big guys like Apple Pay and others. We also get questions on how to roll out a mobile payment wallet, or how to enroll with particular wallet service provider, how does HCE work, etc.
Besides the business considerations there are also questions about the actual implementation of these wallets - do you buy vendor software and implement it in-house? Do you integrate with VISA and MC digitization services?
In this blog post I will try to clarify some of these topics, and also share my opinion about options available.
Mobile Payments 101
Many latest smartphones come with a built-in NFC chip and antenna, which allow communication with NFC capable payment terminals. So if we could get the payment card details into such a phone, we would be able to use it as a physical body of our card to tap and pay - just like we would with a regular plastic contact-less card.
To avoid getting into technical nitty-gritty’s (there is lot’s of information available on the net on technical aspects, I will not repeat it here), getting the card (or rather payment credentials associated with the card) into such a phone in a secure manner is the most important aspect of enabling mobile contact-less payments. On the physical card the payment credentials reside on the EMV chip, which is a small microcomputer that facilitates information exchange between the card and payment acceptance device (like the POS). But how can this be replicated on a phone? Up until recently there were 3 main ways to achieve that:
- Use the SIM card. SIM card is also a chip, so it can store and process information, just like the EMV chip on physical card. But to put that additional card related information on a SIM an issuer would need to negotiate with tel-co’s who own the SIM cards. Additionally, provisioning the payment credentials to a SIM over the air securely requires complicated infrastructure involving so called TSM’s (Trusted Service Managers), which add additional dependency.
- Use the SD card. SD card is a data storage device, and you can write an application on it for payments. This application then can be executed by the OS of mobile phone. This method, however, also has many drawbacks - first, not very phone has SD card slot. Second, executing such sensitive payment applications require additional security features in the app’s code and even in the mobile phone OS itself. Finally, the question of logistics - how to distribute the SD cards- also remains.
- Use the Secure Element. SE is a special temper-proof microchip that is embedded into the phone already in the factory during the manufacturing process for the single purpose of storing sensitive data. However, very few phones actually have them, and those that do are not open to external access- meaning the issuer will have to negotiate with phone manufacturer for access to these SE’s for payment credential provisioning.
Host Card Emulation
All of these methods are being used in real-life projects today (Apple Pay, for example, uses secure element), but from an issuer perspective you can clearly see a common problem they share - all rely on 3rd parties. This forces issuers to engage into complicated business models, partnerships and technology infrastructure model in order to roll out mobile payment solutions to end users. In my opinion this aspect was one of contributing factors to slow adoption mobile NFC payments.
Enter HCE - Host Card Emulation technology, brought into the masses by Google in hopes to promote and give competitive edge to Google Wallet, which later became Android Pay. Again, not to go into technical details, what HCE technology does is emulate an EMV chip in a virtual space - the “cloud” - that can be hosted or controlled by the issuer or a processor servicing the issuer, thus eliminating any third party out of equation. The downside is that HCE is only available on latest Android (and Windows phone and Blackberry, but the market share for those is negligible) platforms so in theory it is now easier then ever to create and roll out a mobile payments wallet offering.
Or is it?
In practice it was soon apparent that the actual implementation of wallets using the HCE was not that straight forward due to vague specifications and requirement of certain knowledge and skills to be available for issuers to be able to successfully pull it off. There was also not much of a choice in vendor software that could ensure end-to-end user enrolment, transaction processing and payment credential management and uploading to the phone, and the payments app itself.
So to make life easier both VISA and Mastercard opened up their so-called digitization platforms (VDEP/VTS and MDES respectively), previously only used by Apple Pay, to issuers and wallet providers.
MDES and VDEP / VTS
MDES (MasterCard Digital Enablement System) and VDEP (Visa Digital Enablement Platform) / VTS (Visa Token Service) are latest services from the popular payment schemes, and continue the trend of them becoming increasingly more service oriented companies. The payments landscape is evolving very fast, and both VISA and MC recognize that traditional products and revenue streams are becoming redundant. The schemes, however, have a massive advantage - brand recognisability and reliable transaction processing infrastructure that works. Those can be leveraged not only to offer new services, but also elevate them to a de-facto industry standard. Which is what the schemes are aiming for.
Let’s look at what MDES and VDEP really do offer.
Essentially both of them are a set of API’s that are aimed at issuers and wallet providers (an issuer can also fill a wallet provider’s role) to take care of technical aspects of tokenizing a card and providing the payment credentials to be uploaded onto the phone, and be used by the payment app. There are two sides to be integrated with MDES and MDEP/VTS platforms - the issuer needs to support specific parameters in online interfaces to schemes (so that issuer can properly process card tokenization and transaction processing messages), and the wallet app platform needs to call specific MDES / VDEP API commands to request card tokenization, and if successful - upload the card credentials onto the phone. MDES and VDEP/VTS take care of token issuing, token (and related payment credential) lifecycle management and de-tokenization operations (matching tokens to real card numbers for incoming transactions and then forming transaction messages with those real card numbers and sending them to issuers). The value in these services is that through such platforms the schemes connect issuers, cardholders and wallet providers in one network, allowing for interoperability and standardization. If an issuer supports VISA or Mastercard digitization standards- any wallet provider (who also adheres to same standards) can enroll such issuer’s VISA or Mastercard cardholder into his service (of course, if the cardholder’s issuer allows it). So in theory this is a good thing, but in practice again there are nuances.
Cloud based payments specs from the schemes were a work-in-progress, and changed from time to time to support certain business cases insisted upon by issuers. So some of the first mobile payment solutions that were rolled out needed to be adjusted and re-certified to confirm with latest versions of the specs. Sometimes waivers were given, but even then only as a temporary measure. The scheme digitization platforms also had a bit of a rough start, though it’s getting better now. To further assist with mobile payment adoption, Mastercard released it’s own SDK for building payment apps (or integrating payment functionality to existing banking apps) to public. Recently MC announced that they will use MasterPass platform to enable contact-less payments for enrolled cards, further helping issuers solve the technical implementation aspects. Visa on the other hand has taken it one step further and is starting to offer a white label wallet to banks directly (albeit only in US for the moment). And in what could become one of the most interesting recent developments in the wallet space – both VISA and MC have engaged with PayPal for cooperation. What roles the issuers have to play there is an interesting topic, one that I will leave for the next time.
To sum it up…
So in general, if you are an issuer and want to create a mobile payments offering, you can either write or buy your own solution (let’s call it digitization software) based on HCE technology, or integrating into scheme digitization services (if you don’t want to be bothered with software implementation projects). If you are in one of the countries where big brand wallets are operating - you can talk with them directly, and if you come to an agreement- integrate into scheme digitization services to enable cardholders use those wallets. That should take care of back-office user enrollment, card tokenization / de-tokenization, payment credential management and transaction processing magic.
For the front end - the actual app itself - you can again either write your own or buy a readily available app from a vendor altogether. Then it’s integrating the app with the digitization software or digitization services of the schemes. If you are getting both your back-end and front-end software from the same vendor then it should be already integrated and working. If you can work with brand wallets then the app side is already taken care of. Is that it? Well, as with all things, there are again nuances, which I will discuss in the second part of this blog post.