Technical Overview
Information on the concept and implementation of the Payment Hub Enterprise Edition
Last updated
Information on the concept and implementation of the Payment Hub Enterprise Edition
Last updated
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.
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.
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.
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
Process orchestration by Zeebe
Mojaloop connector
Channel connector
AMS connector
Audit Streamer
Operations Streamer
Operations App
Operations Frontend
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
