VIPASO Solution Overview

Suggest Edits
364

VIPASO Service Architecture

The graphic below shows the end-to-end system loop with all the participants of the payment. The flow starts with the merchant initiating a payment request on the VipasoPoS (terminal) mobile app, which starts the payment session in the VIPASO backend system. At the same time the consumer gets the payment request on its VipasoPay (wallet) mobile app and confirms the payment to the VIPASO backend system. The backend now triggers the payment initiation either via PSP, MNO, bank or national payment switch. From there the payment is handled using the standard rails, depending on the chosen payment method (e.g.: credit/debit card, bank account, phone number/MSISDN).

For example, in the case of card based payments (e.g.: Mastercard/Visa transactions), the transaction via PSP is handled like any other e-commerce payment through the established scheme based payment rails with the card schemes and the issuing entity which finally processes the payment from the consumer’s payment credential to the merchant’s bank account.

System Architecture

The VIPASO platform consists of micro-services on the backend that provide a REST API for mobile applications (iOS and Android native applications). The backend system consists of several services for user data, payment and communication with external services.
Users can access all the data they have the permissions for by using mobile applications. All user data including sensitive data is stored encrypted on the server.

Backend services are responsible for the communication with external services. The payment service includes integrations to any external payment services including PSPs, national payment switches, MNOs. The other services are responsible for the security and other API endpoints for the Pay (consumer) and PoS (merchant) mobile apps.

The diagram below displays the entire architecture of the VIPASO system from a high level point of view. The diagram consists of external service connections, payment and app services, the CDN service and the mobile apps.

External services

External services that provide functionalities on the backend and in the mobile apps are:

  • Email gateway: External system for sending emails for user confirmation in the registration and restoration process if configured.
  • SMS gateway: Service for sending SMS messages (OTP codes) for account confirmation if configured.
  • Payment service providers (eg.: PSP, national payment switches, banks, MNOs)
  • VAS service providers (e.g.: couponing/loyalty, cash register, currency conversion)

Payment Initiation Service

Bluetooth Service Communication

This functionality is the most important and most complex one inside the application. This is the case because the Bluetooth and server communication support payment and exchanging transaction data between devices. Via Bluetooth, the Pay and PoS applications are exchanging session ID, timestamp of payment and short commands that are related to the flow in the payment process. Those commands communicate signaling data and synchronize the user experience on both devices. With the help of the Bluetooth technology, the proximity of these two devices to each other is ensured by a managed perimeter.

The entire logic behind payment and exchanging user-sensitive information such as credit card and payment data is established through communication to the server via API calls. All information that the application sends to the server, or the server returns to the applications is encrypted. For example, an application sends an API call to the backend (server) to initiate a payment, or to execute a payment. The server handles that API call and data, and then the server communicates with the payment provider for each payment request or transaction. After the payment provider handles and processes the requests, it returns data to the server, and then it processes the data if needed and forwards it to the applications.
An overview of the logic for Bluetooth and server communication is displayed in the next diagram including an end-to-end payment with user communication.

The payment process and flow consists of communication between mobile apps, payment service on backend and the external payment service provider (e.g.: bank, MNO, PSP, national payment switch). Mobile applications send requests and communicate with the server and payment service. The payment service sends requests and communicates with the external payment service provider. Both PoS (merchant) and Pay (consumer) mobile apps use the same APIs and communicate with our backend. All communication with the payment service provider is done securely through our backend system.

The detailed payment flow between mobile apps and the payment service is displayed on the diagram below:

Payment Service Provider

For payment service provider, we differentiate between PSP, financial institution (bank), national payment switch, MNO and any integrated Fintech, which is participating in the payment flow of VIPASO.

In the following example of a card based payment transaction, the PSP handles all further payment processing after the payment initiation. It combines the payment request with the merchant data and the payment method data and forwards the payment initiation to the acquiring entity in the established payment system. Therefore there is a thorough setup needed with the PSP.

The VIPASO system needs to be connected to a PSP with which all the payment-related commercial contracts have to be established beforehand. Each PSP operates a bit differently and they have different APIs and workflows therein. Therefore for each PSP an implementation of this payment connection adaptor is needed.

If the connection, both commercially and technically, to the PSP is set up, each merchant needs to be onboarded and set up at the PSP and connected to the VIPASO system for payments.

When a consumer registers in the VIPASO system with the Pay app, no payment method is available initially. The user has to add a new payment method, e.g. a credit card, as a first step to be able to pay with VIPASO. This new payment method is forwarded directly to the PSP which has to store the data securely as a card-on-file for future transactions. The PSP returns a token for this payment method to the VIPASO system which acts as an identifier for the payment method.

For verification of the payment method in case of a credit card, the issuer, over the PSP, might require a 3-D Secure workflow as an SCA method which will be handled by the VipasoPay application and its success forwarded to the PSP to finish the addition of the new payment method.

When a payment is initiated with the VipasoPay and the VipasoPoS mobile applications, the VIPASO backend uses the PSPs token of the merchant (as set up during merchant onboarding) in combination with the PSPs token of the consumer's payment method to request the payment at the PSP.

Since all payments in the VIPASO system are triggered with the VipasoPoS app by the merchant, all payments are so-called merchant-initiated transactions and therefore should not require SCA again.

Financial Institution

The example below shows a payment flow using account to account rails based on Open Banking concepts interacting with a financial institution (e.g.: bank). This flow is also replicable for the integration with a national payment switch or any fintech or an MNO as intermediary in the whole payment chain.

The VIPASO system is using standard Open Banking APIs (restful APIs and ISO 20022) to initiate the payment flow including the additional required authentication flows based on an established SCA method of the financial institution.

Technology Stack

The VIPASO payment system is built with the following technologies:

  • The backend system is written in modern programming languages, mostly Kotlin and Go, and consists of multiple services running on a dedicated cloud environment that communicate with the other system components securely in-cluster and third party services over the internet.

  • The iOS applications and SDKs are written in Swift. The core architecture of the iOS app is Model-View-Viewmodel (MVVM). As the main functionality of both merchant and consumer applications is payment via Bluetooth and server communication, those parts are placed into the SDK codebase. Classes for Bluetooth communication, server communications (API calls) and common helper classes are also part of the main logic.

  • The Android applications and SDKs are written in Kotlin using coroutines. The Android architecture looks and works exactly the same way as iOS. The SDK module contains all logic for Bluetooth and server communication (API calls). Connection with the backend is implemented with Retrofit library.

Backend System

The backend system is the backbone of the system landscape and is running on a Kubernetes cluster. That means it is completely system independent, because the services are all built to be run as single-purpose independent micro-service Docker containers. Since the services together act as a web API all connections to it are handled by a reverse proxy with integrated TLS certificate management.
The backend services consist of

  • Payment gateway
  • Identity service
  • Authentication & authorization service
  • CDN service
  • Databases for each of the services

The REST API communication with the mobile apps on iOS and Android is distributed between the payment gateway, the identity service and the authentication & authorization service, each responsible for their purpose in the system. They are written in Kotlin using the Quarkus framework for asynchronous and high-throughput handling of web requests and reactive Hibernate to access the database.
The payment service handles the connection to any payment service provider (PSP, MNO, bank, national switch) which might be based on ISO 8585 and ISO 20022 standards or others and is ultimately responsible for initiating the payments.
In addition to the web API services, there is also a content delivery network (CDN) service that serves binary resources to the mobile apps if necessary using edge computing servers for low latency and therefore a fast user experience within the apps.
The default database used for the back-end services is the PostgreSQL relational database management system (RDBMS).

Updated 27 days ago

What’s Next