Provide scalable and fault tolerant design with easy integration
Allow easy plugging with different payment types (Mojaloop, GSMA, Afrimoney and others)
Enable reuse of existing BPMNs to facilitate transfers
Prioritizing New Use Cases
G2P
P2G
Bulk Processor Flow
Bulk processing is designed as a separate system within Payment Hub EE architecture supporting
File integrity check with MD5/SHA256 checksum when received in channel connector
Bulk processor
Split streamed files and split into sub-batches
Format file contents into a format bulk connectors can parse
Order payments
Publish to Kafka payment topic
Merge back sub-file and sub-batch results into a consolidated response
Bulk connector
Format data based on payment connector requirements
Starting point of initiated payment type-specific workflows
Stream sub-batch transactions from S3 based on metadata from Kafka
Configurations
To provide a granular level of control, the bulk processor supports multiple configurations for different stages like ordering, formatting, splitting etc.
partylookup.enable: used to enable or disable the partylookup stage
approval.enable: used to enable or disable the approval stage
ordering.enable: used to enable or disable the ordering of transactions in a data set based on a field provided.
ordering.field: the field based on which ordering will be done.
formatting.enable: enable or disable the formatting of data set. If formatting is disabled the default formatting standard is used.
formatting.standard: the formatting standard to be used for transactions, possible values are "DEFAULT", "GSMA".
splitting.enable: enable or disable the splitting of the original csv file into sub-batches. Splitting is done on the sub-batch-size field configuration.
splitting.sub-batch-size: the size of the single sub batch.
mergeback.enable: enable or disable the merging back of the sub batches result.
success-threshold-check.enable: enable or disable the success threshold check, use this configuration to make sure at least x percentage of transaction is successful in a batch.
success-threshold-check.success-rate: a percentage value that will be used while making the threshold check.
acknowledgement.enable: enable or disable the acknowledgement part of the workflow.
Key Considerations:
Kafka provides auto partitioning within topics based on throughput and data
Scalable and fault-tolerant system provided by the multi-cluster setup
Handle backpressure from Zeebe and throttle workflow initiation
Kafka will act as a buffer in this case
Advantageous when Zeebe is overloaded
Due to resource limitations
Or not fast enough scaling
Reduces cascading Denial of Service for other payment connectors.
Provide a visual workflow representation with Zeebe
Stores every state for workflow instances
Timers surviving node failures without interruptions
Using an efficient, high-performance binary protocol (gRPC) for the clients to connect and receive tasks for execution
Retry mechanism on the entire subprocess
But retry is already in place within subprocesses
Unified payment architecture
Easy integration with AMS if payment staging requires it
In case of beneficiary creation during transfer
Using Raft for log replication
Kafka to write ahead log replication as well.
Easy integration of pre and post-transaction workers
[ {"id":568,"workflowInstanceKey":2251799907439003,"transactionId":"e5eea064-1445-4d32-bc55-bd9826c779a0","startedAt":1629130966000,"completedAt":1629130967000,"status":"IN_PROGRESS","statusDetail":null,"payeeDfspId":"giraffe-bank","payeePartyId":"7854278651","payeePartyIdType":"MSISDN","payeeFee":null,"payeeFeeCurrency":null,"payeeQuoteCode":null,"payerDfspId":"gorilla-bank","payerPartyId":"7543010","payerPartyIdType":"MSISDN","payerFee":null,"payerFeeCurrency":null,"payerQuoteCode":null,"amount":448,"currency":"USD","direction":"OUTGOING", "errorInformation": "{\\\"errorInformation\\\":{\\\"errorDescription\\\":\\\"Invalid responseCode 500 for transfer on PAYER side, transactionId: e5eea064-1445-4d32-bc55-bd9826c779a0 Message: {\\\\\\\"timestamp\\\\\\\":1629130966891,\\\\\\\"status\\\\\\\":500,\\\\\\\"error\\\\\\\":\\\\\\\"Internal Server Error\\\\\\\",\\\\\\\"message\\\\\\\":\\\\\\\"\\\\\\\",\\\\\\\"path\\\\\\\":\\\\\\\"/fineract-provider/api/v1/interoperation/transfers\\\\\\\"}\\\",\\\"errorCode\\\":\\\"4101\\\"}}",
"batchId":"c02a14f0-5e7e-44a1-88eb-5584a21e6f28" }]
Money is transferred directly to bank accounts / mobile money wallets from the sender float account.
No involvement of AMS.
Without Auto Payout
Targeting organisations
Money is transferred to Fineract wallets of the receivers.
Receiver can choose if they want to withdraw the money out of the wallet
Or consider using the money in float/current/checking account for L2 beneficiaries (clear invoices, payroll) seamlessly in one platform (L1 beneficiary amount remains in closed loop)
This provides an advantage to beneficiary orgs to manage their payouts if they have a legacy current/checking account with mostly manual payout processing.
