Bulk Disbursement Integration

Bulk Payment Design

  • 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

    • Such as bulk notification

References:

https://forum.camunda.io/t/zeebe-usecase-architecture-question/1168/6

https://stage.docs.zeebe.io/reference/grpc.html#error-handling

https://docs.camunda.io/docs/product-manuals/zeebe/deployment-guide/operations/backpressure/

https://stage.docs.zeebe.io/bpmn-workflows/multi-instance/multi-instance.html

https://camunda.com/blog/2019/08/zeebe-horizontal-scalability/

https://docs.camunda.io/docs/0.25/product-manuals/zeebe/bpmn-workflows/embedded-subprocesses/embedded-subprocesses/

https://docs.camunda.io/docs/0.25/product-manuals/zeebe/bpmn-workflows/event-subprocesses/event-subprocesses

https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7

API Specification

  • Provide developer friendly consumer APIs

  • Enable easy integration by abstracting underlying payment type API complexities

  • Group common fields across various payment APIs and make em mandatory field

    • All fields in the spec below are mandatory fields

  • Allow addition of payment type specific fields as optional

1. Bulk Transfer

Use below csv file for refernece.

Use the below request along with above CSV file

Use the below request to start a batch only using the filename

Use the below request to pass transaction data in the body of the request

2. Bulk Transfer Status

Response File

3. Batch Details

4. Get Batches

5. Download Template

Payment Routing

  • Route enables user to split payments received and transfer the funds to various vendors/beneficiaries.

  • Sample request body

  • With Auto Payout

    • Targeting individuals

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

Last updated

Was this helpful?