Technical Overview

Information on the concept and implementation of the Payment Hub Enterprise Edition

In this section, we'll provide an overview of the Payment Hub EE - the business requirements it supports, the architecture it's built on and the current status of the code.

Overview

The Payment Hub is a self contained application to enable a financial institution (DFSP - digital financial service provider) to integrate its various core banking systems (AMS - account management system), its banking channels, where customers initiate payment transactions and the various payment schemas that funds could be transferred.

Purpose

Enable DFSPs running various core banking platforms to rapidly connect to the Mojaloop or other payment schemas with a fully auditable manner, where their payment operators will have access to their own records and mechanism for investigation and interaction with transactions.

Design

Logical Model of the Payment Hub

Deployment oriented Component Architecture

The role of the Payment Hub EE at a DFSP

Architecture

Key architectural considerations

• Running on on-premises and cloud infrastructures, utilising Kubernetes

• Separate real-time engine and operations backend systems

• The Payment Realtime Engine is self contained, highly available and fault tolerant, can handle complete transaction flows

• Orchestrating the microservices are desired

  • handling timeouts

  • correlations of asynchronous events

  • handling error and exception scenarios with the necessary compensations

  • overview of in-flight transactions

• A Payment Realtime Engine manages the state machine using a microservice orchestration layer

  • Using Raft for consensus and log replication

  • Using RocksDB for key-value store of states

  • Does not use external NoSQL or Relational DB, which hinders scalability

• One engine is bounded to a single data center, for high performance, low latency and minimizing issues from network failure scenarios

• Multiple realtime engines could run parallel and independent

  • Protect against complete site failure

  • 24x7, 99.99+% availability operations require version upgrades, certificate changes, hardware replacement, … without interruption of the service

  • If payment network supports the notion of independent engines at a single DFSP, than routing could happen at the Switch, otherwise, the Payment Hub realtime engines could hand over the callbacks amongst each-other internally

• Systems for backoffice operations, including long term storage database, audit logging, monitoring, reconciliation - detached in a separate cluster

  • These components could be offline without any payment service interruption and data loss - the realtime engines Kafka layer keeps the records

  • “Operations systems” are not performance critical

  • Backoffice user access allowed only to these components, not the realtime engines

Internal structure of the Payment Hub EE

• Process orchestration by Zeebe

• Mojaloop connector

• Channel connector

• AMS connector

• Audit Streamer

• Operations Streamer

• Operations App

• Operations Frontend

Payment Hub EE internal structure

Components and flow of messages using the Payment Hub EE to link participants

• Payer 1 - using the channel of the bank, initiates a payment with pain.001 (mobile number of the Payee, provided using the Remittance Info of the messages) (the UI helps, to select the right institution and account at the intermediary bank (Leopard Bank) to reach the Payee

• Using pacs.008 and pacs.002 messages to complete an instant payment flow (based on SEPA Instant) funds arrive to a technical account at Leopard Bank in seconds, and transaction completes

• Based on the Remittance Info, Leopard Bank identifies the Payee and its Financial Service Provider utilising the Mojaloop Network, and completes the second transaction

• In case of failures, the necessary compensations will be executed by Leopard Bank