Identity & Verification Methods
Yellow path decisions trigger the identification and verification process of the cardholder through one of the available activation methods.Activiation methods are configured by MeaWallet based on options Issuer has communicated that they will enable. If the issuer decides to implement further activation methods post implementation, it is their responsibility to communicate with MeaWallet about this.
Token Service Providers are the primary entities describing the supported activation methods and then it is between their requirements and issuer willingness to implement certain set consumer activation methods. Excluding the type of tenured channels for communication between the issuer and cardholder there are following three types of activation methods are foreseen:
- Passcode;
- Issuer Mobile Application;
- Call center.
Retriever Contact Data API (Issuer responsibility)
If a cardholder chooses to authenticate themselves using activation codes the Issuers will have several responsibilities. Issuer has access to cardholder information which MeaWallet does not and therefore relies on Issuer to complete this process. The first responsibility will be to retrieve cardholders contact data from the issuer systems and return that information back to MeaWallet in Retrieve Contact Data response. Issuers can either use Token Unique Reference, CorrelationID or CardInfo to identify the contact data depending on how the Issuer decides to create their implementation.
Mask pattern for cardholder contact details
There are no specific requirements issued by the payment network or third-party wallets on how to mask the cardholder contact data. However we recommend to use the following approach:
E-mail - First two characters remains of identifier remains as is, rest is replaced with the *. Domain remains unchanged.
Example: ag*****@gmail.com
Phone number - Mask all digits with the * except the last 4. Leave hyphens if applicable.
Example: **-***-****-1234
Send Passcode API (Issuer responsibility)
Passcode can be also referred as One-Time Password or activation code. Passcode have the following properties:
- Human readable passcode
- Usually 6 digits long
- Generated and validated by TSP
Issuer will receive the passcode through the Send Passcode request, it is the Issuer`s responsibility to forward this to the cardholder. Issuers can either use Token Unique Reference, CorrelationID or CardInfo to identify the contact data depending on how the Issuer decides to create their implementation. Certain TSPs also allow the issuer to generate and validate passcode on their behalf. Activation code can be presented as a different activation method based on the channels how it is provided to the consumer. This may be an SMS text message, E-mail or inbound call to the cardholder.
Issuer Mobile Application
Activation by the mean of issuer mobile app. Depending on the context this activation method can be also referred as an "In-App Verification".
Activation from issuer mobile application require the secure authentication of the cardholder into the application. Token Service Provider may offer different options for the token activation in the back-end. MeaWallet recommends to use the consolidated method for all available TSPs using the Customer Service API Token Activate request.
This is prohibited to offer the issuer mobile application activation method to the cardholder if request is initiated by the push provisioning.
Issuer mobile application must be additionally integrated with the selected third-party wallets according to their specifications in order to support such activation method.
Call center
Cardholder outbound call to the call center. This is mandatory activation that must be supported by all issuers. Call center authentication is not allowed to be displayed as a default step-up authentication choice by all third-party wallets. This is done because third-party wallets often deem call center authentication as bad customer experience. This may be displayed as an additional, fall-back or backup activation method. Issuers call center staff must have availability to systems which are able to do token life cycle management. An example of such a system is the Mea Service Portal.
Issuers staff might also be required to be fraud trained. This is due to requirements by third-party wallets like Apple Pay which require that authentication for seemingly fraudulent provisioning is authenticated through fraud trained call centers. These seemingly fraudulent digitizations are often referred to as orange flow.