Merchant UPI Plugin — Marketing Hype versus Reality

By: Rahul Chari: Co-founder and CTO, PhonePe

There is a lot of buzz in the UPI payments space with multiple players in the fintech ecosystem launching their own versions of the Merchant UPI Plugin. The Merchant UPI Plugin is supposed to solve the following problems:

1. Lower success rate via the Payment Apps (Also known as TPAPs — Third Party Application Providers) intent model
2. Readiness of the Payments Apps for every new UPI functionality

In this blog, we will evaluate if these are real problems that will be solved by the Merchant UPI Plugin.

1. Lower success rate via Payment Apps intent model

All the players who have launched the UPI Plugin have claimed that there is a reduction in the number of steps required by users to make a payment with the UPI Plugin. Some even claim it reduces the steps from 5 steps to 1 step, compared with the payment journey via a Payment App (intent flow). This is more marketing hype than reality.

This is what the Payment App flow looks like:

Step 1: Customer selects a Payment App on the merchant payment page and taps on the pay button

Step 2: Customer is routed to the Payment App where the default UPI method is pre-selected. Customer reviews the UPI method to use and hits the pay button on the Payment Apps’ payment page

Step 3: Customer is taken to the MPIN page where he/she enters the PIN and submits. After this step the payment is processed and the customer is redirected back to the merchant application’s order confirmation page

UPI Plugin Flow:

Step 1: Customer selects a UPI account on the merchant payment page and taps on the pay button

Step 2: Customer is taken to the MPIN page (now embedded within the UPI Plugin SDK which sits inside the merchant application) where he/she enters the PIN and submits. After this step the payment is processed and the customer is redirected back to the merchant application’s order confirmation page

As you can see, there is one less step of customers being routed to the Payment Apps’ payment page. Instead, in the UPI Plugin model, the UPI payment options are rendered on the merchant payment page directly.

Let’s look at the potential improvement in success rate due to this optimization. The claim is that app-to-app routing causes drop offs and the UPI Plugin eliminates these since it is an SDK embedded within the merchant application. Below we examine how the app-to-app routing as well as invoking an SDK works on Android from a technical perspective.

App-to-app routing on android intent works on an inter-process communication (IPC) model. Invoking an SDK within the parent app works within the same process and within the same application. Technically, there is very little difference between these two models. The drop off due to inter-process communication will be extremely negligible (overheads of starting a new process for the Payment App and then communicating with the new process via IPC).

If the merchant application checks if the Payment App is installed on the user’s device and it is ready for payment (i.e at least one UPI account is linked and set up for payment), there should be no additional drop-off between the two models.

Now let’s look at what it takes to get UPI setup for users on the UPI Plugin. Every user for whom the UPI account needs to be shown on the merchant application’s payment page, will have to be onboarded on the UPI Plugin. There are four steps in the onboarding process

1. Permission to send SMS is taken from the user (this is to verify user’s phone number)
2. Device registration/binding basis sending of SMS
3. Listing of accounts linked to user’s phone number linking
4. UPI PIN set (if not already set for the account by the customer)

Most merchant applications do not take permission to send SMS. This is an additional point of friction and a potential drop off point. For those users who do grant the send SMS permission, the UPI Plugin SDK then sends the SMS using a VMN of the sponsor bank to register / bind the device of the user. Over the last seven years at PhonePe, we have seen between 40%-50% drop off in the sending of SMS and the device binding step. Also there are risk checks that need to be done to ensure there is no fraud in the SMS based device registration and binding. The liability of checking for these frauds lies with the application that is enabling the payment processing. Then comes the optional step #4. For new to UPI users, PIN set requires a debit card number to be entered. From our experience, we have seen that a significant number of users do not have debit cards although they may have a bank account which can be UPI enabled. Solving all of these challenges will need significant focus and investment from merchant applications.

There are two options for merchants when it comes to where the onboarding process can be introduced on their application:

1. In the pay path when a user tries to pay using UPI
2. Outside of the pay path (say payment settings where users can manage all their payments information)

The challenge with option #2 is that it is always hidden behind a couple of clicks and discovery is limited.

With option #1, it will drive contextual discovery of this new payment experience. However, given how the funnel conversion is for onboarding, it comes with its own risks. Users who land on the pay page of a merchant application have already made a decision to purchase and are looking to pay. Most of them would also look for a familiar payment option (say PhonePe or Gpay for UPI payments) when they land on this page. Now, to ask the user to set up something new on UPI in this context is interruptive. Hence this will come with its own cost — i.e payment page to order conversion will take a hit.

Given the above challenges in onboarding of users, adoption will be a challenge.

2. Dependency on Payment App for the development for every new UPI functionality

Now coming to the second point, to remove dependency on Payment App for every new UPI functionality, this model puts the onus of development with the merchant application. What this means is, merchants will have to invest time and effort to provide the UPI functionality that NPCI develops. Example: UPI Lite, Rupay CC on UPI, EMI on Rupay CC via UPI, etc. This involves significant work to continue offering the newer UPI options.

All this heavy lifting of building new UPI features and stabilizing them is done by Payment Apps today. This is non-trivial in terms of effort and ongoing upkeep. With large teams dedicated to solving UPI payments, Payment Apps are in the business of providing the best in class payment experience to consumers. This will now have to be taken up by the merchants. Moving this responsibility to merchant applications will only splinter the adoption of UPI features and slow down the pace of change.

The UPI Plugin model also puts the following responsibilities on the merchant applications:

1. Introduction and stabilization of new UPI features
2. Compliance with the relevant guidelines/ circulars issued by NPCI under the UPI Plugin framework
3. Maintenance and support of the onboarding and delinking process. Example: PIN set/reset is enabled with debit cards today. Aadhar based OTP is the new option and there will be new features which will continue to be added
4. Risk management for UPI onboarding to prevent frauds such as account takeovers
5. Customer support at all touch points — customer not able to onboard, not able to reset PIN, money debited but transaction is pending (what is referred to as DCR in UPI), etc.
6. Integration and support for the dispute management (UDIR) functionality provided by the sponsor bank SDK. All the eligible customer complaints and disputes should be routed via UDIR for UPI Plugin transactions
7. Promotion of sponsor banks app for any issues related to UPI via the UPI Plugin Flow — not all users would have downloaded the sponsor bank app that supports UPI
8. Meeting data localization and app security audit requirements

All of the above and more is being done by the Payment Apps today as they are in the business of providing the UPI payments functionality. However, for a merchant, the core business is not payments. It is an enabler for running their business.

Conclusion

The UPI Plugin model does not offer any significant technical benefit to improve success rates. It instead shifts the onus that exists on Payment Apps today to the sponsor bank and the merchant application. This model introduces more complexity and puts more burden on the merchants rather than helping them focus on their core business.