# Overview

Verestro Cloud Payments is a solution developed to facilitate adopting cloud-based payments for the Customers. VCP provides functionalities for User identification and verification, P<span class="inline-comment-marker" data-ref="00c599e9-b547-4fea-9719-04f0c5ffafca">ayment Instruments</span> digitization and User data management. Cloud payments enables a card to be digitized into a wallet application on a mobile device and used for payment without the need for a Secure Element (SE) or a Trusted Execution Environment (TEE) to protect the card’s sensitive assets, such as the keys needed for calculating the Application Cryptogram.

Master Keys for the digitized card are kept securely on remote servers(for plastic in the chip), hence the term ‘cloud-based payment,’ and a limited number of keys (where each key can only be used to perform a single transaction) are downloaded to the application.

Solution consists of:

<div class="wiki-content" id="bkmrk-server-components%3A-w">- server components: 
    - Wallet Server - backend component,
    - Wallet Admin Panel - frontend component,
- mobile components: 
    - Wallet SDK - Android libraries.

</div>## Benefits of Payment Token

The MCBP service is an easy and secure way to replace a plastic payment card with a payment token. Recognition to the tokenization and digitization process without leaving the house, we can add our payment card to the mobile application and use only a mobile device during purchases.  
The benefits of tokenization are felt by every participant in the process:  
Issuer - by implementing the tokenization service, it will provide its customers with much higher and safer access to innovative payment solutions.  
Card Holder - can freely use innovative payment solutions. The tokenization service will allow free and secure payments using any devices connected to the internet.

<div id="bkmrk-"><div class="no-print" id="bkmrk--50"></div></div>## MCBP Introduction

Mastercard Cloud-Based Payments (MCBP) is technology which enables a card to be digitized into an application on a mobile device. On plastic card, Master Keys needed for calculating cryptogram are stored in the Secure Element. Using MCBP there is no need for Secure Element since keys needed for calculating the cryptogram are kept securely on remote servers, hence the term ‘cloud-based payment,’ and a limited number of keys (where each key can only be used to perform a single transaction) are downloaded to the application. VCP is solution which provides functionalities for digitization, user data management and payments needed for final Customer to adopt MCBP.

### MCBP High Level Architecture 

