43. UPI

Aditya Kulkarni
Auth-n-Capture
Published in
9 min readMay 2, 2020

UPI is the most interesting and simplest of the payment modes but equally complex in working… isn’t it the case with anything that looks simple from outside? This will be a super long chapter and still, I might fail to cover everything… so bear with me

Let’s start and let’s start from the very beginning…

Illustration A

I cut a tree and you give me one chicken… I give you three chickens and in return you give me one goat… that is how humanity started transactions… I am sure our ancestors debated for hours about how many chickens are equal to one goat… of course, they had plenty of time in hand. Humanity evolved so did the trades and services and so did the currency… Thank God we reached this stage where we have standard currencies, else, imagine receiving 1000 chickens as salary… Ufff!

Today, we do various types of transactions: P2P (C2C), P2M (C2B), B2C (P2M), B2B, G2C and C2G… (P=Person, C=Consumer, M=Merchant, B=Business, G=Government) that means we need an efficient way of transferring funds… It started with cash, cheque and demand drafts, and then we moved online with RBI’s NEFT and RTGS. Then came NPCI’s IMPS which works in real time and 24x7… But IMPS has limitations (a) Need to collect other party’s account details (b) Add it as beneficiary in your account (thus, delay to start the first payment)

Then came the most disruptive payment mode — UPI (Unified Payment Interface)… The idea is simple — take the best part of IMPS and make it simple & mobile friendly.

Let’s start with basic jargons and entities

  • VPA (Virtual Payment Address) or UPI ID: Looks similar to an email ID (9192939495@upi or tony.stark@okhdfc). You would need a bank account and valid debit card to create a VPA
  • Issuer PSP: Bank/PSP that creates the VPA
  • Acquirer PSP: Bank/PSP that processes VPA transaction
  • Issuer and acquirer talk to each other via switch (UPI Switch which is managed by NPCI)
  • Payee: Person/entity which is receiving the money in ‘beneficiary bank’
  • Payer: Person/entity who is paying the money from ‘remitter bank’

[Isn’t it similar to card transactions? A unique card issued by the issuing bank and transactions processed by the acquiring bank via card scheme]

Virtual Payment Address (VPA) or UPI ID

VPAs are interesting not just because they look like email ids but there are other things such as

  • One VPA can be linked to multiple banks (but one bank will be primary)
  • A bank account can be added or deleted
  • Multiple VPAs can be created on a single bank account
Illustration B

Security — Device and PIN

Didn’t I say that UPI is mobile friendly? That is great but that is not sufficient unless it is ‘super’ secure. Security is achieved by device binding combined with PIN or fingerprint to open the UPI App and another PIN to perform the transaction. In summary, UPI follows 2nd Factor Authentication (what you have and what you know) as prescribed by RBI.

UPI Apps:

Two types of entities can develop UPI Apps

  • Bank (ICICI, HDFC etc.)
  • FinTech Companies/merchants (PhonePe, AmazonPay etc.) — But only a bank can create VPA or connect with an NPCI switch. So these companies tie up with bank(s) (e.g. PhonePe — Yes Bank and ICICI Bank, Google Pay — HDFC, ICICI & a couple of more)

Payment Flows:

Ishan and Nijesh went out for dinner at Nandos. Nijesh owes Rs.750 to Ishan. Both of them have UPI Apps, so either Nijesh can transfer funds to Ishan or Ishan can ask Nijesh to transfer the money via a UPI App… here is how the transactions are done…. Wait.. wait… let’s add a few complexities…

There are two types of payments

  • Pull Payment: Payee (Ishan) sends collect request to Payer (Nijesh)
  • Push Payment: Payer (Nijesh) initiates the transfer to Payee (Ishan)

Also, the flow varies depending on the number of entities involved; here are few combinations: Two Party Model, Three Party Model and Four Party Model

Illustration C: Two Party Model
Illustration D: Three Party Model

I will go ahead with Four Party Model (Payer PSP & remitter bank are separate entities and Payee PSP & beneficiary bank are separate entities) and let’s see how ‘Pull’ and ‘Push’ payment models work

Illustration E: Payer initiated P2P transfer (Push Payment)
Illustration F: Payee Initiated P2P transfer (Pull Payment)

Merchant Transactions:

If a merchant who wishes to collect funds via. UPI then the merchant would require a VPA. Current or nodal accounts do not have debit cards — so how will a merchant create a VPA? In this case, the acquiring bank will create a VPA for the merchant. Merchants can enable UPI by integrating with either an acquiring bank or a payment aggregator, who in turn, uses acquiring bank(s) or directly integrate with a UPI App (e.g. PhonePe)

Let’s do the transaction now… there are two main flows (Let’s see the user journey)

Collect Flow:

Illustration G: Collect flow

Positives: Works on all platforms (website and mobile Apps)

Negatives: (1) User has to enter the VPA — user may not remember the VPA and can make typing error (2) Broken Flow — User has to enter the VPA on website and then open the App on the mobile to complete next steps (3) Lack of visibility — Merchant will not have any idea whether collect notification is received by the user and steps he is taking

Intent Flow:

Illustration H: Intent Flow

Negatives: Works only on Android (Although Google Pay and PhonePe offer an open intent on iOS but integration is App specific)

