The horizon payment system is built with the following technologies:
The backend system is written mostly in Java and consists of multiple services running on a dedicated cloud environment that communicate with the other system components securely over the internet.
The iOS applications and SDKs are written in Swift. The core architecture of the iOS app is Model-View-Viewmodel (MVVM) and the application uses third-party libraries for communication with the server. CommonCrypto is responsible for the encryption/decryption while JazzHands is used for animations. As the main functionality of both merchant and consumer applications is payment via Bluetooth and server communication, the iOS project is structured with a core and common library for both applications (Wallet and Terminal) where the entire logic is placed. Classes for Bluetooth communication, server communications (API calls), algorithms for encryption/decryption and common helper classes are also part of the main logic.
The Android applications and SDKs are written in Kotlin and RxJava. The Android application is divided into three modules (common, wallet, terminal), similar to the iOS application. The core module contains all logic for Bluetooth communication, server communication (API calls) as well as logic for encryption/decryption. Connection with the backend is implemented with Retrofit library. API classes and repositories are implemented through Dagger dependency injection.
The backend system is the backbone of the system landscape and is running on a Linux server, although completely system independent, because the services are all built to be run as Docker containers. Since the services together act as a web API all connections to it are handled by an Nginx reverse proxy.
The backend services consist of
- App service
- Payment service
- CDN service
The app service is the main service for the REST API communication with the mobile apps on iOS and Android. It is written in a typical Java web stack with Spring Boot, Hibernate and Tomcat as its application server.
The payment service is an additional service layer with a REST API or additionally based on ISO 8585 and ISO 20022 standards. It handles the connection to any payment service provider (PSP, MNO, Bank, National Switch) and is ultimately responsible for initiating the payments. This service is built with the same Java web stack as the app service, using Spring Boot, Hibernate and Tomcat as its application server.
In addition to the web API, there is also a content delivery network (CDN) service that serves binary resources to the mobile apps with an Nginx web server.
The database used for the app and payment service is the PostgreSQL relational database management system (RDBMS).
The horizon platform consists of microservices on the backend that provide a REST API for mobile applications (iOS and Android native applications). The backend system consists of several services for Wallet and 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.
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.
- SMS gateway: Service for sending SMS messages (PUK codes) for account confirmation.
- Payment service providers (eg.: PSP, national payment switches, banks, MNOs)
- VAS service providers (e.g: couponing/loyalty, cash register, currency conversion)
Java backend services are responsible for the communication with external services. On the backend side there is the payment service which includes integrations to any external Payment Service Provider including PSPs, National Payment Switches, MNOs and an app service which is responsible for the security and endpoints for the Wallet and Terminal mobile apps.
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 horizon Terminal mobile app, which starts the payment session in the horizon backend system. At the same time the user gets the payment request on its horizon Wallet mobile app and confirms the payment to the horizon 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 (eg.: Card, A2A, Phone Number/MSISDN).
For example, in the case of Card based Payments (eg.: 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.
The diagram below displays the entire architecture of the horizon 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.
Bluetooth Service Communication
This functionality is the most important and most complex one inside the application. That is the case because the Bluetooth and server communication support payment and exchanging transaction data between devices. Via Bluetooth, the Wallet and Terminal applications are exchanging session ID, timestamp of payment and short commands that are related to the flow in the payment process. Those commands help to improve better user experience. 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 server and 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.
The whole logic for Bluetooth and server communication is displayed in the next diagram. End-to-end payment user communication (Wallet-Terminal payment process):
The payment process and flow consists of communication between mobile apps, payment service on backend and the payment service Provider (eg.: 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 payment service provider. Both Terminal and Wallet mobile apps use the same APIs and communicate with our backend. All communication with the payment service provider is going 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 horizon.
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 horizon 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
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 horizon system for payments.
When a user registers in the horizon system with the Wallet 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 horizon. 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 horizon 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 horizon Wallet application and its success forwarded to the PSP to finish the addition of the new payment method.
When a payment is initiated with the horizon Wallet and the horizon Terminal mobile applications, the horizon 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 horizon system are triggered with the horizon Terminal app by the merchant, all payments are so-called merchant-initiated transactions and therefore should not require SCA again
The example below shows a payments flow using account to account rails based on Open Banking concepts interacting with a financial institution (eg.: bank). This flow is also replicable for the integration with a national payment switch or any fintech or a MNO as intermediary in the whole payment chain.
The horizon system is using standard Open Banking APIs (Restful APIs and ISO20022) to initiate the payments flow including the additional required authentication flows based on an established SCA method of the financial institution.
Updated 3 months ago