 Each time I made an online payment, even the most well designed app, the payment experience erged me. All those poorly designed bank pages that endless wait for that 6 digit ODP to come from few seconds to few minutes, come, come, come, it felt wrong. After all, isn't the payment just about moving some amount X from account A to account B? As a tech person, we thought it's a 10 member team problem. It didn't be an India wide problem. You don't need so many people working on it. We said this needed to be fixed. Right, working with some very large banks, the deal then go through as expected. Then build a payments browser. It's there in almost all big Android apps in India. Solved the payments experience problem to an extent, but the core problem remained unsolved. While we were doing all this, some bunch of guys in India came up with this very unique idea called UPI, Unified Payments Interface. It was bullseye. It systematically solved the payments problem in India, to an extent where it became as simple as get an email address, set a four digit to six digit UPI pin and move you're ready for payments. You don't need anything else. No longer you have to remember those extent digit card numbers that CVV, all those things gone. Unlike traditional payments, payment system, not just push payments, UPI supports even full payments, meaning you can not just send money to someone. You can also request money from someone. Hello, everyone. As she said, I'm engineer at Jaspe. Our UPI story began with UPI since the very beginning, got a chance to look at the initial draft of the UPI specification. We got an opportunity to build him for India. And we powered UPI stacks for a lot of these big merchants like Ola, Amazon, Uber, et cetera. Okay, forgive me for my bias, but I am extremely amazed about this unique payments protocol of India, UPI. And I'm glad that this is not something which we borrowed from best. This is something which we have bet all by ourselves. Although I hear a lot of people talk about the UPI growth stories, the numbers, the pays, the phone pays, but very little is spoken about why UPI is so scalable, what happens under the hood, when a transaction happens, what is really going on, what makes it interoperable. Today in this crisp talk, I would like to show some of the internals of UPI and would like to, if some of you have not yet integrated UPI in your merchant apps, we'll give you pointers on how you should go about. Okay, let's take a very simple scenario. Let's say I want to make a payment to someone, Wimble, rupees 5000 on UPI. What does it require? They request that both I and Wimble should be on UPI network, and I should know Wimble's payment address, which is like his email ID. And I should obviously remember my UPI pin. So first of all, let's assume that I'm a Veeam user. My payment address is the LAPAT UPI, and I want to make a payment to Wimble. I open my Veeam app, I key in Wimble's payment address. Wimble at YBN is a phone pay user and amount. And then my UPI pin, which is encrypted by the common library. I'll talk about the common library in my coming slides. So any payment in UPI has four steps. One is initiating, second is VPA resolution. Third is the debit credit leg. Fourth is the acknowledgement leg. So I initiated a transaction from my Veeam app. I have the, this goes to the UPI switch. Now UPI switch is like the central router, which is responsible for orchestrating this whole transaction. Talking to different systems and helping the transaction go through. We have sent my Wimble's UPI address, amount encrypted pin to UPI switch. That's the first API, which is called RecPay. From there, UPI switch, looking at Wimble at YBL, the domain part of the VPA knows, okay, I have to ask phone pay for the actual bank account, which is mapped to his payment address. So UPI switch initiates a request to phone pay PSP, where phone pay, all PSPs maintain this VPA to actual bank account number mapping. So phone pay will have a table which looks like Wimble at YBL is Kotick bank account, this is his account number, this is his IFSC. Kiran at YBL, this is bank account, this is his IFSC. So phone pay replies back saying, okay, Wimble has a Kotick bank account, this is his account number, this is his IFSC code. That's it, we are now ready to make a real UPI transaction. We have account numbers of both me and Wimble. We have the encrypted MPIN, we have the order details like amount. Now starts the debit credit leg. So since I had a access bank account, the first debit UPI switch is responsible now, is now responsible to go to access bank and say, hey, access bank, can you debit the Lips account, my account number, this IFSC code with amount 5000. The debit request goes, the encrypted MPIN is now unfolded by access bank at that point, is verified, access bank will have all their other checks, rate limits and other things. Once it passes all those checks, the access bank replies back, okay, you can proceed, the debit is successful. Once the debit is done, now the credit part, where since Wimble had a Kotick bank account, the UPI switch is now going to go to Kotick bank and say, can you credit rupees 5000 in Wimble's this account, this is the IFSC code. This completes the credit debit leg. If both of them are successful, the transaction is done. Now the notification part is left, which is notifying since I am still waiting on my BMAM, waiting to see the transaction status. The last part is the notification leg, where the UPI switch tells the initiating PSP, the payer PSP saying, okay, the transaction status success or failure irrespective of that, it notifies the payer PSP and similarly notifies phone pay saying, hey, Wimble got rupees 5000 from Dilip at UPI. This is UPI in nutshell. This is what happens under the, each time you make a transaction in phone pay and all this in very good latencies, they have very good latencies, SLAs and these things. Okay, so some of you might be wondering, okay, we talked about encrypted MPIN, but where are the two factors? RBI says all transactions should have two factors. Where is the two factor in UPI? So one factor is the MPIN. The other factor is the acquiring PSP is responsible for maintaining that other factor, which is, most of the PSPs are using device fingerprinting and techniques like that. So in my case, since I had a Bheem bank, Bheem account, Bheem was responsible for one of the factors and the actual MPIN is verified by my core banking system, which is Axis Bank. In Wimble's case, since he was a phone pay customer, phone pay was responsible for his one factor and MPIN was to be verified by Kotak. So we said this encrypted MPIN again and again, right? How is this happening? NPCI has provided an encryption utility, which both Android and iOS, which is responsible for capturing this 4-digit or 6-digit UPI pin. It encrypts right then in the source so that even the PSP, even the Bheem and the phone pay cannot see the UPI pin. The encryption happens at the source and that again is unfolded at the core banking system. So this is the second factor authentication. I think now we understand why they say, right? UPI is interoperable. Why is it UPI interoperable? Because I didn't even have a, I didn't register on Axis Bank PSP. I registered on some Bheem PSP. I wanted to transfer to some phone pay PSP address. He had a Kotak bank account and I had an Axis Bank account. This is by the way called the 4-party model of UPI. This makes it interoperable. Whoever is innovating on the PSP front gets the customers. Whoever is providing good SLAs and all, maybe they retain their core banking customers. But anybody is free to choose their own PSP and I think they have mandated for all of these PSPs to allow moving to some other PSPs also. So let's look at some of the possibilities. Since I have a short talk, I'll be rushing through the talk. So let's look at some of the interesting possibilities. My favorite one is this auto debit. Not yet launched under development UPI 2.0. Some guys in our office are already coding this feature up. So what is this UPI? If some of you guys have already used SI on cards, credit cards and all, all these recurring payments become really simplified. Making a postpaid bill payment every single time on the first of every month you have to key in your credentials, make that payment, all that will be gone. All a merchant has to do is say, hey, I want a merchant initiates a request saying, hey, I want to debit 1000 rupees monthly, weekly, all these are configurable and you have to authorize once using your MPIN. All subsequent requests will be happening in the background. Customer doesn't even have to key in any of his credentials again. This, this brings us very close to the zero click payments, which we might have seen in U.S. and these things where now you don't have to worry. You are a frequent Uber user. Just give a mandate to Uber and that's it. All your payments will happen. A Paytm like experience is possible from your real bank account. This is the power of UPI. This is yet to be launched and the customer is the king here. Customer can revoke the mandate at any point of time. It is mandatory for all PSPs to give an option for customer to revoke all these mandates which he gives to the merchants. Second interesting things. This is something, this is a sort of a hack which you can do. Merchants can do, merchants can request a flexible VPA from their PSPs saying, okay, whenever there's a payment from LIC, on the payment address which is of the format LIC- let's say a 6 digit number, please forward it to me where the LIC will see, okay, this is my policy number. Let's say 0112358 is my policy number. Each time I make a payment to that VPA, automatically my premiums will be paid. Similarly, a recharge will be as simple as R- your mobile number- your network at Paytm and boom, your recharge is done. Merchants can request this from their PSPs. All this is possible. Third one, UPI on delivery. This is also interesting. Things like we were doing a pilot in Bangalore with LPG and the petrol pump guys for providing a UPI solution. What we did was on the day of delivery, we sent a collect request, a pull payment request, saying, hey, your gas is going to be delivered today. If you want pay via UPI, 500 rupees collect request. And we saw just by doing that, we could convert at least 10% of the overall transactions. We didn't give any offers just by giving that flexibility. A lot of interesting use cases can be built. In one of the regions in our pilot, what we saw was when the LPG delivery guys wore the static QR codes and went to the houses, they could convert 40% of the transactions, overall cash transaction into online. And none of this was run by offers or something. If some of you have not yet integrated UPI in your app, there are two ways to do this. One is the in-app payment. Second is the collect request. The building blocks remains the same. You have to go and create an account with a PSP, be it Access, HDFC, PhonePay. You have to create an account with them. They'll probably share some API keys with you. And the merchant server using these API keys is the right to access to talk to the PSP servers and optionally you might integrate a UPI SDK in your merchant app. This is roughly the architecture for both the approaches. So in-app payments, here your PSP will give you a UPI SDK, which is roughly about 500 KB in size. Good thing is you don't have to worry even if your customer is not already on UPI, he can do a in-app registration and make the payment. Bad part about this is you have a 500 KB bloat which will come into your app and if you're really concerned about the size, maybe this is not the right choice. The flow looks very simple. Invoke UPI SDK with the order details saying I want to collect rupees 500 from him. The UPI SDK does all the heavy lifting of talking to PSP server, talking to common library, getting the encrypted MPIN, and finally responds back with the status to you, which you can again, you advise to go and check with your server what was the current status. Second is the collect request where Uber started this way where they didn't, let's say you're still experimenting, you're not sure whether to go all in in this network. You can do just two API integration. One is the collect request API and second is the transaction status API. With this you will be able to collect. So you have to ask the customer to enter his payment address. At this point a collect request will be sent to him. He has to open his PSP app and make the payment and meanwhile you have to constantly poll for the transaction status. Problem with this is there's this app switching cost you might lose out on your customers but it's a if no increase in size is your criteria this is the way to go. So after having integrated with nearly UPI stacks of nearly 10 to 15 banks we have some learnings to share. One of the key problems which we saw is this missing acknowledgement problem. The part where the PSP server is supposed to tell the merchant server saying this transaction was successful this was failure right. What we saw is surprisingly at least 10% of the transactions we didn't get callbacks from the PSPs and this results in a very bad customer experience as the payment has already happened but since you don't have a status you show that order is still in pending state. A way to fix this which is sort of a hack is ask for a transaction search API or a transaction list API from your PSP so that you can ask your customers okay key in your RRN and I'll look up the system if it's like push versus pull and settlements still banks lot of banks are having manual settlements though it's UPI instant they don't typically provide instant settlement but you can always request problem with that is you will have your bank statement with lot of these small entries if you have small transactions going on but you can always request a instant settlement where you will get the money instantly in your bank account otherwise these bank systems are still evolving they take typically settlements are delayed which is not acceptable for small merchant at least from our experience they will go crazy if a settlement is delayed by by a day or two this is a UPI story so far some numbers and I think latest what things to look out for is UPI 2.0 I'm also personally wait waiting for the launch of UPI 2.0 some really amazing delightful consumer experiences can be built once we have UPI 2.0 rolled out and I think WhatsApp is soon going to launch UPI in their apps that is some something that's it guys so if you have any queries I think I have an office hour from 1 to 3 any questions I think if we have time I can take questions you are just on time