Tokenization & Contactless

More knowledge on ApplePay, GooglePay, HCE and other ways of NFC and eCommerce payment using tokenization (MDES and VTS)

Issuer Wallet and ApplePay / GooglePay - Differences

As we have implemented more than 50 contactless and tokenization projects for banks, fintechs and other payment institutions, let me share a quick view on key differences between various types of contactless payment technologies. 

X-Pays

If you are a card issuer in today's world, you usually need to implement ApplePay and GooglePay to let your users benefit from various payment activities on mobile phones. We think it is obligatory in today's world for standard card use cases. The power of Apple and Google is so strong that avoiding these platforms really impacts your customers.

In general, implementation of these technologies is not difficult. If you use our Token Management Platform, implementation time can be reduced to weeks. Additionally, you have to sign contracts with Apple and Google. In the case of Apple, they charge additional fees for registering a card at ApplePay. In the case of Google, they collect all transactions of your users to earn money on advertisement and data management. These are key disadvantages. In both cases you have to follow their requirements and changes, but if you cooperate with certified providers, you do not have problems with this, as a processor can solve these problems on your behalf. 

Both Google and Apple solutions enable contactless, inApp and eCommerce payments on their browsers. The non-contactless payment transactions are an important part of these projects. You should focus not only on contactless payments. 

It is worth mentioning that implementation of tokenization usually gives you access to other X-Pays like Fitbit Pay, Garmin Pay or others. They are much smaller companies and we treat them as nice-to-have in card issuing projects today. 

Issuer Wallet SDK

Before Apple Pay and Google Pay appeared, both Mastercard and VISA invented other ways of contactless payments on mobile phones. They were called differently, but today they are mainly called Issuer Wallets. In such cases you do not sign contracts with Apple or Google, but you implement technology (both mobile SDKs and backend) that allows you to go live with contactless payments on mobile without signing contracts with Apple or Google. Actually it was possible for Android only, but recently (2023/2024) Apple allowed non-ApplePay contactless payments on iPhones in the European Union.

In such cases you need to get and certify SDKs and backend components to go live with contactless payments. Such developments usually take 12-24 months and the software must be kept updated all the time, so it is actually better that you try to use a certified partner for this activity to avoid on-going development costs just for your project. From a contactless use case perspective, transactions work in a very similar way to X-Pays, but you have more flexibility. On Android, for example, you can implement a contactless payment just after unlocking the phone screen. You can - but do not have to - ask for additional authentication. You are also sure that data of your users and their transactions will not be shared with external entities (Apple and Google) for their benefit. 

A big advantage of the Issuer Wallet SDK is that it can work not only on Android phones - for example, we have live implementations on Huawei devices. This detail has an important business impact on your users. 

In today's world, working with Apple or Google is obligatory in our opinion, but we strongly recommend implementing Issuer Wallets at the same time, as it will give you more flexibility and business security in the long run. The costs and processes do not differ a lot, but the additional benefits of an issuer wallet such as flexibility, more devices, lower transaction costs make it worth implementing. 

Thanks for reading. 

NFC on iPhone/iOS

What happened?

As part of an agreement between the European Union and Apple, Apple has decided to open access to its NFC module to 3rd party developers. It allows the creation of solutions for contactless payments (HCE), an alternative to Apple Pay.

This article aims to explain the challenges and opportunities related to this technology.

How it works?

What are the differences compared to Android?

Since 2013 Android allows implementing alternatives to Google's own Google Pay, and there are already a few mature solutions on the market. Apple's NFC API offers very similar capabilities from both a technical and user experience perspective. However, there are a few differences:

What are the differences compared to Apple Pay?

Apple's API allows 3dr party developers to implement most of the functionality offered by Apple Pay. Two slight differences are:

Will it work outside the EU?

Companies registered in the European Economic Area can offer this functionality to customers based in EEA. The table below shows various combinations of companies wanting to offer HCE payments in their App and customers, and the expected outcome according to Apple's requirements.


 Company developing App established & licensed for payments in EEA
 Company developing App not present in EEA or not licensed for payments in EEA 
