Hurdles we met trying to integrate with UPI

Hurdles we met trying to integrate with
UPI
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 Best 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 Best Upi App 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 Best 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.
Source: http://tinyurl.com/z38zd6l