Hurdles we met trying to integrate with UPI
Our enthusiasm to integrate an app with UPI met with hurdles; some that we could cross and some just not yet. But, the possibilities are exciting.
Unified Payments Interface (UPI) allows money transfer between any two bank accounts without the hassles of typing in a plethora of details related to the receivers account. UPI works using a Virtual Private Address (VPA) that looks something like company@bank, and that is all anyone needs to know to transfer money to “company”. The money automagically is routed to the bank account that “company” has mapped to the VPA.
This brings with it a super potential for being the de-facto mechanism for allowing money transfer between a buyer and seller without a third party getting involved. Imagine a digital marketplace that collects rent from shops, but transactions between buyers and shops are no concern of owners of the marketplace. Isn’t this how it works in the real world? Now, UPI brings the possibility of this happening in the digital world without the need of a complicated payment gateway.
Our enthusiasm met with hurdles, some that we could cross and some not yet. But the possibilities are exciting.
UPI apps of banks
Unfortunately for me, the exercise hit a hurdle as soon as it began. UPI doesn’t yet have apps for iOS, and I was using an iPhone. I had to get hold of an Android device for testing.
Most UPI apps need a SIM in place to verify the phone number and query bank accounts. For reasons best known to banks and creators of UPI apps some accounts are just not ready! Polite error messages ask one to connect with bank branch or the app provider. The way out was with the help of a co-worker for whom BHIM, PNB and HDFC UPI apps were setup with accounts and transactions were working.
Available documentation
The next step was to find out how a merchant app could integrate with a UPI app. We tried a simple use case. All that needed to be achieved was from within an app to initiate a UPI transaction, at the end of which a message with status could be displayed. Typical scenario - a product is bought and the buyer needs to pay the seller directly. Buyer needs to be displayed a message about the transaction status. This works ok when both buyer and seller are face to face, they can use a UPI app of choice, scan a QR code and make payment. But how does it work when it has to happen via a merchant app?
The expected flow is
1. Buyer selects a product and places order within the merchant app
2. Merchant app invokes UPI with required information. (receiver VPA, amount, reference)
3. Android displays all apps capable of handling UPI
4. Buyer selects the UPI app of choice to make the transaction
5. UPI app does the transaction and presents the buyer with confirmation
6. UPI app passes control back to the merchant app with a response having information about the transaction
The Linking Specification document provided by the NPCI almost explains how this can be done. The document explains how merchant apps can use URL deep linking to invoke UPI apps on Android devices. It also provides a table on what response is expected, except it does not say where and how this response can be used. Creators of the document may have missed including some information because it was that obvious for them and they assumed it would be so for others.
Trial and error
We now had a needle (response) in a haystack (UPI apps) problem, and we did not even know how to identify the needle. We did not know if each of the UPI app would provide the response in a similar style and location. We wished the linking specification document would have made this clear and set it in stone.
After a few trials and meetings with helpful developers we figured the “response”, and thankfully two of the three UPI apps we tried provided the response in identical pattern. The one that failed to provide a response was BHIM, which presented the confirmation but refused to give control back to the merchant app.
Identical pattern of response by two out of three UPI app was good progress. Another step forward.
However, the information in these responses had nothing in them for the merchant app to reconcile with the request. The transaction references were those of the UPI app and not one provided by the merchant app. There wasn’t one parameter that could be used to relate back with the transaction initiated from the merchant app.
UPI is evolving
UPI is a fantastic initiative and eventually when all works well we will wonder how we did business without it. But for now, the integration is at best flaky, and improving it does not seem like one entity’s responsibility. So, when it is everyone’s responsibility we know what happens.
If testing apps on android was already a problem of plenty due to a variety of devices and versions of OS’s, the number of UPI apps available complicated it further.
BHIM announcement could not have come at a better time, making me wonder why NPCI didn’t lead the UPI initiative with BHIM. Why would you make each participating bank create their own UPI app and then provide an alternate that makes theirs redundant?
Adherence to guidelines
This is what brings in fear. Unlike a payment gateway where the merchant is working with a single entity and is developing an app to match gateway requirements, with UPI there is a dependency on a variety of third party apps and their adherence to guidelines and quality. Merchant app could initiate a transaction and never find out its outcome. Is there a way for a merchant app to query NPCI to find out the status?
Wishful thinking
A simpler solution for merchant integration will be for NPCI to provide a direct web gateway asking the same information as specified in the Linking Specification document and providing the same response with additional parameters to help merchants reconcile the transaction. Involving another UPI app in between is complicating matters and it truly isn’t required. Guess what, a web gateway will work for iOS too!
NPCI should own this and true to UPI’s name “unify” - make their gateway the single point of query. It’s really “sarkaari” to expect merchants to start a transaction at one place and expect to find the outcome from another place.
