fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Geiß <markus.ge...@live.de>
Subject RE: [DISCUSSION] UPI Integration
Date Wed, 01 Jun 2016 07:28:31 GMT
----------------------------------------
> To: dev@fineract.incubator.apache.org
> From: meta1729@gmail.com
> Subject: [DISCUSSION] UPI Integration
> CC: mifos-developer@lists.sourceforge.net
> Date: Tue, 31 May 2016 15:23:18 +0530
>
> Hi all,
>
> There are three components in UPI. PSP Apps (created by PSPs), PSP
> Servers (backend for PSP apps), and UPI Server (managed by NPCI).
>
> PSPs (Payment System Players) are Banks, Payment Banks, PPIs, or any
> other RBI regulated entities that are allowed to acquire customers and
> provide payment (credit/debit) services to individuals or
> entities. The list of authorized PSPs[1] is maintained on RBI website.
> [1] https://www.rbi.org.in/Scripts/PublicationsView.aspx?id=12043
>
> This is how an individual is supposed to use UPI: He has a bank
> account. He will install any of the PSP Apps on his mobile. Create his
> virtual address and tie a bank account with that address. Now he can
> pay or collect money to/from other virtual addresses.
>
> Let's refer to Fineract user as an MFI. MFIs are not interested in
> becoming a PSP. So they are not PSPs. So we won't be implementing a
> PSP Server. MFI can use an existing PSP App, which will be a mobile
> app. This is cumbersome/impractical. We cannot write our own client if
> their ToS prohibits it. So, we hope that PSPs will open up their
> backends to public, so that we can legally write our own custom client
> to talk to the PSP server. But it is not at all clear whether PSP's
> will open up their backends. Most of the UPI documents released by
> NPCI focus only on the protocol between PSP Server and UPI Server, and
> do not say anything about standardization of protocol between PSP Apps
> and PSP Servers. If this isn't standardized or opened up, we cannot
> have full UPI integration.
>
> On page 15, of the UPI Product Document[2], under §12 Certification of
> members, it says "b). It is also being explored if there is a need to
> certify every PSP Application that will talk to UPI. If the decision
> is in favor of certifying an application of the PSP, we will finalize
> the modalities thereto." I think they have messed up the terminology
> here. I think what they mean is they are exploring whether to require
> certification of PSP Servers which are allowed to talk to the UPI
> server.
>
> [2] https://mifosforge.jira.com/wiki/display/MIFOSX/Unified+Payment+Interface
>
> Even if PSPs don't open up their API, there is a way we can still use
> UPI. It is by creating a third party merchant mobile app. According to
> the diagram on page 10 of UPI API Tech Spec, third party apps can only
> use Collect methods of the API. These merchant apps are supposed to
> call into any of the PSP apps that are already installed on the
> device. On Android this will be using Intents.
>
> Other concerns:
>
> At several places in NPCI docs[2], it says the PSP apps 'need to use' the
> "common library" for secure credential capture
> (MPIN/Password/PIN/Biometrics etc). Since we are not building a mobile
> app, we won't be using the library for credential capture. Credentials
> will be saved in the database.
>
> At several places in NPCI docs, the term "Mobile device
> fingerprinting" is used. This is a bad sign for two reasons. First
> because relying on device fingerprint for identifying a physical
> mobile device is very insecure design decision. I don't know what
> constitutes the fingerprint, but things like IMEI, Android ID can be
> easily spoofed by using an emulator. Second reason is that it hints
> that PSP Server-App communication is not going to be standardized or
> opened up, and PSP's are free to use their own custom protocols there.
>
> So currently the only guaranteed way we can use UPI is by creating the
> merchant app. Since I believe we already have a Mifos mobile app, we
> only have to add this functionality there. An MFI will create a
> self-branded instance of this app and use it for collection/repayment
> (not possible for disbursement).
>
> What I could find though was that NPCI conducted a hackathon few
> months ago, wherein they had participants write PSP apps and
> servers. For the purpose of writing the apps, they defined a
> JSON-based protocol[3] and provisioned a sandbox PSP Server to test
> against. This protocol seems to have been defined for the sole purpose
> of the hackathon. If they wanted to standardize it they would have
> mentioned it in the tech spec documents. See Hackathon resouces[4] for
> more info.
>
> [3] https://mifosforge.jira.com/wiki/download/attachments/138412058/Hackathon-PSP%20Server%20integration%20and%20usage.pdf?version=1&modificationDate=1464684199474&api=v2
> [4] https://www.hackerearth.com/sprints/unified-payments-interface-hackathon/resources/
>
> According to a news article[5], 10 banks are ready with their apps but
> they won't be launching until mid-June.
> [5] http://www.business-standard.com/article/finance/wait-for-2-months-to-transact-on-unified-payments-interface-116041200758_1.html
>
> If anyone has sources in the industry, if you know anyone working at
> any PSP like Paytm, you could try to find out what the situation is
> and how Fineract can use UPI.
>
> --
> Regards,
> Aditya Hendre


Hey Aditya,

We may need to clarify a few things. ; o)

1) The first part of the project is to create a Java based SDK to wrap the UPI API. This
would allow the integration of NPCI's UPI service into any Java application.

2) We also have APEX organisations and large associations as consumers of Fineract.
In addition the RBI is currently issuing licenses for Mobile Money banks, and Fineract
would be a solution to support this use case. This would lead to offer the PSP
capabilities as part of Fineract, utilizing the new UPI Java SDK. 

Best,

Markus

.::YAGNI likes a DRY KISS::.

 		 	   		  
Mime
View raw message