Date
ParticipantsEd, Antony, Yannick, Vladimir

Check-In Notes

Listen to recording at 

What did we accomplish last week?

Vladimir has been documenting some of the strategies discussed regarding reversal of transactions

Yannick has been exploring ActiveMQ to explore porting over ActiveMQ from RapidMQ in Antony's code.

Antony - issue with endless looping if ActiveMQ not configured.

What is blocking us?


Actions & Next Steps

  • See if Courage's work on Configuration of ActiveMQ has been reviewed and merged

 

  • Nazeer Shaik to review architecture once it comes from Antony
  • @Thynn and Murali to create tickets for work they're doing and bugs they're finding
  • Antony to peer-review the recent work that Vladimir has done. 

Finalize Architecture:
Primarily we need to finalize the architecture and design so that the developers working on the gateway can proceed forward. We needed to incorporate the following: 
- Avik's feedback and oustanding questions from previous meetings including 1)adding in support for transaction limits at disbursal based on tiered KYC, 2) including a separate table for API aggregators, 3) handling of failed transactions (both inbound and outbound) and clearly documenting the integration with Fineract for how those failed transactions are handled and when they're re-attempted, 4) extension of apache fineract to handle clients who have mulitple phone numbers and multiple mobile money accounts. 
- James feedback regarding discovery of the receiver being separate following a design similar to Simple Payment Setup Protocol 
Whether the payment gateway should be a stand-alone module or directly part of Apache Fineract. 
Antony saw benefits of having it be part of Fineract so that each tenant could have its own transactions. 
Review and incorporate Antony's code into main repo for gateway
Create Tickets for Additional Work on Apache Fineract
- Capturing additional mobile numbers per client and tagging or categorizing with code that they're for different mobile money providers.