Positives: (1) No need to enter the VPA or scan QR code (2) App-to-App switch: seamless user experience (3) Merchant will know whether the customer has a UPI App on the device or not (so little less darkness w.r.t. user’s actions) (4) Definitely better success rate compared to collect flow

Other UPI flows:

  • In App Flow: wherein the common library is opened within the merchant’s App
  • Google Pay’s unique flow: G Pay creates a UPI ID in this template (thanos.titan@okicici) but it is difficult to remember. So instead, you enter a mobile number and it resolves the UPI ID attached to that mobile number and then proceeds with the UPI transaction flow… Super Cool !!!

How do we improve the Success Rate of UPI transactions?

As you noticed, there are many entities and actors involved in completing one transaction. And each step, entity and actor is a potential point of failure… Here are few things that can be done to improve the success rate

In general:

  • Use multiple acquiring banks to do smart/dynamic routing based on performance and availability
  • Be Proactive: If the issuer or switch is having issues (performance degradation or downtime) then show appropriate warning messages so the customer can choose an alternate payment mode

In Collect flow:

  • Validate the UPI ID/VPA before initiating the payment (remove @google.com or @upi.com handles, spell check @okhfc — don’t allow user to press ‘PAY’ button until such obvious mistakes are corrected (similar to how you do BIN check or run Luhn’s algorithm on card number)
  • On website, include UPI QR code so user doesn’t have to type VPA but just scan UPI QR Code
  • Save VPA/UPI ID of successful transactions (no need to enter every time)
  • Reduce typing requirement: Allow customer to select App first then based on App selection and user information (e.g. Mobile number and mail id), populate the VPA (e.g. if customer selects PhonePe then populate VPA as 9192939495@ybl)
  • Use G Pay’s mobile number based flow (to avoid typing of VPA in case of G Pay)
  • Show a timer expiry (how much time is left before the collect request expires) — Don’t we all work faster and efficiently when we are closer to the deadline… shoosh!!!
  • Utilise the wait page to educate the customer (highlight next steps: you will receive notification on your XYZ App, open App, enter PIN etc…etc.)

Intent Flow:

  • Implement intent flow for mobile App (higher success rate than collect)
  • Show only better performing Apps (blacklist others)
  • If you only want to show top 2–3 Apps, then have a placeholder so that the user who uses a non-popular App can enter the VPA (and initiate payment)

Additional Features:

A. QR Code

QR codes are an innovative way of making payments… QR code is nothing but payee (receiver’s) VPA in QR format. There are two types of QR Codes: Static (where the amount has to be entered by the payer) and Dynamic (where the amount is already embedded in the QR).

Both are equally efficient solutions for different use cases. Static QR fits better in case of brick and mortar stores (stick the QR near the checkout counter) and dynamic QR can be utilized perfectly in converting Cash on Delivery cases to online payments (embed the QR code generator in delivery person’s App so he can generate a QR at the customer’s door )

B. Custom VPA

Let’s say a B2B merchant who caters to 10000+ retail companies and the company wants to implement a UPI solution where retailers can collect payment from its customers.

A custom VPA based solution is a good approach as the merchant can create unique customised VPAs for each of the retailers — easy to reconcile and to facilitate settlements.

C. Mandate: One time to Recurring

When NPCI announced about UPI 2.0 in 2017, many waited eagerly for the recurring mandate but only to be disappointed as UPI 2.0 did speak about mandate but only a one-time mandate. What good is a one-time mandate? As expected, it didn’t do well except in one case… i.e. IPO pre-bid (try it on Zerodha during next IPO).

Finally, the recurring mandate has arrived… I think it will solve many issues of existing recurring payment solutions (NACH, eMandate and SI on Cards). Many P2M use cases such as Mutual Fund SIP, mobile Postpaid bill payment etc. can use this solution. But adoption by the NBFC sector will purely depend on whether the solution is covered under Negotiable Payments Instrument Act or not.

It will be really interesting to know whether banks will extend recurring mandate to P2P Cases (e.g. Recurring monthly rent payment to your landlord)… Let’s wait and watch

D. UPI Payout

UPI is a perfect solution for many B2C (M2P) payout use cases such as vendor payout, incentive payout etc. UPI runs on IMPS so the payout is done in real time and 24x7. You need a source account, UPI rail and UPI ID of the beneficiary to transfer funds. Merchant can validate the UPI ID before initiating a payout to that UPI ID and thus improve the success rate. (refer payout chapter for more details)

In a short period, UPI gained tremendous popularity among users as well as merchants… and numbers don’t lie… Users appreciate the convenience and merchants are thrilled with the performance & cost (the most economical payment mode). Many merchants (Cred, Ola, Swiggy) are nudging users towards UPI for these obvious reasons…

This is where I end this article… but there is more to write about UPI mandate, working of popular PSP Apps but maybe some other time…

Thank you NPCI, thank you Nijesh for teaching me UPI and a super special thanks to Ishan who forced me (and everyone around him) to love UPI :)

--

--

Aditya Kulkarni
Auth-n-Capture

Trying to follow Richard Feynman’s words “do what you can, learn what you can, improve the solutions, and pass them on”.