Should we ask for Free Software app for UPI?

Its worth every penny and time investing in development of an open source UPI client.

UPI is common people's internet banking now. Hard to find phones without UPI apps. In these tough times, UPI is handy

Every bank has now least 2 UPI android apps their own. Then there is apps such as google pay, phonepe, paytm freecharge etc capturing markets with cashback offers and gaining monopoly.

I use UPI only via USSD (*99#) because of this very reason. I badly want libre UPI app in f-droid store.

i had heard about this, but only tried it recently. ussd solution will work even if you don't have smartphone or internet. but the user experience may not be pleasant, so what about creating a ussd wrapper application that can read qr code, send ussd code in the background and parse the responses to provide a better ux for the end users? there are already some similar solutions, but couldn't find any free software alternatives. found an app on f-droid which is capable of sending and parsing ussd responses to check balance, maybe someone could work on this to make it work for upi payments. apart from the technical challenges in creating such a wrapper app, there are still a couple of issues: ussd doesn't seem very secure and i don't know if there are any legal issues in developing and distributing such apps (i hope there's none, but it's always good to confirm by consulting any legal experts).

Now that ICFOSS is out of the picture. We need to find someone else for this. Anyone have any idea about whom to contact ?

No idea currently. Is there a financial circle comfortable with term free software and does development publicly. I only know of Razorpay who deals with payment gateways and remotely something opensource here.

Razorpay have their own products. I don't know they develop something at
request or do consultation for that matter. But let see. Whom to ping at
Razorpay ? Anyone from our circle work there ?

nemo, but I dont think a company would do this.

(Views are personal, and not that of my Employer).

There's a lot of open-API branding around UPI that makes this issue hard to understand. Here's a simple sketch that explains the various components (attached).

The Orange Bit is the central UPI server, which acts as the router for the other banks, which run their own servers. All of this is proprietary, running on a closed-network and inaccessible to the Internet.

An API is exposed to the actual UPI apps, which differs in its implementation across the banks. Each UPI application as a result contains:

1. Code to talk to the specific Bank API. In the case of BHIM, this is the public-facing NPCI UPI server. This involves parsing requests, responses, handling registration, etc.

2. There is the application code (red). This is the actual client-side code, say views, client-side logic etc.

3. CL, which is the NPCI Common Library. This is responsible for the same PIN screen that you see on every UPI Application. It takes care of accepting the PIN (or OTP/Debit Card) and encrypting it with the NPCI Public Keys.

4. Other code, usually third-party open-source libraries. Things like QR code scanner etc.

An effort to make a complete FOSS UPI application involves:

1. Getting NPCI to publish the CL source code.

2. Finding a bank willing to make its API schema public without getting them to bank your application.

Even if you find a bank willing to do (2), it is unlikely you can get (1) - leaving you with a partially FOSS app with a blob of sorts.

Finally, as anyone running NewPipe can attest to: none of this is technically impossible. You can always reverse 1 and 2 from any public UPI application for eg. But having one FOSS UPI application means opening a can of worms where there are infinite malicious UPI applications on the playstore.

Thanks for this. This finally led me to read more and download a bit of documentation.
I had the idea that the handling the request for authorization with NPCI happens at the bank when it forwards the request it receives via its API.

"But having one FOSS UPI application means opening a can of worms where there are infinite malicious UPI applications on the playstore." - That's true. But consider this one stupid question.

1 is reverse engineered to make a libre library handling making an authorization request encrypted with public key of NPCI.
Is there a possibility wherein a bank's api can verify the apk signature which removes the possibility of malicious applications in Play Store ?

The whole premise for this discussion was that we try to get new Kerala Bank to make the BANK API SDK open. We can stretch that pipe dream scenario to bank api trusting apk built and signed by F-Droid, which in turn is trusted by Free Software community.

Is there a possibility wherein a bank's api can verify the apk signature

Not at all foolproof (some bank apps try this, calculating a self-checksum and sending it to the server, but easily spoofed by sending a static checksum. This is just made easier by having access to the source), unless you use something like Google SafetyNet (not sure if this requires PlayStore).

Kerala Bank is currently not on UPI, so there might be more challenges on your way, but possibly higher rewards, since there might be chance of getting the Bank UPI Server as FOSS.