Security

For the VIPASO system (mobile applications and backend) security is one of the most important features that has been developed. VIPASO provides security on different layers of the system and all customers and their data are secured. It provides security in the mobile applications, in the communication between the server and mobile apps as well as on the backend of the system. All security aspects have been built with PSD2 in mind and are fully in line with the directive.

In-App Security

Regarding mobile applications, security refers to keeping user data and credentials secure and providing an extra layer of security (biometrics & PIN) for unlocking and accessing applications. All user data that is kept in the application (user token, username, PIN password) for the user are placed in the local keychain storage encrypted with AES algorithm standard. This means that without a key and algorithm no one can access the user data from the local storage.
Another security layer in the application is added on unlocking the applications. Users have to lock their application by entering a PIN code and can also allow the applications to use biometrics authentication from the device. So each time an application runs in the background mode or the user runs an application again after some period of time, they need to enter their PIN code or unlock the application with their biometric data. This security step is a must when users authorize their payment.
One more security layer inside the application is added to the login process. No one is able to log in using another email address or phone number because there is an account recovery process. Each time a user wants to log in again to the application (after she reinstalls the application, or if she logs out from the app), she needs to recover the account step by step. First she enters an email address or phone number and after that she receives the OTP code on her phone number or an email confirmation link. It is made sure that the user accounts and data are fully secured.

API Calls

The most important security feature in the system is the communication with the server. All the API calls, especially ones that contain sensitive data for the user, are encrypted. For example, API calls that are considered to be sensitive are and of course encrypted are the ones that return the user profile and the consumer ID (e.g.: credit card number/PAN parts, MSISDN, account number parts, ...) and all API calls regarding payment and transactions.
The logic used behind the API call encryption is standardized by the AES algorithm. The data that is being sent to the server and the system retrieves the data to the mobile applications from the server using HTTP requests over TLS (HTTPS). For authentication and signatures private and public keys are used that are generated from mobile app certificates after the user installs the app for the first time. In the registration/recovery process public keys are sent to the server and signed by the VIPASO backend, so the backend can verify the mobile apps data using the asynchronous signature verification algorithms. On the other hand the mobile apps use their private keys for signing, so without that pair of private/public keys no one can abuse user data.
Also all API calls are authorized with a customer token, and every application can have only one valid token. If a user recovers her account on another device, the token will be invalid automatically and after the recovery process she will get a new one.

Backend Security

The most important security principle for the VIPASO backend services is the principle of least knowledge. Hence all sensitive payment data is not stored anywhere in the VIPASO system but at the payment service provider (e.g.: bank, MNO, PSP). There is no data stored on any VIPASO database, which could plainly (without the proper credentials of the payment service provider) be used to initiate a payment from or to any of the VIPASO system participants.
There is, however, some information needed for the VIPASO backend system to initiate a payment with e.g.: the PSP. This is the merchant ID and/or shop ID of the merchants at the PSP to identify the payment receiving party on the one hand and the token of the payment method of the consumer at the PSP on the other.
Since even only the tokenized ID of the payment method is considered sensitive information to us, the system additionally AES encrypts the user’s payment method tokens upon reception from the PSP and stores it separately in a dedicated database.