# 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 payments 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. ![](https://bookstack.verestro.dev/uploads/images/gallery/2022-05/embedded-image-0yuqgojy.png) 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. ![](https://bookstack.verestro.dev/uploads/images/gallery/2022-05/embedded-image-eqj4tjwe.png) # 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. ![](https://bookstack.verestro.dev/uploads/images/gallery/2022-05/embedded-image-hummwitd.png) ## 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. ![](https://bookstack.verestro.dev/uploads/images/gallery/2022-05/embedded-image-mrcew8t6.png) ## 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. ![](https://bookstack.verestro.dev/uploads/images/gallery/2022-05/embedded-image-z4bihn7k.png) # 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**](https://www.figma.com/proto/YEz8pn7pHkuT9J5k62gi1i/Verestro-Mobile-Application-MC?node-id=0%3A1&fuid=961177874964904334) # 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](https://bookstack.verestro.dev/uploads/images/gallery/2022-06/scaled-1680-/image-1655192332277.png)](https://bookstack.verestro.dev/uploads/images/gallery/2022-06/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](https://bookstack.verestro.dev/uploads/images/gallery/2022-06/scaled-1680-/image-1655192349087.png)](https://bookstack.verestro.dev/uploads/images/gallery/2022-06/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.