Issuer Wallet and Apple Pay / Google Pay - 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 Apple Pay and Google Pay 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 Apple Pay. 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-Apple Pay 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. 

Read more: Push Provisioning to Google Pay and Apple Pay

Thanks for reading.