Date
ParticipantsEd Cable, Yannick Awasum, Denila Philip,

Check-In Notes

Discussion on Architecture

  • Avik's Feedback on Mobile Money Gateway Design Specs:
    • In India no dominant provider in region - have tied up with aggregator - mossambee
    • If we go with aggregators need a couple slightly different columns 
  • For sending collection requests for customer on payment on due date - send a customer request to their wallet
    • Instead of customer initiate, notification turns up, they pay and it gets settled. 
    • Have we decided
  • Avik
    • Which providers? 
      • Cameroon Orange & MTN - access is hard but there is aggregator: https://www.furthermarket.com/Developers/#MOBILE%20MONEY%20CASH%20COLLECTOR
        • Limited in that customer-initiated transactions were not supported.
        • Still working with Orange & MTN but test sandbox is difficult - if can estimate higher # transactions can give access to sandbox - need to demonstrate demand and TX volume. 
        • Ayuk is working on Kodo Money in Zambia 
      • Zayyad - M-Pesa  - Kenya
      • Sifiso - Zimbabwe - Skyburg
  • Questions on Alternative Design
    • What are batch use cases? 
      • For disbursement in bulk - loans, vouchers, etc.
  • What about hard limits on disbursements
    • This is the case in India - where wallets have limits based on tiered KYC.
      • Can disbursements be broken into pieces?
      • Limit is 10000Rs without KYC
  • Table Questions
    • What is incoming client requests? 
      • Don't consider incoming client request entity as its been deleted.
      • Vladimir: focus on alternative design diagram. 
  • Separate table for aggregators
    • Enhance MMP with codes
    • aggregators will provide list of codes and these codes need to be sent in a request
    • Mapping needs to be maintained - fair cause to have a table for gateways/aggregators
      • How is Antony maintaining mapping of aggregator codes? 
  • What about failed transactions
    • Outbound: If MFI making disbursement to client, transaction logged in gateway and then pushed to mobile money provider, it if fails, status sent to gateway. Need to implement job in Fineract to call back all transactions that were failed in Gateway. If doing disbursement and it fails, Fineract query DB of mobile money gateway and roll back transactions taht fail on provider
    • Inbound: as of now, didn't think through clearly - problem is once money gets out of mobile money client, hard to get it back - once that payment has been done from provider side, can't get it back into account, if TX fails on side of Fineract, status of transaction would be left in mobile money gateway - query gateway in order to look at TX and see where they're reflect in Fineract. 
    • Avik: couple things involved
      • Retrying TX due to failing or timeout on mobile money side ---> Use Spring Retry if timeout on disbursement
      • Callback URL to roll out URL and SMS to customer account if fail for account limits, etc.
      • Spring Retry should handle for disbursements. 
    • Suspense Account by Musoni for TX in limbo
    • Fineract; configure job instances in Node - 
    • Best to track failed transactions on end of day job - not everything can be done synchronously - lots of times APIs are given asynchronously 
  • Need to improve documentation on integration with Fineract with interactions for failed transactions - whether push/pull etc. 
  • Additional Questions:
  • How is simple process flagged? 
    • Only pass journal entries once payment has been processed successfully, etc.
  • Review of implementation hasn't been done by Nazeer yet
    • Currently using API for loan repayment/savings
  • Action: review more of the integration with Apache Fineract
  • Action: phone # management - customer with multiple mobile money accounts - extension on Fineract side to accommodate that. 
  • Other Feedback: 
    • Explore using using common modules (microservices)/code for audit, reporting, multitenancy, etc.

What did we accomplish last week?

  • Murali
    • Completed SOAP adapter for Wave and integration with Mifos
    • Some dependencies on Wave for data
    • Agreed on 
    • In Mobile Money Gateway implementation so far
      • Fundamental architecture doesn't address multi-tenancy
      • Multiple adapters connecting to and interfacing with different Mifos tenants
      • Murali was able to have done that - did it in a different way - scope for better mind to support that - include that again
    • Got it to work with multiple tenants but true multi-tenant end to end nature not implemented yet in Vladimir's codebase
    • Database recreated each time server executed - has address that - raised a ticket and resolution. Will raise ticket on architectural changes. 
    • Notable progress from 
    • Avik: multi-tenant changes can be made - not too time intensive

What is blocking us?

  • Antony - not sure on the architecture 

Actions & Next Steps

  • Vladimir to demo his work to date separately to Avik, Yannick, Murali
  • Antony to demo his work to proceed ahead with architecture (scheduled for Wed)
  • Denila to continue documenting requirements
  • Avik to continue reviewing and giving feedback on architecture.
  • Expand design document to cover more of the scope of Fineract integration
  • Further outline how failed transactions are handled
  • Document how we handle multiple mobile money accounts per customer. 

 

  • 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. 
  • Antony to share the architecture/design documentation.
  • Vladimir to help Chirag get his build running.