UPI is a significant innovation in digital payments by NPCI. The UPI mission statement of democratizing digital payments and its focus on being a platform lifts the spirits of the digital payments ecosystem of India. Having seen UPI in its earliest form and launched as a payment method in PayU’s PSP stack, I have seen UPI struggle to match the approval rates of cards and net banking.
If UPI has to succeed as a trusted digital payment method, it will have to match the debit card approval rates, which typically range between 70-75% as an industry average. Let us look at some of the challenges in UPI and how to resolve them.
An asynchronous payment method leads to cart abandonment
A typical checkout experience in India expects the following user interactions:
- Select a stored card, enter card details or select a Netbanking option
- Get redirected to the bank’s ACS or Netbanking portal
- Complete 2FA or a similar authentication
All these steps happens in the same web-browser or mobile-app without user having to switch context. This is where the first challenge in UPI sets in. UPI is designed to work as an asynchronous payment method. The payment, in the case of mobile apps, can only be completed on the customer’s bank app. [There is an alternate flow for the web, which leverages MPIN-based hosted by NPCI. In the interest of mobile payments, the dominant transaction source in India, let’s however focus on app-based flow which is designed as an asynchronous payment method.]
A merchant enabling UPI as a payment method sends a payment request to the customer’s VPA (Virtual Payment Address). The customer receives a request on her bank’s mobile app and makes the payment through the mobile app. Upon success of this transaction, which the merchant identifies by polling a web service, the customer’s order is placed successful. Imagine this on a mobile phone where you have to switch apps for making a payment, and add to this the network chattiness we so often experience. This payment experience is going to face lot of drops.
Payment experience and inter-operability
In order to enable UPI on their mobile apps, merchants (or their PSPs) need to integrate a UPI mobile SDK that is provided by their partner bank. The bank’s SDK can natively launch its own bank’s app when a UPI payment is triggered. However in cases when the customer has a VPA of a different bank, it communicates with NPCI making the customer wait for a notification – often the customer has to switch the app manually!
UPI’s mission is to make payments (and not just funds transfer) inter-operable. The architecture is design around a four-party model (Sender and her bank, Receiver and her bank). While this is operationally active, it is time it is enable in the payment experience. It should not matter whether the merchant’s and the customer’s banks are the same. The merchant UPI SDK should always trigger the UPI:// deep-link that will launch the customer’s bank app irrespective of whether the SDK bank is same or not. This makes the payment experience consistent and truly inter-operable across banks.
SMS vs Push notifications
In addition to the design limitation in the payment flow, UPI relies on push notifications instead of SMS. Push notifications can be delayed and often unreliable for eCommerce payments that can have payment expiry constraints – imagine trying to book a ticket using a payment method that relies on push notification. You are highly likely to miss that favorite seat of yours!
Instead sending a SMS with a deep-link (upi:// ??) supported by the banks works most effectively. Since P2P use-cases do not need the SMS reliability, the cost of SMS-based notification can be passed to merchants or aggregators who wish to use this instead of an in-app notification.
I hope our friends at NPCI are listening and as they have done for RuPay, will rise to turn around UPI into an established digital payment method.