Guides

VIPASO Solution Deep Dive

Suggest Edits
364

System Architecture

The Vipaso platform consists of micro-services on the backend that provide a REST API for mobile applications (Android, iOS and KaiOS native applications). The backend system consists of several services for user data, payment and communication with external services.

These backend services are responsible for communication with external services; such as integrations to external payment services including PSPs, payment switches, and MNOs. The other services are for the security and API endpoints for the Pay (payer) and PoS (requester) mobile apps.

The external services include:

  • 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, payment switches, banks, MNOs)

Below is a high-level flow of the Vipaso system architecture:

Payment Initiation Service

Bluetooth Service Communication

Bluetooth and server communication support payment and exchanging transaction data between devices. Via Bluetooth, the Pay and PoS applications exchange session ID, timestamp of payment and short commands related to the flow in the payment process. These commands communicate signalling data and synchronize the user experience on both devices. Using 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.

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.

Below is an overview of the Bluetooth and server communication:

Payment Flow (Apps to Payment Service)

The payment process and flow consists of communication between mobile apps, payment service on the 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 (requester) and Pay (payer) 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

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 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 requester data and the payment method data and forwards the payment initiation to the acquiring entity in the established payment system.

The Vipaso system must be connected to a PSP where all the payment-related commercial contracts must be established beforehand. Each PSP operates 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 card or mobile money account, as a first step 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 the 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 successfully 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 requester (as set up during their 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 requester, all payments are so-called requester-initiated transactions and therefore should not require SCA again.

Financial Institution

For financial institutions, the Vipaso system uses 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.

The payment flows using account-to-account rails based on Open Banking concepts interact with a financial institution (e.g.: bank), and are replicable for payment switches or any fintech or an MNO as an intermediary in the whole payment chain.

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 30 days ago

What’s Next