Skip to main content

Overview

Puran is intended to be a product that provides comprehensive functionality for the mobile end user. The available range of functionality is wide and can be freely modified according to product requirements (for example, a given customer does not want NFC but wants Apple Wallet and Google Pay support). This is made possible by its modular design. Puran's capabilities can be expanded at will using and third-party client SDKs. There is nothing preventing the client API functionality from being implemented as a new module.

Puran's basic capabilities are to provide a consistent and rapid end-user interface to:

  • registration and authentication,
  • user and device pairing,
  • mobile application security support with full biometrics support (including in the form of Apple TouchID and Apple FaceID),
  • support for digitizing and tokenization of payment cards,
  • support for a wide range of payments and money transfers (e.g. NFC, Peer2Peer, QR, PayByLink),
  • eKYC mechanism,
  • support for transaction history with possibility to add attachments such as invoices, receipts, payment confirmations,
  • redeeming of corporate cards,
  • storing loyalty cards,
  • creation of user balance and virtual cards.

Purpose and scope

This product guide provides a high-level overview of Puran product. This document covers the following topics:

  • description of possible configurations,
  • granting access,
  • description of main processes as,
  • additional and optional functionalities.

Terminology

This section explains a number of key terms used in this document.

Name

Description

End-user/User

User using the mobile application.

SDK

Software development kit in  the form of application programming interfaces (APIs) libraries of reusable functions used to interface to a particular programming language (Swift and Kotlin).

MDC SDK

Mobile Data Core SDK.

VCP SDK

Verestro Cloud Payments SDK.

P2P SDK

PeerToPeer SDK.

BC SDK

Business Control SDK.

Available modules

This section of the documentation briefly describes the various available modules that can be enabled within the Puran product. The last part presents the solutions that are currently being produced or are planned to be produced and will be available soon. A more detailed presentation of the various functionalities is presented in the section describing the screens in the application.

MDC

Secure connections to the APIs

The most important module responsible for the security of stored and transmitted user data, including personal information, payment cards and addresses. Creates a secure connection to the API based on a time limited session token. Required for other Verestro’s modules to work because of providing identity confirmation.

Basic user flow

Another functionality provided by the MDC module is handling the end user flow, starting with registration, through the process of pairing the device (password login) and ending with user authentication (authorization of the logged-in application with a pin or biometrics).

Cards management

Using the MDC module, the application can securely download end-user cards from the PCI DSS environment. It is also available to authenticate the card when adding via 3DS (also in V2 version) and to remove all card data from Verestro systems.

Transaction history

Also using this module it is possible to download the whole transaction history of the logged user, regardless of whether the card still exists in the system (it is possible to download the transaction history for a card that has been removed). Transaction history contains the most important information about each transaction, such as date, amount, status, merchant and optionally attachments.

Attachements

The next mechanism provided by the MDC SDK is transaction attachment support. It allows up to 5 (5 per transaction) images related to a transaction to be added on the transaction details screen. This allows, for example, to attach a picture of a receipt or a scan of an invoice. The number of 5 attachments was created in order to be able to attach e.g. several photos of a long receipt or a multi-sided invoice. Attachments can be attached directly using the camera or added from the device memory.

VCP – digitization, tokenization, NFC payments

Digitization and tokenization

The two most important functionalities of the VCP module are digitizing and subsequent tokenization. These processes allow the physical card and its information to be digitized and then a token used for payment to be created. 

NFC

NFC payments are contactless payments that use near-field communication (NFC) technology to exchange data between readers and payment devices such as phone using Puran Application. The NFC module allows you to make payments directly using the Puran app. For technological reasons, this functionality is only available on Android phones. Apple iOS can only use Apple Wallet. 

P2P – peer to peer payments, QR payments, PayByLink payments and receivers

Peer to peer payments

The use of the P2P module allows funds to be transferred between users using the recipient's data. All you have to do is select the card and enter the data of the recipient who is to receive the funds. These functionalities are developed in the Receivers module. 

QR payments

The QR module provides the functionality of using QR codes to process payments. Its operation is intuitive and fast, the recipient of the funds on the QR screen enters the amount they wish to receive and the sender, using our application (this is important, you cannot use an external QR code scanner) simply scans the code and confirms the payment. 