[![image-1654374212441.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654374212441.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654374212441.png)

### MCBP Key Components

<table border="1" id="bkmrk-component-descriptio"><tbody><tr><td>**Component**</td><td>**Description**</td></tr><tr><td class="confluenceTd">MPA</td><td class="confluenceTd">Android Mobile Payment Application provides frontend interface to the user and uses part of Verestro Wallet SDK which is responsible for payments using HCE.</td></tr><tr><td class="confluenceTd">Verestro Wallet Server</td><td class="confluenceTd">Provides the backend services to support Mobile Payment Application via Verestro Wallet SDK and is responsible for managing users, devices, cards, Payment Tokens and communication with MDES. Wallet Server acts as Token Requestor on behalf of Issuer in context of digitization.</td></tr><tr><td class="confluenceTd">Verestro Wallet SDK</td><td class="confluenceTd">Provides all functionalities needed for MPA to perform all needed operations related to MCBP.</td></tr><tr><td class="confluenceTd">MDES

</td><td class="confluenceTd"><span class="inline-comment-marker" data-ref="36d623fa-7c74-4f2e-9613-b63fe40f8b02">T</span>oken Service Provider which supports digitization(transforming the card into Payment Token) and is responsible for management, generation and provisioning of transaction credentials into mobile devices to enable simpler and more secure digital payment experience.</td></tr><tr><td class="confluenceTd">Remote Notification Service</td><td class="confluenceTd">Wallet Server communicates with the MPA also using Remote Notification Service. For Android is used Firebase Cloud Messaging.</td></tr><tr><td class="confluenceTd">Issuer</td><td class="confluenceTd">Issuer is responsible for card issuing, accepting authorization digitization requests and accepting transactions which uses token.</td></tr></tbody></table>

## Description

### Wallet Types 

VCP supports following wallet types which can be used in the implementation:

<div class="wiki-content" id="bkmrk-open---user-register"><div class="wiki-content">- OPEN - user registers itself in the application and provides data like PAN etc.,

- CLOSED - user data are passed automatically from Customer servers without User interaction to Wallet Server.

</div></div>### Imlementation Models

Verestro provides two different implementation models for products: integrated <span class="inline-comment-marker" data-ref="97bb34f4-a90b-4656-b137-2dc8cf07e9ca">and standalone version.  
</span>

**<span class="inline-comment-marker" data-ref="97bb34f4-a90b-4656-b137-2dc8cf07e9ca">Integrated</span>**

In this model Customer is owner of<span class="inline-comment-marker" data-ref="ca67dc1a-65a6-4b95-967c-86ec3518a9cd"> MPA</span>. Verestro provides Wallet SDK and Wallet Server. Customer is responsible for direct User authentication and passes the result of the authentication to Wallet SDK. Online operations which <span class="inline-comment-marker" data-ref="8c5d08f8-cc4c-4d8e-bd98-91fb28b5a236">need</span> to be performed by User using Wallet Server <span class="inline-comment-marker" data-ref="678545c4-fe8d-44b3-98cd-4dcad60949b9">require</span> valid session on Wallet Server. To obtain user online session with Wallet Server, Customer needs to pass <span class="inline-comment-marker" data-ref="5b9076ff-0917-4487-be44-a64e16065fb7">Trusted Identity.</span>

**<span class="inline-comment-marker" data-ref="5b9076ff-0917-4487-be44-a64e16065fb7">Standalone</span>**

In this model Verestro provides MPA, Wallet SDK and W<span class="inline-comment-marker" data-ref="fcdb30d1-339e-450d-95c9-fe75ca4949d8">allet Server. Furthermore, Verestro manages direct user authe</span>ntication.

### Architecture

[![image-1654374565801.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654374565801.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654374565801.png)

### Server Components

Server components are applications which <span class="inline-comment-marker" data-ref="22436c7d-9dc1-4a2b-a8cb-a35723fa4ab9">need</span> to be deployed on remote server to make possible to connect them by network.

#### Deployment Models

Verestro offers two deployment models of server components. On-premise and SaaS.

SaaS - Server components are designed to be deploy in SaaS model. In this case everything is deployed and configured on Verestro side. Verestro is responsible for <span class="inline-comment-marker" data-ref="f7c5ee4a-d7b4-436a-a08d-80b848607f95">maintaining</span> infrastructure, deploying applications and monitoring.

On-premise - Server components also can be deployed on Customer infrastructure. Applications are designed to be deployed using [K<span class="inline-comment-marker" data-ref="1af4839c-c21e-48d5-9f9f-fe05e91b4ba5">ubernetes</span>](https://kubernetes.io/) as system for automating deployment, scaling, and management of containerized applications. For more details please contact Verestro representative.

#### Wallet Server

<span class="inline-comment-marker" data-ref="6de4aa14-4355-42f7-970f-97f5fbc774f5">Wallet Server - is backend component which consists of few internal services which are responsible for managing users, devices, cards, Payment Tokens, transaction history. It acts as Token Requestor on behalf of Issuer and is c</span>ompliant with PCI Data Security Standard.

<span class="inline-comment-marker" data-ref="6de4aa14-4355-42f7-970f-97f5fbc774f5">It exposes:</span>

- mobile API - available via Wallet SDK to <span class="inline-comment-marker" data-ref="71d24dfa-36a8-4b47-a3d6-f2fdb1a6c280">performs</span> operations directly from mobile device,
- LC API - server API dedicated for Issuer to manage users and cards data on Wallet Server,
- admin API - server api dedicated for admin panel frontend,
- MDES Outbound API - server API dedicated for MDES.

Wallet Server operates with domain objects like:

- User - root of entity tree. User is identified in Wallet Server via some unique identifier which can be external id given by Customer. User can have access to his data and operations based on session. Session is created after paring device and when is expired then User authentication needs to be performed. <span class="inline-comment-marker" data-ref="97ec29d9-de8d-4868-888a-c76e7541e8ed">Session</span> is valid <span class="inline-comment-marker" data-ref="5438ae1f-0b85-4eac-95d8-91ea909c9108">configurable period of time</span>.
- Device - belongs to User. When User starts using application after installation then device pairing is performed. After pairing device with some unique id(constant across installations and users<span class="inline-comment-marker" data-ref="96df8e20-0f99-4db1-b1e7-2443aefc1aac">),</span> unique device installation id is generated and this installation is assigned to particular User. It is possible to have one active installation on specific device for specific User. If other User starts using application on same device then another device pairing is performed and all data from previous installation will be wiped.
- Card - belongs to User. User can have many cards. Card is identified via internal id given after storing card on Wallet Server. Whole PAN is stored on Wallet Server(always or short period of time). <span class="inline-comment-marker" data-ref="2bb6aa0f-4f38-4e08-9711-0d3f3e32e839">  
    </span>
- Payment Token - after PAN digitization, device Payment Token is created also on Wallet Server side without any sensitive data. One PAN can have one device Payment Token on specific device installation at the same time which is INACTIVE, ACTIVE or SUSPENDED.

[![image-1654374710316.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654374710316.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654374710316.png)

#### Wallet Admin Panel

Web frontend application which is dedicated for back office to manage all User data.

### Mobile Components

<div class="wiki-content" id="bkmrk--3"></div><div id="bkmrk--4"><div class="no-print" id="bkmrk--51"></div></div>#### Wallet SDK

Verestro provides Software Development Kit (SDK) called Wallet SDK which can be used in Mobile Payment Application. As a compan<span class="inline-comment-marker" data-ref="b105c2cb-2e1d-4eae-bb0e-e9dc00fcfacb">y</span>, Verestro provides many products which can be used in single application. For that reason Wallet SDK is divided into separated modules which covers different functionalities. There are two main modules dedicated for Verestro Cloud Payments: MDC SDK and UCP SDK. <span class="inline-comment-marker" data-ref="9c246dbd-27f5-45b6-b4c9-06bda9d2beec">MDC SDK is core Verestro module responsible for user data management: authentication, payment cards management - since these are main functionalities used in every product. </span>UCP SDK is dedicated for performing digitization and payments using Payment Token. In payment context UCP SDK wraps <span class="inline-comment-marker" data-ref="495056b6-b208-4f08-8c75-91ff9e8248d9">Mastercard</span> Cloud Based Payment SDK.

<div class="wiki-content" id="bkmrk--5"></div><div id="bkmrk--6"><div class="no-print" id="bkmrk--52"></div></div>#### Requirements

Wallet SDK has some mandatory requirements to make it work:

- device cannot be rooted,
- Android OS image (ROM) should be genuine in version 6.0 (Marshmallow) or above,
- devices cannot have enabled debugging.

There are also some not mandatory requirements, but Customer needs to be aware of them to maintain functionalities:

- NFC module necessary for HCE payments,
- lock screen necessary for locally-verified user authentication.

#### Security

Wallet SDK was developed according to security requirements included in Security Guide MCBP SDK for Android. However Wallet SDK cannot guarantee full MPA protection and MPA must provide additional layer of security to protect user interface(mainy when PAN is manually entered in the application) and data processing within application. More detailed information can be found in *Wallet SDK API.* Moreover all sensitive data are passed as chars or bytes arrays. Wallet SDK copies the arrays and clears that copies just after processing. MPA should clear provided sensitive data immediately after passing them to Wallet SDK.

Security Checks and Data Clearing

On Wallet SDK side are pe<span class="inline-comment-marker" data-ref="c6e0f391-dfd6-48b3-b5b8-929a7da5ea81">rformed security checks which includes static</span> code analysis protection and dynamic analysis protection. Security checks consists of:

- root access detection,
- hooking protection,
- debugging protection,
- custom ROM protection,
- data tampering protection,
- man in the middle protection.

Security checks are performed periodically, if Wallet SDK detects any of above things all data hold by Wallet SDK will be cleared and security report will be sent to Wallet Server. MPA will be informed about such detection.

Communication with Wallet Server

Communication from genuine applications which are installed on genuine devices is accepted by the Wallet Server. Wallet SDK at the very beginning performs authentication of application and device to Wallet Server. This authentication may takes advantage of Google SafetyNet which is 3-rd party trusted side in whole authentication. Google SafetyNet <span class="inline-comment-marker" data-ref="b3d47876-5075-4e2f-a0f9-700fc4f6f788">verifies</span> device and sign information about device and application. Signed data from SafetyNet are sent to the Wallet Server. Wallet Server verifies data and allow or does not allow for further communication. Application is verified according preconfigured application certificate digest used for signing application.

Important: There is a limit of requests to SafetyNet API: 10 000 per day. If Customer predicts that there will be more installations per day then this limit needs to be increased during Google Project Setup.

Wallet SDK communicates with Wallet Server using TLS 1.2. Wallet SDK performs public key certificate pinning when it tries to establish connection with Wallet Server (similar with connection to MDES). Certificates for the pinning needs to be provided to SDK. Sensitive information are additionally encrypted and/or signed.

**Versioning**

Wallet SDK uses semantic versioning. It means that every release has own version which is MAJOR.MINOR.PATCH, where:

- MAJOR version increases when SDK has incompatible API changes,
- MINOR version increases when new functionality is added in a backwards compatible manner,
- PATCH version increases when new backwards compatible bug fixes are introduced.

MAJOR versions are supported 6 months and Customer needs to migrate to new version if they want to maintain support.

#### Remote Notification Service

Wallet SDK is responsible for remote notification processing. However MPA is responsible for obtaining FCM registration token, handling FCM token update and receiving remote notifications. Before passing remote notification to SDK, MPA needs to verify if given message is dedicated for SDK by checking sender Id. Sender Id is configured during onboarding. Verestro will create new FCM project and provide data needed to obtain FCM token for given project. Due to observing some issues with FCM token refresh notification from FCM service, additional check of new token availability is recommended(eg. on application start). See more in *Wallet SDK API.*

#### Access

Wallet SDK is stored as artifacts in maven repository. Access there is provided during onboarding by Verestro representative.

### Configuration

Whole product has configuration which needs to be fulfilled. This configuration also consists of data which are set in MDES. More details are described in *Wallet Configuration*.

### User Experience for Contactless Transactions

MDES offers a few options for customers for defining user experience for contactless transactions. Final option is the choice of CDCVM type (Mobile PIN, Locally-verified CDCVM) and CVM model (Always, Flexible, Card-like).

#### CDCVM Types

There are two types of Consumer Device Cardholder Verification Method (CDCVM) which are supported by MDES.

#### Mobile PIN CDCVM

A PIN value (4–8 digits) that the cardholder enters on the mobile device and that is validated online by MDES during the transaction authorization process. Since Locally-verified is mostly preferable option, Mobile PIN is out of scope.

#### Locally-verified CDCVM

A CDCVM entered on and validated by the consumer’s mobile device, for example system device PIN, pattern, password or biometric methods (such as fingerprint, iris or facial recognition). Swipe (slide to unlock) is not a valid cardholder verification method and must not be supported. These methods are commonly associated with a device unlock process and are validated on the cardholder’s mobile device. The payment component embedded in the Mobile Payment Application will use the outcome of this authentication process. A Locally-verified CDCVM applies to all the payment tokens of a given Mobile Payment Application instance (“Wallet-level”). In some parts of system this type is also named as Custom.

### CVM Models

For two CDCVM types customer can apply different user experience CVM Models.

#### Always CVM 

In this model the card profiles supplied to the SDK are configured to indicate that the mobile device supports on-device cardholder authentication. When transactions are performed on a POS supporting CDCVM, the POS will delegate cardholder authentication to the mobile device the terminal will not request an Online PIN on the terminal. In POS which does not support CDCVM cardholder authentication is required using Online PIN. This model requires the cardholder’s mobile device to authenticate the cardholder for all transactions (LVT, HVT, Transit). CDCVM can be performed using either a Mobile PIN or a Locally-verified CDCVM. MPA is expected to decline any transaction for which cardholder authentication is not performed or is unsuccessful.

Below are presented sample diagrams which show how the transactions can look like:

*Always LVT, HVT - single tap*

[![image-1654375111845.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654375111845.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654375111845.png)

*Always LVT, HVT - double tap*

[![image-1654375121955.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654375121955.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654375121955.png)

#### Flexible CVM

In this model the card profile also indicates that the mobile device supports on device cardholder authentication Mobile PIN or Locally-verified CDCVM. However rather than applying authentication for every transaction the MPA defines flexible criteria such as allowing multiple transactions between each authentication. This criteria are often names as Lost &amp; Stolen options or velocity checks. For transit transactions cardholder authentication is not expected.

Below are presented sample diagrams wh<span class="inline-comment-marker" data-ref="eed44fff-027b-4731-bc57-1843d477f863">ich show how the transactions can look like:</span>

*Flexible LVT*

[![image-1654375214373.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654375214373.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654375214373.png)

*Flexible HVT - single tap*

[![image-1654375231686.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654375231686.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654375231686.png)

*Flexible HVT, LVT with Velocity counters - double tap*

[![image-1654375238935.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654375238935.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654375238935.png)

#### Card-like CVM

In this model the card profiles supplied to the SDK are configured to indicate that the mobile wallet is not capable of supporting on device cardholder verification. This means that when transactions are performed with a Point of Sale (POS) terminal, the POS will treat the transaction in the same way as a card transaction. Typically this means that low value transactions (LVTs) will be processed without additional user authentication and if supported, high value transactions will require an online PIN to be provided on POS. This model is put here just for general information, however it is not preferred for issuer wallets.

Below are presented sample diagrams which show how the transactions can look like:

*Card like LVT*

[![image-1654375297218.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654375297218.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654375297218.png)

*Card like HVT*

[![image-1654375302023.png](https://developer.verestro.com/uploads/images/gallery/2022-06/scaled-1680-/image-1654375302023.png)](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1654375302023.png)

#####   


#### Lost &amp; Stolen Options

<span class="inline-comment-marker" data-ref="faaf0ff2-cec6-48f7-917f-e7af19ddfb49">The Lost &amp; Stolen options are dedicated to control performing transactions allowed before requiring cardholder authentication. This limits fraud risk if the cardholder’s mobile device is lost or stolen. Lost &amp; stolen options can be applied only for Flexible CDCVM</span>. These options also are known as velocity check counters. Wallet SDK provides interface which is invoked during transaction. Transaction information like range, rich transaction type, amount are provided within this interface. MPA can implement various checks to support velocity check counters using transaction information. MPA for example can count LVT transactions and allow only some predefined number of LVT transactions without cardholder authentication.

#### Transit Transactions

Transit transactions are transactions with given Merchant Category Code performed e.g. on traffic gates like: underground. It is up to Customer if wants to enable such transactions or not (option selected during MDES onboarding). Transit transactions are enabled in every CVM model, however for Always CDCVM needs to be performed for every transaction, for Card-Like and Flexible CDCVM can be skipped.

### Tokenization/Digitization

Tokenization is a process which enable to replace sensitive data, e.g. card number, with another string of characters - a secure payment token - as a result of which card data remains inaccessible. Payment tokens are assigned to a given device of the card owner, which means that an unauthorized person, even if he obtains the token data, will not be able to use them via another device. It is also secured inside the SDK. As a result of the tokenization process, the customer comes into possession of Transaction Credentials in a mobile application on his device.

![](https://developer.verestro.com/uploads/images/gallery/2022-06/embedded-image-ypcbgte3.png)

#### Digitization decisions

- Green - Approve the digitization request without further cardholder interaction,
- Yellow - Approve the digitization request but seek additional cardholder authentication,
- Red - Decline the digitization.

## Main processes

### User and cards registration into wallet server

User with unique identifier known on issuer side is passing with cards to wallet server. After that process, device can be paired with.

### Pairing device for particular user by trusted identity

Authentication of the device in context of given user. Process needed to allow access to wallet server from that particular device.

In the integrated model signed user identifier passed from issuer into wallet server via SDK is used to authenticate given user.

### Digitization of the card

When device is paired user can have access to his own data: cards. After that he can digitize chosen card which was previously added into wallet server.

### Digitized card profile provisioning on the device

After successful digitization, digitized card profile is delivered to device. Since only limited number of keys for transaction is delivered to the device, SDK calls replenish to cover up the number of transaction credentials.

### Transaction credentials replenishment

### Payment

### Payment history(Optional)

It is possible to store transactions on wallet server.

## Main steps and implementation

Issuer integration with MDES.

- Completing BPMS/ICG file - configuration for issuers in MDES, 
    - PAN ranges allowed for digitization,
    - channel for the authorization cards for the digitization: predigitization API/ISO 8583 messages,
    - digitization path,
- Completing PCG file - configuration for token requestors(wallet configuration), 
    - parameters for connection,
    - transactions user experience,
- Exchanging certificates, 
    - connection,
    - external wrapping key,
    - payload encryption to mdes,
    - tav,
- Adopt LC API to pass users and cards into wallet server and manage them later,
- Integrate SDK into issuer application,
- Implement signing user identity to authenticate user on wallet server via SDK.