Types of mobile wallets
Before you decide what type of mobile wallet you will go for, it makes sense to get an overview of what types of mobile wallets exist and which one is right for you.
OEM wallets
OEM wallets or XPay wallets are the most common wallet implementations. They are associated with or tied to a certain device manufacturer, the most prolific being Apple (Apple Pay), Google (Google Pay), Samsung (Samsung Pay), and Huawei (Huawei Pay). Certain wearable manufacturers such as Garmin and Fitbit also have a proprietary mobile wallet on their smartwatches.
Here is what you should know when it comes to the differences (as per 3/2023) between the four major OEM mobile wallets:
There exist many more differentiating nuances for the cardholder. For example, Google Pay might be easier to use while Apple Pay has more features and does not track any transactions. Practically, however, since the proprietary wallets tend to be tied to a mobile operating system, the choice of wallet is predefined by the device the cardholder owns.
As a card issuer, your choice of mobile wallet implementation will primarily come down to which solution is available in your country. If multiple wallets are available, implementing them all will let you offer mobile payments to more customers. If you want to get started with just one OEM wallet, it makes sense to pick the wallet most suited for your market. If, for example, people are mostly using Android-based phones in your country, picking Google Pay is the correct choice.
OEM wallets allow users to add cards from multiple banks to the wallet application. OEM wallets come pre-installed on the cardholder’s device, making it easier for the cardholder to use the issuer’s card for mobile payments.
Issuer-branded wallets
An issuer-branded wallet is a custom-made mobile payment application (MPA) to be used by one specific issuer. It adds to the functionality of, e.g., an existing banking app. Unlike OEM wallets, cards can be issued, stored, activated, and sent to the mobile wallet within the same application. As with OEM wallets, users can choose the mode of authentication and use their cards for contactless payments. You can design an Issuer-branded wallet to reflect your company’s look and feel to guarantee consistent branding throughout your application. The MPA can be combined with the issuer’s existing application(s) a separate, dedicated mobile payment app. Compared to the OEM Pays, this supplies a more flexible user experience, design, and user interaction.
Which wallet implementation is right for you?
The two options supply different opportunities to issuers. OEM Pay can give the user a more seamless experience, as all cards are in one application. Issuer Pay can give the issuer more flexibility and possibilities, especially in terms of value-added services and user interaction.
The following table highlights some of the key features and differences between OEM Pay and Issuer Pay. 
Branding options are particularly good for Issuer Pay as the issuer controls the mobile application and the user experience. With OEM Pay, the issuer has limited branding possibilities through card art and other available interfaces.
Issuer Pay allows for a simplified user experience and onboarding, the possibility to add other services to existing applications and the choice of which technology to use.
The cost question is a bit more nuanced. On the one hand, while there exist turnkey SDKs for issuer pay, the integration with the banking app requires careful planning, time, and effort to get the user experience exactly right. OEM Pay only requires you to make your cards available to be added to the wallet. On the other hand, opening a project with, e.g., Apple has a high fixed price tag in addition to Apple’s cut for each transaction.
In terms of risk and opportunity, OEM Pay lets you, for little effort, be one of potentially many cards your customer might be using in a very user-friendly package. If you want customers to use your card exclusively, Issuer Pay is the way to go. For that to succeed, though, the user experience and additional features of your banking app must exceed the value that comes with the versatility and ease of use of an OEM wallet.
Combining Issuer and OEM Pay
It might make sense to offer both issuer and OEM Pay in certain situations. For instance, in a country where Apple Pay is available, but not Google Pay, offering both an issuer wallet for Android and Apple Pay for Apple platforms would allow you to cover a wider market. The expense might be worth the cost if you are looking for a competitive advantage or leadership in the mobile wallet space. For example, introducing an Android issuer wallet is more lucrative in a market where the number of people using iPhones and Android-based phones are about equal, compared with a market where only 10% of people own Android phones.
Mobile wallet features and requirements
Tokenization
(OEM wallets and Issuer wallets –required)
To digitize your cards for use in a wallet, they must go through a process called tokenization. Payment tokenization is a security technology where sensitive card information is replaced with a unique digital identifier (a token) to process payments without the need to expose card data.
Another significant security benefit of tokenization is the fact that a token is only valid in a specific context. This may be a mobile device, a smartwatch, or a particular merchant. Outside that specific area, the token is useless and cannot be misused. In practice, this means that a card account can have multiple tokens used for different purposes, e.g., one token for your mobile wallet, one for your smartwatch and one for a streaming service or travel ticket app. All major payment schemes like AmEx, Mastercard and Visa have developed their own Tokenization systems to support card tokenization and require that you have the means to turn your cards into tokens in place.
Push provisioning
(OEM wallets –required I Issuer wallets –recommended)
There are two ways a cardholder can add their card to a digital wallet. The manual way will require all involved parties (wallet provider, payment network, issuer, and cardholder) to follow up with a tedious and time-consuming verification process to ensure the legitimacy and authenticity of adding a card. This process leads to a higher threshold for the cardholder to engage. The reasons could be a lack of trust in the system, worrying about making mistakes, and failure to follow up on the required step-up ID&V process. The alternative is called push provisioning and is often required by OEM wallet providers. Push provisioning simplifies and accelerates card issuance to digital wallets for the cardholder and helps wallet providers to acquire new customers. Instead of having to go through a lengthy authentication process and manually entering credentials, users can just push a button on their phone to activate their token.
Typically, this simplified onboarding results in two to three times as many successfully tokenized cards to digital wallets compared with manual onboarding.
Token management platform
(Issuer wallets –required)
Tokens are created faster and more regularly than ordinary payment cards. After a while, the large number of tokens will be challenging for your customer support to keep track of.
If you build your tokenization platform or buy it from a third party, make sure there is an easy-to-use, efficient, transparent token management platform in place that lets customer support easily access token data and manage them. Another feature you should look for in a token management solution are built-in analytics and reporting tools that let you gather information on how your customers use tokens and identify opportunities for improvement or new business.
Digital Cards
(OEM & Issuer-branded wallets –optional)
A digital card is a digital version of a physical payment card which can be viewed on, e.g., a mobile app. Having digital card functionality is not required for mobile wallets, but they can complement a card issuer’s offering, especially if they’re a digital-first bank.
Since not every ecommerce site offers the opportunity to pay with a mobile wallet, a digital card supplies all the information needed to conduct the payment, such as the PAN, expiry date, and CVV code. If you cannot or do not want to issue a physical card (to save money or better, the environment), or just want to offer your customers a convenient and more secure alternative to their physical card, we recommend considering digital cards.
Consumer controls
(Issuer-branded wallets –optional)
Today's consumers expect to easily control all aspects of their daily lives in real-time, 24/7, safely and comfortably from their smart devices. Consumer controls allow your customers to manage their tokens on their own. Solutions range from basic functions like activating, suspending, and deleting a token, to more granular customization that lets cardholders define how much money can be spent where, when, and how. That way, consumer controls can create a win-win situation, where the customer can quickly handle simple token-related tasks without having to call the bank, freeing up capacity for customer service. In addition, the enhanced user experience and customizability adds incentive to increase the usage of your mobile or web app for payments and exposure to other services.
How to launch your wallet
The answer to this question depends on the partners you work with, your chosen payment network(s), region, current state of digitization (e.g., whether you are starting from scratch or expanding your existing wallet capability), etc. We will look at an overview of a generic implementation process to give you an idea.
Throughout the process, you will work with
Now that you know your mobile wallets, you might be interested in how to implement yours, what steps are involved and how much time it will take to go to market.
Phase 1: Analysis and planning
During this arguably most challenging and impactful part of the project, you will research the available options, define a budget and production schedule, and make decisions on
- The type of mobile wallet you want to implement
- Which card network(s) to work with
- Which tokenization partner to choose
Where your choice of mobile wallet lands depends on the factors discussed above. When it comes to picking the tokenisation partner, there are several options out there. Issuer processors or payment network can give you some recommendations. Some important questions about your tokenisation partners and whether they will fit your business model you should ask are:
- Can they connect to the card scheme and the mobile wallet of your choice?
- What is the pricing structure?
- Are there setup costs? Is there a lock-in period?
- How much time will it take to implement the solution?
- Is the solution easy to implement? Are there turnkey options?
- Do they offer other necessary or useful services such as push provisioning or digital card functionality?
- Is their solution cloud-native?
Timeframe:
If this is your first wallet, depending on the internal and external processes, this phase, you should factor in up to can take one to two months. Adding further wallets or payment networks to your portfolio should take a fraction of the time.
Phase 2: Development and configuration
he development phase consists of building the mobile wallet environment and
collaborating with the payment network(s) of your choice.
If this is your first wallet, you will need to exchange keys with both the payment network and the tokenisation partner. The development will focus on the implementation of pre-digitisation and token lifecycle management services. The former is a set of processes needed to convert account credentials into tokens, the latter enables the tokens to be generated, suspended, resumed, and deleted. If you are launching an issuer wallet, we are assuming that you have your mobile app that will support the wallet functionality already in place.
Timeframe:
Ca. two to eight weeks for the backend development, four to six weeks for the onboarding and key exchanges (which should be done simultaneously with development to save time), and two to six weeks for continuous testing of the environment setup and integrations.
Phase 3: User account testing
At this point, you, the tokenisation partner, and the payment network will be involved in testing the connectivity, functionality, and integration of the tokenisation platform, to get ready for the production stage and see whether it will hold up to certification standard.
Timeframe:
Most of the testing will take two to eight weeks each but can be done simultaneously. The pre-production testing, which relies on the other moving parts being place, will lag a bit behind and will add around two to four weeks to this phase.
Phase 4: Production
The production phase involves building the final pilot setup, testing the solution outside the sandbox environment and finally the commercial launch.
Once everything including push provisioning and the production pilot are in place, and (for OEM wallets) the specific requirements from the OEM wallet’s side are met, a third-party lab will test and certify the solution. After this final milestone, the wallet will be ready to launch.
Timeframe:
Around eight weeks.