PayByLink is a module designed to create payment links that can be used for a limited time. On the corresponding screen, you just need to enter the amount and generate the link. Such a payment link can be sent in any way to the sender, who after clicking it will be taken to the screen with the payment confirmation. 

Receivers

The receivers module extends P2P-related functionality. Its only responsibility is to provide a list of contacts from the device memory and mark which users are using our application. This allows us to select the recipient of the payment without entering their data manually. 

Business Control – business cards and alerts

Business cards

This module allows to receive and activate corporate/business cards and use them for payments like any payment card. Such cards are assigned for a specific period of time and have an amount limit. It is also possible to send a request for increasing the amount limit on the card or extending the validity of the card to the corporation from which you received the card. 

Alerts about business cards

Another of the BC module's functionalities is support for business card notifications. There is displayed a list of notifications for corporate card users about such events as updates of regulations, which acceptance is required for further use of corporate cards or feedback about positive or negative decision on application for card limit increase. 

Antaca – cards issuing and eKYC

Cards issuing

One of the most important functionalities provided by the Antaca module is the ability to create and issue payment cards. Currently only virtual cards are supported, but in the future it will also be possible to order a physical card from the mobile application. 

eKYC

The next functionality that is included in the Antaca module is eKYC.  The eKYC solution offers complete remote identity verification and management. Purana implements the end-user part of the eKYC process for providing identity verification documents. 

Puran – loyalty cards, fitness

Loyalty cards

The functionality of handling loyalty cards is provided by the Loyalty module. Currently its operation is strongly connected with device memory (card data is lost when the device is vaporized) but we are working on creating a solution which will store loyalty cards on a server so that user will always have access to them. This module allows you to scan a loyalty card and create its digital form, so that you can always have all your loyalty cards with you, in our application. 

Fitness

The fitness module allows to pair dedicated sports bands for use during workouts. The data collected in this way can be analyzed and help you achieve your sporting goals optimally. 

Apple Wallet & GPay

The functionality provided by the Wallets module is consistent regardless of the target platform. Their most important functionalities are the ability to add a card to Apple Wallet or Google Pay and to check if it has been added. The card thus re-processed can be used for payments and functionalities provided by these wallets. It is important to remember that adding it to external wallet does not mean that you cannot use it further in Puran app or pay with NFC (Android only).

Security 

The systems offered by Verestro are fully secure, which is confirmed by current third-party certificates. As we store card and payment data we are obliged to comply with strict legal requirements. Card data are stored in a specially designed environment - Data Core. This environment is PCI DSS certified. The PCI-DSS standard guarantees the security of payment card data. It ensures that sensitive information is properly guarded and provides maximum security in the payment process.

We achieve high security standards by, among other things :

  1. Building and maintaining network security - the need to build and maintain a firewall configuration that protects cardholder data, not using manufacturers' default passwords and settings.
  2. Protecting cardholder data - protecting stored cardholder data, encrypting data transmissions when using public networks.
  3. Maintaining a payment management program - using regularly updated anti-virus systems, developing secure systems and applications.
  4. Implementing strong access control methods - limiting access to cardholder data to only those with a business need, assigning each user a unique ID, limiting physical access to cardholder data.
  5. Regular network monitoring and testing - testing security systems and processes, controlling access to network resources and cardholder data.
  6. Maintaining information security policies - relying on security policies for employees and vendors.

The following example shows the connection between the mobile application and the PCI DSS environment to retrieve the end user's card list.

Architecture

Puran uses Verestro's distributed systems to provide the highest quality of service. It is practically the best architectural solution these days. As mentioned in the previous chapter, the communication between services is completely encrypted, maintaining the highest security standards. This kind of system guarantees not only high efficiency, due to the division of responsibilities between the components, but also allows for easy and fast scaling of the system according to the customer's requirements. The state of connectivity between the various parts of the system is constantly monitored, ensuring immediate response to any out of the norm events. We also use tools for storing and processing logs, thanks to which we can provide high quality support and solve any issues in a short time.

Access solutions

This chapter describes possible implementations of the Puran product. We are not limited to developing an entire application, we can provide a customized product based on client requirements and vision. 

Complex solution

The first possible solution for delivering the product is a closed and finished application. This process starts with the creation of a prototype application for the client depending on the modules selected and the branding provided. This solution is entirely contained in the services provided by Verestro. No technical work is required on the customer side.

Application connected to the existing infrastructure