EEA citizen, transacting in EEA country
 ✅HCE available
 ❌HCE not Available
EEA citizen, transacting outside EEA (traveling)
 ✅HCE available ❌HCE not Available

non-EEA citizen, transacting in EEA country (traveling)

 ❌HCE not Available ❌HCE not Available
non-EEA citizen, transacting outside EEA country ❌HCE not Available ❌HCE not Available

Pay by Account - NFC from bank account

As we have done several Pay by Account projects I would like to share some information what is the best way to implement such solution. 

Pay by Account or in other words mobile NFC payments directly from bank account is an important product development step for many local schemes. Usually it is not enough to enable money transfers, QR payments or bill payments and it would be beneficial to make use of global authorisation and clearing network of Mastercard and VISA. In such case users of local schemes like BLIK in Poland or PIX in Brasil could be using or are using mobile phones to pay globally. 

The solution is not difficult to implement using virtual cards and some local settlement ideas. There are the following architectural components:


image-1713005793559.png

Key implementation steps are the following:

  1. Every user interested in using contactless, eCommerce, or inApp payments will get hidden virtual payment token
  2. Token will be tokenised at mobile phone of the user (usually Issuer Wallet SDK) and will be used for payments on standard Mastercard or VISA acceptance network
  3. In case token is used to do domestic transactions at acquirers and terminals integrated with local scheme, authorisation and clearing will be routed to local scheme
  4. In case token is used for international transactions, globally, at any terminal in the world, authorisation and clearing will happen via standard Mastercard or VISA settlement network

To enable this project you need to have virtual card issuer or card issuing processor with super low fees per card - test us :)  You will also need some support of Mastercard or VISA to agree on such processing mechanism. Additionally certified SDKs and backend components for contactless payments will be necessary (we can provide as well).

There have been already several implementations of similar schemes in the world. We are happy to discuss this setup in more details. 

Thanks for reading.

On-device tokenization in India

Payment law in India required a few years ago that server based card-on-file systems are not allowed. Instead, there is a necessity to store user data on-device to perform transactions. 

This is an interesting topic that impacted a lot of local players like big merchants, Cred, Phonepe or Amazon so let me describe it in some details because maybe it will be implemented in a few years in other countries as well. 

Requirement for storing tokens in a secure way on customer devices forces us to implement and certify secure SDK in which payment token data will be saved. It is a similar concept to standard HCE (Host Card Emulation) implementation for mobile NFC payments. While registering to a merchant or wallet system, the user adds a payment card, performs tokenization with approval (One-Time-Passwords) of the issuing bank and the token connected with his card is stored in this wallet / SDK.

Once we have a secure place of storing the user's token on his mobile phone we can use this token for multiple purposes:

  1. NFC / contactless payments - the user uses his phone to perform transactions on a contactless acceptance network. Token and payment keys are transferred through the contactless interface to the payment terminal and acquirer for authorization.
  2. inApp - the user chooses products and adds them to the basket in the merchant app, clicks that he wants to pay with a particular wallet or payment brand and confirms the transaction in a wallet app. The token is taken from an SDK, transferred to the cooperating acquirer in the form of a DSRP message (Dynamic Secured Remote Payment) and processed in standard way
  3. web purchase - the user chooses products and adds them to the basket on the merchant website, clicks that he/she wants to pay with a particular wallet or payment brand and receives a push notification in his/her mobile app to finalize the transaction. As above, the token is taken from an SDK, transferred to the cooperating acquirer in the form of a DSRP message (Dynamic Secured Remote Payment) and processed in standard way. There could be a possibility to store the token inside the browser of the user on his laptop / PC but this requires more discussion with Mastercard and VISA.

To enable these use cases, several implementation points needs to be considered:

This is an interesting development and area of work. We are live with a few partners and are happy to work with new ones. Please contact us if you are interested.

Thanks for reading.