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
- NFC on iPhone/iOS
- Pay by Account - NFC from bank account
- On-device tokenization in India
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?
- NFC payments. Users of participating third-party banking or wallet apps can initiate NFC transactions from within the app with compatible NFC terminals.
- Default app settings. Users can choose any eligible app as their default contactless payments app which will enable the app to support Field detect and Double-click features.
- Field detect. The default contactless payments app automatically launches when the user places the device in the presence of a compatible NFC terminal and after user authentication (if the iPhone is locked).
- Double-click. The default contactless payments app automatically launches when the user double-clicks the side button (for Face ID devices) or the Home button (for Touch ID) and after user authentication (if the iPhone is locked).
- Payment support for non-default apps. Eligible apps running in the foreground can prevent the system default contactless app from launching and interfering with the payment.
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:
- Not possible to directly ask a user to set your application as the default NFC payment app - on Android, when users open your app, they can be presented with a dialog window that asks them if they want to use your app, as the default NFC payment app. Apple's documentation doesn't seem to hint at such a functionality.
- Apple needs to give you special entitlement to access the NFC module - without Apple's approval, it's not possible to include NFC payments into your app. This entitlement can be requested here: https://developer.apple.com/contact/request/hce-payments-entitlement/
- Security certification - every app enabling NFC payments needs the EMVCo certification. As NFC on the Apple platform is a new thing, it's still not clear how exactly security certification will look like, however due to fundamental differences between Android and iOS we can expect slight 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:
- Power Reserve Mode - Apple Pay allows payments with the default card for some time after the iPhone battery is depleted.
- Express Transit Mode - allows to pay for public transport tickets in a few areas with compatible cards, without unlocking the iPhone. Full list of locations is available here.
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:
Key implementation steps are the following:
- Every user interested in using contactless, eCommerce, or inApp payments will get hidden virtual payment token
- 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
- 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
- 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:
- 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.
- 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
- 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:
- types of devices - an inApp and web purchase can work on all devices (iOS and Android) but NFC is enabled on Android only. Apple is blocking the NFC access outside of the European Union today.
- VISA vs Mastercard - do you need a solution working for both schemes? Are there any local certification requirements?
- Issuers - are banks ready to connect to your new X-Pay wallet? Which banks are enabled on local markets?
- local on-soil requirements - is there a need to store data in the country? What are the legal impacts?
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.