If the customer has already built a working product with its own users, but would like to extend its offer with mobile applications with selected modules, there is also such a possibility. Thanks to the use of a dedicated LC API, it is possible to inject users' mobile applications into the backend to avoid forcing them to re-register. The application is designed and implemented on the basis of the white label in accordance with the client's expectations.

SDKs

Another implementation option is the use of a package of selected SDKs for application. With such an implementation, the use of MDC is always required to ensure the security of data transferred to the backend of selected SDKs. By choosing this option, there is no need to integrate user databases or to set up new accounts by endusers.

Configuration

The following section contains Puran product configuration options that are available by default and can be implemented easily in the application development flow. 

Appearance of the application

By default, the application allows to change the branding, which includes:

  • splash screen (occurs after application launch, before any other screen),
  • colors of application (primary, secondary and accent),
  • text appearance (size, font, color),
  • icons and logos,
  • name (on device and on market),
  • visuals of cards.

Any other change, whether in terms of design or flow/functionality, requires analysis by the technology team. 

For example, adding additional screens during adding a card or additional data fields that are available on the registration screen and then presented in the application. 

User registration and activation process

Possible configuration options for processes related to application access.

Registration

Description

None

The application is open for use in full or limited form without login. This option is not available for some functionalities (especially related to payments and cards).

Open for everyone

Use of the application is possible after registration, which is open to all.

Invitation required

Use of the application is possible after registration, which is available only by invitation code.


Activation

Description

None

Once registration is complete, no confirmation is required to activate account.

E-mail

Once registration is complete, a link is sent to your email address. Its click takes you to a web page (fully configurable HTML) and calls a callback to the server, which will activate your account. Web page can simply contain information about correct account activation or contain content introducing user to the application.

SMS OTP

Once registration is complete, an SMS is sent with the OTP code that is required to activate your account. If the user disables the OTP window during the registration process (e.g. by turning off the application), it will be called again during the login attempt.


eKYC

Description

Enabled

Enabling the eKYC process may be required by some functionality or for legal reasons. Enabling this option forces the user to go through the KYC process through Verestro's internal process - taking a photo of their face and identity document with the mobile device's camera. 

Disabled

The application does not require a KYC process to use any of the features .

Time settings for individual functionalities

Puran has a several default parameters related to the time of each action. Table below describes particular action and time related to the action.

Functionality

Description

Default time on beta environment

Default  time on production environment

Session time

Session after successful login to the mobile application.

15 minutes

15 minutes

Cache lifespan

Specifies how long the cache is considered up-to-date. 

15 minutes

15 minutes

Storage of specific data

This section describes the storage locations for information that is used in the mobile application.

Functionality

Description

User credentials

Only as JWT token. They are not stored in a direct way. 

Identity token

In secured form, one token per user. Logging out removes the token. 

Cards data

As a cache with a specified lifespan in the local database per logged in user. All card data is stored in a PCI-DSS environment.

Loyalty cards

Currently in local device memory, so logging out deletes loyalty cards. In the future they will be associated with the user like payment cards and downloaded from the server.

Requirements for sensitive data

This section contains password and pin detailed requirements. Password has to contain at least 3 of the 4 groups of characters mentioned below.

Functionality

Description

User password length

8-250 chars.

Password requirements        

upper-case letter, lower-case letter, special character and digit.

User PIN length

4

PIN requirements      

only digits.

Permissions

This section contains a list of required permissions and the reasons for using them.

Functionality

Description

Camera

Camera permissions are required for the following processes: eKYC, QR and transaction attachments.

Storage & multimedia

Memory access is required in the process of transaction attachments.

Contacts

Access to contacts is required in the P2P process to download a list of contacts that can be used as recipients of a transfer.

Cache management

In order to provide the user with an application that runs quickly and smoothly, a cache mechanism has been implemented for the most frequently used data. Some card data, transaction history or loyalty cards are cached in a secure way. 

Cache memory is designed to store data that will be processed by the system in a short time. Its main advantage is the speed of writing and reading, so the role it plays determines the performance of the device. This happens, among other things, thanks to the small capacity of the medium. Well, the smaller the amount of space, the shorter the waiting time to find a particular unit. Additionally, cached data is available immediately, regardless of the server response and is refreshed every specified time by special mechanisms in Puran. 

