Overview

Here is a short overview of the technical steps which need to be taken on backend and mobile side to allow your users to integrate their credit cards into Apple Pay and Google Pay.

Steps on Backend

Provide TOTP cardSecret and cardId
Integrate mandatory user notifications

Steps on Frontend

Optional: Integrate overview of status of Apple Pay / Google Pay integration for different cards of the user

Steps on Mobile App(s)

We have detailed guides for mobile development for iOS and Android.

Integrate MeaWallet Push Provisioning SDK
Integrate required splash screen for Apple Pay

To better understand the overall process, let us first define some common terms.

Term	Description
VTS	Visa Token Service. The service provided by VISA to allow mobile payments with VISA credit cards. This service is used in the background to tokenize the card details. The Visa Token Service replaces sensitive account information, such as the 16-digit primary account number (PAN), with a unique digital identifier called a token. The token allows payments to be processed without exposing actual account details.
Mobile Wallet	The wallet on the smartphone in which the credit card is stored for paying with Apple Pay or Google Pay.
Token	A unique representation of a single credit card. Used instead of the PAN which is printed on each card.
Tokenization	The process of creating a token from a given PAN of a single credit card.
Provisioning	The process of adding a credit card to a given mobile wallet.
Push Provisioning	The process of adding a credit card to Apple Pay or Google Pay, starting from the mobile app of the partner. The credit cards is pushed into the respective wallet.
MPP	MeaWallet Push Provisioning SDK - the SDK that allows you to use the provisioning/tokenization within your own mobile app.
Green Flow	An already authenticated user starts the push provisioning flow. There is no need of a separate authentication.
Yellow Flow	A not authenticated user starts the provisioning flow from the mobile wallet app (Apple Pay or Google Pay) and there is the need of further authentication of this user. The backend systems from VISA decide if a additional authentication is required. If additional authentication measures are taken, the user has to provide a one time password (OTP) when adding the credit card to the mobile wallet.
Red Flow	The tokenization is declined by VISA and the process has to be restarted.
OTP	One Time Password - a single use password to authenticate a user. The one time password is provided either by VISA directly via SMS (Google Pay) or you as a partner have to provide it via email or SMS (Apple Pay).
TOTP	Time-based One Time Password - a single password which is only valid for a short amount of time, usually some minutes.
PAN	Primary account number, the credit card number on each card.

Implementation Overview

The schematic overview above shows the different parts of the implementation.

Mobile App(s)

For the mobile apps, please see our detailed sections about Apple iOS and Google Android.

Backend

Subscribe and listen to our callbacks regarding status changes of the card provisioning
Subscribe and listen to the callback containing the OTP the user needs to complete provisioning on Apple devices if the yellow flow is chosen by VISA.
- Send OTP to user via email or SMS.
Implement Pliant APIs GET endpoint to fetch data about provisioned cards and the mobile devices itself.
Apple: Send confirmation email when tokenization is successfully completed.
Apple: Provide an endpoint for your mobile app to decide if a splash screen needs to be shown to remind the user to provision a credit card.
- This is part of Apples certification process: a user that has not provisioned a card yet needs to be reminded for the first 3 months to do so. Provisioned cards are those with provisioningStatus being either TOKEN_PROVISIONED or TOKEN_ACTIVATED. You can get this data from the callbacks and from the GET endpoint.

Frontend

Optional: show information about the provisioned cards of the user or organization.

Flow Overview

Starting from the partners own mobile app (Green Flow)

(Your Mobile App) User initiates the Apple Pay / Google Pay provisioning by clicking a button in the app.
(Mobile Wallet App) User confirms the card details for the card that has been selected to be added to the mobile wallet.
(Mobile Wallet App) User confirms T&Cs.
(Mobile Wallet App) In progress screen during which token provisioning / authentication takes place.
(Mobile Wallet App) Confirmation screen that provisioning has completed successfully.
(Your Mobile App) User is redirected back to your mobile app, you may also show a confirmation dialog.

Green Flow Status Changes

During the Green Flow, the status changes for provisioningStatus are as follows:

TOKEN_CREATED - The token has been generated for the selected card.
TOKEN_ACTIVATED - The token has been successfully activated, marking the final status for this flow.

Starting from the Apple / Google Wallet on the mobile phone (Yellow Flow)

User initiates the provisioning in the mobile wallet app (Apple Pay or Google Pay) and manually enters the credit card details.
User chooses the provisioning method.
Tokenization process takes place.
1. As part of this, you may receive a OTP (one time password) which needs to be forwarded to the user by an appropriate method (email, push notifications, ...).
2. You may not receive an OTP for all yellow flows, since the cardholder selects the method they want to receive the OTP in the mobile wallet themselves. If they select SMS, the SMS is sent by our processor Thredd immediately. Only if another method is chosen Pliant receives the OTP and forwards it then to the partner as a callback.
User receives the OTP.
User enters the OTP on their mobile device.
Visa validates the OTP and activates the new token, thus adding the card to the mobile wallet.

Yellow Flow Status Changes

During the Yellow Flow, the status changes for provisioningStatus are as follows:

TOKEN_CREATED - The token has been generated for the card.
TOKEN_PROVISIONED - The token has been provisioned and is ready for further verification.
PASSCODE_SENT - An OTP has been sent to the user via the chosen delivery method.
Final Status Options
1. TOKEN_ACTIVATED - If the user enters the correct OTP, the token is activated successfully (final status).
2. TOKEN_ACTIVATION_FAILED - If the OTP verification fails, token activation fails, marking this as the final status.

provisioningStatus behaviour (Card Added/Removed to Wallet)

Here we describe the behaviour of provisioningStatus and tokenStatus in relation to card changes in the wallet.

tokenStatus changes to ACTIVE: the card is added to the wallet
tokenStatus changes to DELETED: the card is removed from the wallet
tokenStatus changes to SUSPENDED: the card in the wallet is locked. (should be reflected in the wallet)

Note: the provisioningStatus should not change anymore after it became TOKEN_ACTIVATED.

Associated Email Notifications

Based on the behaviour described above, the following notifications are sent.

Card is added to the wallet: email sent
Card is locked/unlocked: no email sent
Card is removed from the wallet: no email sent
Card is added to the wallet again: email sent