Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
[Mifos-developer] Fineract Payment gateway
654 views
Skip to first unread message
Steve Conrad
Oct 6, 2018, 10:54:13 PM10/6/18
to Dev, Mifos software development
Hi all -
I wanted to provide an update on the Fineract Payment gateway development that we have been working on over the past few months. A few different teams have been working on this functionality for some time, and we are continuing efforts to deliver functionality that will allow Fineract to work with other MFIs, MMPs and large scale projects like Mojaloop.
Antony Omeri developed functionality that allows Fineract to interact with outside systems using ActiveMQ. The latest iteration of this development can be found here: https://github.com/conradsp/fineract/tree/payment-gateway-integration
This past summer, Sanyam Goel (under the mentorship of Rahul Goel and myself) did some excellent work developing a middleware project that handles transactions between Fineract and other providers like Beyonic and Mojaloop. The latest iteration of this work can be found here: https://github.com/conradsp/payment-gateway/tree/payment-gateway-core-functionality
After the summer, I did a bit of work to flesh out the connections between Fineract, the payment gateway, and a first outside provider, which was Beyonic. I have finished the implementation of some basic functionality, and created a document in Confluence which describes how to configure and use all of the various pieces. This document is located here: https://cwiki.apache.org/confluence/display/FINERACT/Payment+Gateway+Configuration
While we have established an architecture and implemented some basic flows, it is important that we validate that the architecture/design and approach are appropriate for what we would like to do long-term with Fineract and interacting with other platforms.
I would invite the community to review, comment, and critique the work that has been done on this project. There may be a better design and architecture that will serve the long-term needs of Fineract. Or we may find that this architecture is one that we want to continue to build on and develop.
Please feel free to respond with any questions or comments.
Thanks,
Steve
Steve Conrad
Oct 8, 2018, 1:56:32 PM10/8/18
to Dev, Mifos software development
Thanks Avik.
The Mojaloop P2P pilot implementation was built before the payment gateway code was completed. I envision that the next Mojaloop-related task would be to implement this P2P flow on top of the Fineract Payment Gateway code and the new implementation of Mojaloop.
The documentation for installing Phase 2 of Mojaloop is located here: https://github.com/mojaloop/docs/blob/develop/WorkShops/Presentations/Mojaloop_Phase2_Wrap-up_Deployment-Day3_V2.0-published.pdf
I installed Mojaloop on a 16GB laptop that I had, as the AWS instances that Fineract had were not large enough to support the installation. It may be a better long-term approach to have Fineract allocate a new larger AWS server for the Mojaloop integration.
I would also recommend joining the Mojaloop Slack channel to get information and updates on their development: https://mojaloop.slack.com/
I was planning to work through this integration as I am able, but I don't want to replicate efforts - if you are working on Mojaloop integration, please feel free to dive in and I will support your work and answer any questions that I can.
Thanks,
Steve
On Sun, Oct 7, 2018 at 8:49 AM Avik Ganguly <avikgan...@gmail.com> wrote:
Hi Steve,
This looks great.
I will look at the design and the reference Beyonic flow and if I come
across any blockers, I will update this thread.
Is the Mojaloop P2P transfer payment flow explained here
<https://cwiki.apache.org/confluence/display/FINERACT/Mojaloop+Integration>
also
part of this payment gateway repo? (1)
Is anyone else working on implementing any Mojaloop use cases on top of the
payment gateway I should get in touch with?
Since the latest version of Mojaloop APIs are significantly different, do
you think P2P transfer flow (documentation (and code if it exists)) will be
impacted. If you are stretched this week, I can try to deploy the latest
Mojaloop artifacts in the mifosmojaloop instance if the deployment process
is fairly documented. What are your thoughts?
Regards,
Avik.
ᐧ
On Sun, Oct 7, 2018 at 8:24 AM Steve Conrad <scon...@gmail.com> wrote:
> Hi all -
>
> I wanted to provide an update on the Fineract Payment gateway development
> that we have been working on over the past few months. A few different
> teams have been working on this functionality for some time, and we are
> continuing efforts to deliver functionality that will allow Fineract to
> work with other MFIs, MMPs and large scale projects like Mojaloop.
>
> Antony Omeri developed functionality that allows Fineract to interact with
> outside systems using ActiveMQ. The latest iteration of this development
> can be found here:
> https://github.com/conradsp/fineract/tree/payment-gateway-integration
> <
> >
>
> This past summer, Sanyam Goel (under the mentorship of Rahul Goel and
> myself) did some excellent work developing a middleware project that
> handles transactions between Fineract and other providers like Beyonic and
> Mojaloop. The latest iteration of this work can be found here:
>
> https://github.com/conradsp/payment-gateway/tree/payment-gateway-core-functionality
> <
> >
>
> After the summer, I did a bit of work to flesh out the connections between
> Fineract, the payment gateway, and a first outside provider, which was
> Beyonic. I have finished the implementation of some basic functionality,
> and created a document in Confluence which describes how to configure and
> use all of the various pieces. This document is located here:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Payment+Gateway+Configuration
> <
Ippez Robert
Oct 15, 2018, 9:22:43 AM10/15/18
to Dev, Mifos software development
Hi Steve,
I tried to run the payment gateway using mvn clean install, howver i ran into the following error. Am using Java8
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 78 source files to D:\Projects\Incubations\payment-gateway\target\classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /D:/Projects/Incubations/payment-gateway/src/main/java/org/apache/payment/gateway/activeMQ/service/InboundMessageHandler.java:[21,34] package com.oracle.javafx.jmx.json does not exist
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 06:59 min
[INFO] Finished at: 2018-10-15T15:06:17+03:00
[INFO] Final Memory: 32M/325M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project payment-gateway: Compilation failure
[ERROR] /D:/Projects/Incubations/payment-gateway/src/main/java/org/apache/payment/gateway/activeMQ/service/InboundMessageHandler.java:[21,34] package com.oracle.javafx.jmx.json does not exist
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
PS D:\Projects\Incubations\payment-gateway> mvn clean install
Where could the problem be?
Thanks
Regards
Ippez Robert
Ippez Roberts
Founder/C.E.O - Swift3 Technologies (U) Ltd"Redefining Next Generation I/O Systems"
P.O.Box 155, MoyoSteve Conrad
Oct 15, 2018, 10:15:41 AM10/15/18
to Dev, Mifos software development
Hi Robert -
In the original implementation, we were using JavaFX, but I removed that dependency. There was one import left in that file that referenced that library. I have removed that import and you should be fine now.
Thanks,
Steve
On Mon, Oct 15, 2018 at 8:22 AM Ippez Robert <ippez...@gmail.com> wrote:
Hi Steve,
I tried to run the payment gateway using mvn clean install, howver i ran
into the following error. Am using Java8
*[INFO] Changes detected - recompiling the module!*
*[INFO] Compiling 78 source files to
D:\Projects\Incubations\payment-gateway\target\classes*
*[INFO] -------------------------------------------------------------*
*[ERROR] COMPILATION ERROR :*
*[INFO] -------------------------------------------------------------*
*[ERROR]
/D:/Projects/Incubations/payment-gateway/src/main/java/org/apache/payment/gateway/activeMQ/service/InboundMessageHandler.java:[21,34]
package com.oracle.javafx.jmx.json does not exist*
*[INFO] 1 error*
*[INFO] -------------------------------------------------------------*
*[INFO]
------------------------------------------------------------------------*
*[INFO] BUILD FAILURE*
*[INFO]
------------------------------------------------------------------------*
*[INFO] Total time: 06:59 min*
*[INFO] Finished at: 2018-10-15T15:06:17+03:00*
*[INFO] Final Memory: 32M/325M*
*[INFO]
------------------------------------------------------------------------*
*[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project payment-gateway: Compilation failure*
*[ERROR]
/D:/Projects/Incubations/payment-gateway/src/main/java/org/apache/payment/gateway/activeMQ/service/InboundMessageHandler.java:[21,34]
package com.oracle.javafx.jmx.json does not exist*
*[ERROR] -> [Help 1]*
*[ERROR]*
*[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.*
*[ERROR] Re-run Maven using the -X switch to enable full debug logging.*
*[ERROR]*
*[ERROR] For more information about the errors and possible solutions,
please read the following articles:*
*[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
<http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException>*
*PS D:\Projects\Incubations\payment-gateway> mvn clean install*
Where could the problem be?
Thanks
*Regards*
*Ippez Robert*
Ippez Robert
Oct 16, 2018, 2:52:13 AM10/16/18
to Dev, Mifos software development
Hi Steve,
Thanks, its up and running now. How do i compile the project into a .war file so that it is deployed in tomcat because running it as a .jar file brings up conflict in port since port 8080 is already bind to tomcat.
Thanks
Regards
Ippez Robert
Steve Conrad
Oct 16, 2018, 10:51:07 AM10/16/18
to Dev, Mifos software development
Hi Robert - building the project as a war is work that is on the roadmap but not completed yet. To run on a different port, you can either add the server port to the application.properties file, or when you launch the application, add the following to the VM options: -Dserver.port=<whatever port you choose>
Steve
James Dailey
Oct 16, 2018, 2:04:58 PM10/16/18
to d...@fineract.apache.org, Mifos software development
Hi Steve -
This is a really important project. Providing interoperability between account systems at a national, regional, and global level is what is needed ultimately. Gone are the days when Mifos was just about managing the "book" or portfolio of a single institution. Mifos must participate in the connective tissue of payments and movement of funds. Thank you for all the work you and the team have done.
When I look at this design, I have some key critiques and queries:
To start, in banking systems we have various ways of "routing" payments to addresses. This can be IBAN numbering, or credit card tokenized numbers that link to virtual accounts, or SWIFT bank routing (wire transfers). The sending account and the receiving account need to be clearly identified to the SWITCH in the middle but depending on the rules, the sending account owner may not have full information about the receiving account. Think of sending PayPal or $Cash in the US - you have the Alias of the account, such as the telephone number or the email address or $handle, to which you are sending funds, but you do not have their underlying bank account information. As a sender you get some confirmation that says "yes, this is the right person based on the information you've entered". From what I can see/understand in the code, you are expecting the sender to have a lot more than the alias of the recipient, or the address that would be used in the payment network. ? e.g. https://github.com/conradsp/payment-gateway/blob/payment-gateway-core-functionality/src/main/java/org/apache/payment/gateway/service/TransactionsDataService.java
Second, it is generally accepted that a financial institution (FI) participates in a payment SCHEME. The scheme has rules which cover how much can be transferred, what settlement rules there will be and how to handle exceptions. Generally the SWITCH in the middle handles the rule enforcement although some rules are delegated to the sending or receiving institution. On the FI side there will be a stateless gateway that manages the queue of transactions, basic data validation, and other key interop functionality.
In many developing countries, the mobile wallet providers are unable to connect to the banking SWITCH (e.g. they cannot get an IBAN ) and thus a number of alternative models have developed, especially Aggregators, like our example. The short of this is that Aggregators have multiple *roles* in the financial flows and this can create confusion in the design of implementations. I see some of these conceptual problems in the current design.
I think it would be useful to review this Glossary of terms and concepts from the ITU (the global association that governs Telecommunications): https://www.itu.int/en/ITU-T/focusgroups/dfs/Documents/201701/ITU_FGDFS_DFS-Glossary.pdf It came about because mobile wallets are becoming so ubiquitous but they - unlike their counterparts in banking - are not yet offering good interoperability. I'm happy to debate this point, but Aggregators don't stand in adequately for a systemic approach to payments - they tend to cherry pick the most profitable lines rather than offer a true *payment rails*.
And, in particular, the use of the concept of "Vendor" is simply not right. The concept should either be a payments network, a payments scheme, or some combination. Vendor may be applicable to a bulk sending provider (which Aggregators also do), in which case you can have a Vendor offering a processing service or a pre-processing service prior to submission of payments to a payments network. "Vendor" in the current design seems to confound a number of concepts, including payment scheme, payment system, processing entity, and data protocol to be used.
In terms of data protocols, again I would argue that Fineract MUST follow international and globally emerging norms, as befits an Apache project seeking global acceptance. I am not yet in favor of ISO 20022 which is a meta language where you have relatively heavy XML based vocabularies (replacement of the ISO8583 "ATM Standard"), but neither am I in favor of writing our own data standards. I have strongly suggested that we get on the bandwagon of the APIs developed by Mojaloop because they are the culmination of work involving the major system providers in mobile wallets and is open source. They are also quite sensible. In this implementation of the gateway our data payloads and the structure of the send, receive, receipt are all non-standard, and unless I mis-understand, they are spread out all over the place in the code.
Finally, in terms of structure, I'll say that clear roles for the different pieces is super important. I'm glad you've been moving in that direction with refactoring. I am not exactly sure how to split out functional domains, but in no particular order and mixing various levels, here are some ideas:
* Bulk payment "pre-processing" should be separated out (bulk file received, data validation, etc)
* Bulk payment retries and dashboards are also separate
* Join a payment scheme and network (become authenticated and authorized participant as an institution)
* Use a payment system data standard (translate the data mapping)
* Enforce certain rules on FI (e.g. total settlement exposure on intra-day period)
* On Receive, validate the payment recipient account (it exists and can take funds, no flags) using alias
* On Send, validate funds are present (after built in authorization has occurred)
* On Send, send payment amount to address (alias)
* On Send, expect a confirmation of amt received (receipt)
* Return information to customer on send
What not to do/include:
* Calculate net settlement positions (should be hand off to switch)
* Recognize funds received unless sending side has confirmed
* Write scheme rules into the core Fineract code
Fundamentally I do NOT believe Fineract or Mifos should be developing a SWITCH, as Mojaloop.io has released that as open source. At most we need a gateway that can connect to different schemes, including mojaloop and a standard ATM network, and perhaps also to various Aggregators (being pragmatic as these do exist and will continue to for the near future). It is not uncommon for a Bank to have a connection to multiple schemes: i.e. SWIFT, IBAN, ACH, LVT, etc. We should NOT turn Mifos/fineract into a run time fully stateful switch (ledger) in the middle. It's role is the backend system of record of a digital financial service provider (DFSP) that connects to any number of payment schemes.
I am happy to discuss further and dig into this more. Again, this is too important not to get right. To bring Mifos/Fineract to a global audience we have to address its role in the ecosystem of financial service providers and how it connects to them all.
Let's have a convo with others who are involved via one of our collaboration tools and report out to the listserv. We should have others review this in depth as to propose some more specifics. I would like a high level architectural document view if that is also possible.
Thanks
James
On Sat, Oct 6, 2018 at 7:54 PM Steve Conrad <scon...@gmail.com> wrote:
Hi all -
I wanted to provide an update on the Fineract Payment gateway development
that we have been working on over the past few months. A few different
teams have been working on this functionality for some time, and we are
continuing efforts to deliver functionality that will allow Fineract to
work with other MFIs, MMPs and large scale projects like Mojaloop.
Antony Omeri developed functionality that allows Fineract to interact with
outside systems using ActiveMQ. The latest iteration of this development
can be found here:
https://github.com/conradsp/fineract/tree/payment-gateway-integration
This past summer, Sanyam Goel (under the mentorship of Rahul Goel and
myself) did some excellent work developing a middleware project that
handles transactions between Fineract and other providers like Beyonic and
Mojaloop. The latest iteration of this work can be found here:
https://github.com/conradsp/payment-gateway/tree/payment-gateway-core-functionality
After the summer, I did a bit of work to flesh out the connections between
Fineract, the payment gateway, and a first outside provider, which was
Beyonic. I have finished the implementation of some basic functionality,
and created a document in Confluence which describes how to configure and
use all of the various pieces. This document is located here:
https://cwiki.apache.org/confluence/display/FINERACT/Payment+Gateway+Configuration
Reply all
Reply to author
Forward
0 new messages