Cache settings are not global, they can be modified per resource, e.g. separately for cards and transaction history.

When modifying data that is contained in the cache, the cache is refreshed, e.g. when card data is modified.

For technological reasons, this mechanism differs between the Google Android and Apple iOS platforms. The following chapters provide an overview of the possible caching options for each execution platform. 

Google Android

Cache strategy

Description

CachedFirst

Tries to get cached data respecting cache status, if cache fetch fails (or cache validity expired) then tries to get data online.

OnlineFirst

Tries to get data online first, on fail can throw exception or force fetch data from cache (not respecting cache status), configurable by cachedOnFail argument.

ForceCached

Gets data from cache not respecting cache status.

There are some exceptions in caching e.g. transaction history is currently always loaded from cache and refreshed only when cache expires. 

Apple iOS

Currently, only the default caching strategy is available. It relies on caching as long as it is available and up-to-date. It is possible to manually refresh the cached data by performing a pull-to-refresh action on the appropriate screen, e.g. for cards it is the cards screen, and for transaction history it is the transaction list screen. 

Application delivery for testing and production purposes

Completion of product configuration (T&C regulations, branding, test groups) is required to test mobile applications.

For beta environment testing, it is necessary to provide the project manager information about the email address of tester and device type . This is related to separate app delivery solutions for each platform.

In the case of a production environment, the application is provided by authorized and official application stores dedicated to that environment.

Beta environment

In the initial stages of the project, the mobile application can be delivered as an .APK file to be installed manually on the device. It is also possible to set up an automatic distribution center for test versions, in which case it is enough to provide Verestro with a list of email addresses to which invitations to the test system will be sent. Each user will receive an individual registration link and AppTester software (a fully secure component of the Google Firebase system) or TestFlight software (Apple's standard way to distribute test applications that meet the latest functional and security requirements). Both of the distribution ways allow to download each version of the application and deliver new versions in real time to testers.

Production environment

Once the testing phase is complete, Verestro generates applications that must be signed with the appropriate set of keys and then, using procedures appropriate to the specific distribution site (Apple AppStore or Google Play), added to the app stores. Once the application is in the store, any user can easily and quickly install the application and update it automatically.

Prototype

This section contains a link to the always current prototype. Using it allows you to get to know the presented product better and presents its advantages. 

CLICK HERE TO OPEN PROTOTYPE

Creating a compatible SDK

The mobile architecture of our systems is modular and multilayered, which enables easy and fast integration of new functionalities in the form of SDK. The creation of the appropriate SDK can be handled by Verestro's development team or it can be a customer-provided SDK. It is important that the requirements in the following subsections are met. 

image-1655192332277.png

The first scenario involves using a certificate obtained from the Verestro MDC SDK to authenticate to the client server. This case requires that the servers exchange certificates with each other and the client server can verify the validity of the token. Verestro systems ensure that the token is used by a person authorized to do so and that it is that person's token (i.e., the client server does not need to verify that the user ID=2 who signed up is definitely user ID=2).

image-1655192349087.png

The second possible scenario makes the client server session independent of the JWT Verestro token. In this case, all communication between Client's SDK -> Client's Server relies on client security, which is transparent to the SDK operation in the application and should be implemented inside the SDK so that the session is always available and valid. 

Android

  • Preferred language (at least on the facade) - Kotlin,
  • Exposed methods that take parameters - they should be wrapped in some model (if more parameters are added, compatibility will not be broken),
  • Libraries versions no higher than:
    • retrofit -2.9.0,
    • okHttp - 4.7.2,
    • kotlinCoroutines - 1.4.1,
    • koin - 2.1.5,
    • minSdkVersion - 23,
    • compile sdk - 31,
    • kotlinVersion - 1.5.31,
    • gradle - 4.1.2,
  • Naming methods - any, well described in documentation,
  • SDK delivery - endpoint to artifactory,
  • If SDK communicates with a server - appropriate configuration and a separate endpoint to connect to the server,
  • JWT - issued token parameter in SDK configuration, we pass in header.

IOS

  • Preferred language - Swift 5.6+,
  • Exposed methods that take parameters - they should be wrapped in a model (if more parameters are added, compatibility will not be broken),
  • Naming methods - any, well described in the documentation,
  • Providing SDK - endpoint to be used in SPM,
  • Minimum Xcode 13.3.