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
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