 Hello everyone. My name is Arun. And I was head of payments with the free charge in my as my earlier job. So I used to be so I was a part of the team that we have seen the journey from fairly rudimentary payment integrating with the payment gateway and then getting it all the way to you know, where we were today right. So this talk is primarily about what lot of companies are going through nowadays when they integrate with payment gateway. So the way it usually happens is that, you know, the you have payment page and then as an engineering team, you have integrated with the payment gateway. And once you once you open it to the external world, it turns out that the payment success rates are quite terrible, or it could range anywhere from 50% to all the way to know if you're very lucky, it might end up somewhere between 75 to 80% right. The if you think about it from product or business standpoint, so if you if you think from, if you think from a product or business standpoint, in any, when you when you try to buy something any any portal, which which is trying to sell something, the hardest part is for a customer for a for a customer is to get him to the payments page, right, where the intent is very high, and then he has made the purchase decision. You know, I want to buy this buy this camera and so on. And once it's like once the person lands on the payments page, that from then onwards, the intent is very high. You know, I really want to buy it. I have entered my credit card. I'm about to get into my net banking and so on. But then after that, it is a it is a cliff, you know, the only about 50 to 55% of the customers is whom convert from payment page or rather payment request to payment success right. So so this talk is this talk is primarily about you know, what can we do about it? No, I'm not using it yet. So what what as a product managers as engineers, and as business owners, we can do about it to you know, improve this right. So so let's start. So let's look at it. Look at a typical payment journey from a customer's viewpoint, right? So right, so you go to a website. Okay, so the so you you are made, you entered some, you know, product information, I want to reach my postpaid number. There are details and then I have landed on my payment page, which is what you see on the right hand side, right? And you click on pay button. And then you desperately wait for like anywhere between 20 seconds to one minute, right? You don't know what's going on. When you see your browser status bar, you see that there is like anywhere between half a dozen to one dozen redirects are happening. And then there's like huge weight like really huge weight, right? So if you're lucky, you end up on this page usually, right? Okay, then you you choose and and God forbid you are using mobile device. This is not mobile optimized by the way this is a desktop site. Okay, so you, okay, you select OTP page and so on. And then the weight again begins because you have to get an SMS or do whatever. And and this is a mobile device. As you can see how usable this is, I'm expected to enter a six digit number. And what I have is actually a, you know, alpha alphabetic keypad, I have to do a bunch of context switch and so on, right? Fine. You you go through that hurdle as well. And then the weight you again desperately wait, you know, really praying after this, typically one of the three things happen depending on your luck factor, how the planetary alignments are and so on. If you are lucky, everything goes through well, you know, payment goes through. You get your product recharge or whatever. If you are key, it doesn't go through, right? For it could be for host of reasons, right? So one of them is stated here is it says, you know, because of the network connection. It's generally you know, you had some bad day or it's you had some bad connectivity. You it doesn't go through fine you what you do is you end up retrying and whatever. But if you are really unlucky, you end up in this situation, right? Where you get a payment failure message, but the money gets deducted from your bank, right? And then you don't know what to do. You you write to a bunch of customer surveys, you know, you post on social media, you know, angry messages and so on. Hope that someone takes notice and then refunds you the money, right? So from the customer standpoint, this is where we are, unfortunately, right? This is like state of the art 2017. Okay. So let's see from the from the people who are building this entire ecosystem, what the situation looks like, right? So what is on the payments page? You saw a bunch of things. There was offers page, there was a saved card, you know, I had to get my all my payment methods, they're like credit card debit card and so on. So product managers being product managers, they want to show absolutely everything, right? So they have to show all the options. Then what ends up happening is okay, you end up writing a service to fetch the payment options and displayed on the payments page, right? Cool. So now you want to improve the user experience. I want to store the cards. I want to fetch the card details and so on. You write one more card storage service, you make a call and then get it. But they want to stuff in offer also, you know, along with the payments page, right? So I want to, okay, fine, I'll integrate with this. I'll make one more one or two API calls and then let's move on, right? So this is remember just to display the payments page. We are not, we have not begun the journey yet. Okay. So and once the customer clicks on the make payment button, this is where the real fun starts. This is where, yeah, so the fun starts here. So the typical call lands on the application server page, application server box. And then there's a bunch of business logic to generate the order ready. You do a bunch of checks, you know, whether he's eligible to buy this or not, you know, prepaid, postpaid, whatever it is. Everything passes, you do the order generation. And then there are a bunch of fraud control checks as well, right? Is this a stolen card? You know, am I exceeding some throttling limit this that right to do a bunch of checks as well? And then, you know, am I eligible for the offers, whatever? Okay, passes through. So out of from this point onwards, the control is absolutely out of everyone signed primarily, right? Customer doesn't know what's happening. Application developer doesn't know what's happening. So this is what typically happens, right? From the application server, the call goes through payment gateway aggregator. Then there is a payment gateway. Then there's a card network. Then there's an issuing bank. Okay, so I have simplified things a little bit. But this is what happens. And then remember, each of them is a browser redirect. Okay, which is I will come to it. Why it's really bad. This is an onward journey. And then the reverse journey is again, you go back from machine bank to card network to PG to payment gateway aggregator, right? So, right? So now we now come to the, you know, the actual problem statement. What's we have already know, you know, why is it the payment convergence so low? And then why is it the user experience so bad, right? So in this entire journey, there is more than a dozen drop off points where user will just disappear. You know, they might close their browser, they will navigate somewhere else, so on and so forth. And for the, for the application developer and the product managers and business owners, there is no visibility into where the customers are dropping off. Because once the control leaves the servers and then lands on the payment gateway aggregator, it's like, it's a black box, right? And so this is what we found out during analysis, while we are, you know, like pulling our hair out, you know, why is it where are people dropping off? We realized that or rather we found out that 80% of the payment failures are just drops. What it means is that people make an attempt to pay, they click on the make payment button, they just don't come back at all. We don't, we don't hear back from them what happened to them, right? This is a real bad situation to be in because we don't know, like, if you, if you know why people are dropping off, you can at least try to optimize, right? Here we don't know what's going on. And from user's experience, I've already covered a bunch of this, this like high latency, you know, there's a bunch of spurious debates. And then there are security concerns as well on top of all this, right? So, so this talk is now about how do we tackle these various points, right? So there is, there's a payments page, there is a funnel, how do we handle response and so on so forth. Let's begin with a payments page. So if we take a look at this again, it's not very clear, but on the left side, you see there is a product information on the middle. The first two panels are product information on the right hand side is, is where customers are expected to like enter the credit card debit card and then make the payment click on the payment button, right? So can someone tell me what is one thing wrong about this page? Just one thing, if someone can, there is probably like dozen things wrong, but I'm just asking for one, which can, right? Oh, that's, that's fairly standard. There's like, there's something called MSCVN, the, looking at the prefix you can get to know. So, so if you look at this page, there are about close to half a dozen points that are grabbing users attention. Okay, so I, I have filled all the details already. I am at the payments page, but then I get get distracted by all these things. You know, I'm given option to change my number, change my carrier. You know, I can edit my billing amount. There is a something about promo code. Then there is all very inconspicuous text about, you know, expiry date and CVV are optional, blah, blah, blah, blah, which is it really matters, but it's like real inconspicuous, right? So, so this is a first thing you'd like to do is this is all, all the actions are called this, this points are typically called call to actions or CTS, you know, which is if there is a pay button, you. Where is it that you are trying to grab users attention, right? This is, these are called action points and then these are CTS or call to actions. You would like to reduce the number of distraction points or reduce the number of call to actions. The guy is already ready to pay, you know, just make him focus on the task. Don't ask him to do something else, right? Because I have made my purchase decision. Don't ask me to edit my cart when I'm ready to pay. Okay. And a good thing, good byproduct of this is that for engineering and for tech guys who are building it, it reduces the business logic and then overall flow drastically. Because you, you try to, okay, you are at the payments page, you know, you want to edit your amount. Then how do you handle it? Do I generate a new cart or do I edit the same cart? If I edit the same cart, I have to handle the concurrent request and so on, so forth, like whole bunch of edge cases open up. Okay. It drastically improves your engineering effort. If you reduce the number of CTS, it has direct correlation, right? And one more thing, clearly it reduces the failure points. Okay. What if the offer services down? How do you handle it? What if the cart updation not doesn't work? Okay. So again, one more point to drop off. Right. So we already covered this. And then there are a bunch of spurious fields in there because. No. Not many people know at least the people who are building the payments page know that the card on the name on the card is actually not a mandatory to process your credit card debit card. Okay. But still a lot of companies, a lot of online portals expect you to fill it and then they make it a mandatory field for some reason. Okay. It is one more distraction for me to enter the name and then, you know, a whole bunch of things can go wrong there. Right. Next. So the very, very crucial point here is to get your validations absolutely spot on and then fail fast. Okay. I'll talk about what the meaning of fail fast in a minute. So there's a bunch of fairly. Well documented. Validations that you can do on a credit card or debit card. There's like lunch check. There's expiry. There is CBV check. And there is something called SBI master called there. It follows a different trajectory altogether for some reason you have to be aware of it. Unfortunately, SBI master happens to be there are just a number of cards in circulation in India right now. So you have to handle it and then you have to know what it is. And it's. When I'm trying to enter my bank's card and then as an application, I know that that bank is down. There is no point in taking me forward. Okay. Please alert me right up front so that I can use my friend's card or someone else's card or do something about it. So this is very important thing. So every card, the first six digits of a card is known as a bin. It determines what is it called as a bank. Bin bank identification number. So it uniquely, uniquely identifies the bank to which that card is issued to. Okay. There are publicly available API soluble, which will tell you given the first six digits of a card, which bank it is, what type of card it is and so on. Good thing about using this is that some of the banks may not allow you to use to purchase certain kind of goods for whatever reason. For example, SBI is really hates people doing recharge using their cards. Really. Okay. So it's better to tell me up front that, you know, if I'm entering a SBI card, dude, you can't use it. Please do something else about it. Right. So, okay. Now the failing fast is I would rather want a error message to be shown up on the payments page than five steps down the line. Don't do that. Okay. Because here the customer is in your control. You can, you can handle the customer to do what to give him alternate payment method extending my credit. You can do a whole bunch of things. But once customers goes to the payment gateway or payment gateway aggregate or some issuing bank page, like you lost him. Okay. So now there is a bunch of very, very generic you are recommendations. So just prominently display, you know, all the cards that you expect to be accepted on the, on the website. It's a, it inspires confidence. And so you would have a bunch of security credentials, be it in terms of PCI DSS, be in terms of now turn security seal, a whole bunch of things. Just displayed prominently on the payments page. Again, it inspires customers trust and customers confidence, you know, very well. Right. And gracefully handle repeat customers for God's sake. So don't ask me to go through the entire pipeline every time. You know, you know that I, I use HDFC net banking, like don't ask me to click five buttons again and again. Right. Make it a default selection. And then let me go ahead. And so this is a really, really important point, which is how do you handle the payment failures, which is quite frequent. Okay. So do, do you get the customer to land him on the payments page or do you get him to do throw me throw him all the way to the product page? Right. The choice is obvious. Retain is focused on the payments page and then don't make me refill all the details and again and again. If the details are like credit card, it's like really painful. I have to take it out and then enter again. One more general recommendation on a mobile devices, especially I, I typical actions are, you know, you click or you swipe. Don't expect me to type a bunch of things again and again. This is a, I don't know if you can see it. So here this widget shows that, you know, on the right hand side, you can see that I already have saved cards, but it is defaulting to and asking me to enter credit and debit card again for some reason. Right. So I have saved card. Select it already. You know, don't make me to click one more button or screen. Okay. Right. So this we already covered. So the input is expecting a number and then you opened me alphabet keypad, like really bad. Okay. Right. So we covered the payments page as such. Now we will talk about the, the middle of the funnel, which is how do we handle from payment, the button click. Now we have gotten the user to click on the payment button. How do we, you know, optimize for funnel down the line. So there is a central theme for rest of the talk, which is, you know, there are two things you should know the things that you can control and then things you can't control. Right. So what are the things you can control is you can control latency and then you can control number of browser redirects. Okay. So things you can't obviously control are that the whole thing I talked about, you know, there is a payment gate, aggregator payment, gateway bank issuing that we can't do anything about it. Right. And of course, OTP is SMS delivery, voice delivery, you can't do anything about it. Right. However, given this reality, how do we, you know, move forward and how do we optimize that's the challenge. Okay. So the overall theme is this is what I will come back again and again. Three things if you have to take away from this entire talk, like if you forget rest of the 43 minutes, if you want to remember three things, do this. Right. You have to reduce the latency, eliminate number of browser redirects and then collect as much data as possible and then build a very good real time analytics. Right. These three are going to play a huge role in improving your payment conversion rate. Okay. We'll touch upon each of them in the slides. Right. So reduce latency. Before that, let's see why latency is bad. Right. So in. So one obvious drawback you already know is, you know, it has a bad user experience, but it has couple of other subtle by products which are equally bad, if not more. Right. The first one is it impacts your system scalability and throughput drastically. Okay. As the number, as the latency increases, the number of concurrent users that you can handle goes down significantly. Right. And we'll, we'll come back to that in a moment. Second thing is customers are impatient. You know, they don't want to wait around and they, when they click on a payment button, they see nothing is happening. But in the background, you see that something API calls are going on. They would like to, they, they see their impatient and then click on the same button about half a dozen times. You know, why is payment not going through? Why is it not happening? Right. It, it, it introduces a huge problem, which is duplicate submits and trust me handling duplicate submits is, is not fun at all. When you're talking about backend systems, right, you have to, you have to take care of idempotency. You have to take care of synchronization and whole bunch of things. Okay. So this is a typical graph about latency and throughput. So as a, what you would expect is throughput to go linearly down as latency goes down, but that's not the case. It actually follows exponential decay. So as the latency increases, the throughput decreases drastically. Okay. This is how generally systems work. Unfortunately. Right. Okay. Now, given this, what can you do to reduce the latency? What are the things that you can do, right? Prefetch as much data as possible as soon as a customer logs in. Okay. Prefetch all these credit cards, debit card details, all the payment methods and everything. Don't do that at the time payment pages loading. Okay. Because typically customer login happens two to three or four steps ahead of the funnel and maybe a few minutes ahead of it. So by the time customer lines on payment page, you already have all the details. We just have to respond. Right. So yeah, so the for repeat customers, you know, fetch all is all their preferred payment methods, whatever, and then stored card. So one thing about stored card is when I have stored a card and then the issuing bank for that card is down. Show it prominently. Don't ask. Don't allow me to go ahead. Right. One more thing. So don't compute fraud score when at the time of payment. Okay. Because you know everything about the customer, what the product is going to buy right up like much earlier in the funnel than at the payments page. Okay. So just have the fraud score computed pre-computed and then just fetch it. Same for the offer checks, you know, pre-computed and then have it ready at the time of payments. And so this is a general advice about any, any systems not specific to payments. Just minimize. Don't go to databases, you know, cash, everything as possible. We'll touch up on this a little bit later. So the one more thing is a lot of things people don't handle is having a sane and default time out behavior when the API is go wrong. What if offer service goes down or rather what if offer service starts misbehaving? What if it's latency shoots up from a half a millisecond or rather half a second all the way to one minute? Do you want that thread to be hanging around? And then it has a direct impact on latency. Right. So don't do that. Have very default, very good time out and then have good default time out behaviors as well. So have a, you know, default behavior review. If it's a fraud service, then, you know, it's okay to let the customer go, you know, you observe the fraud because you're, you're, maybe it's a, it's a, it may not be a okay decision in some of the cases. But generally turns out to be okay. Again, in terms of if it's offer service, give it an offer. It's okay. You know, you will earn customers goodwill at least. Right. Usually it's not an engineering decision alone. It you have to consult your product managers and the business owners because at the end of the day, they are the ones who are the paying the money. It's a mix of all those things. Right. So browser redirects. Why are they bad? One is each browser redirects introduces a drop. It introduces a latency and then customers will just, they don't want to wait. They just would want to go away somewhere else. Right. And then most importantly, it's dependent on the customer's network connection. Right. Because when a, when a browser is, is being redirected to some other service, it's my bandwidth and then my data that's being consumed. More importantly, it depends on my signal strength. You know, typically on mobile devices, which is not very good. Right. So, and then, of course, introduce this opens up a whole bunch of edge cases in terms of back button. I don't know how many of you have experienced it. If you go to, if you traverse from payment page to net banking page, try pressing back button. You will not be able to get out of it. Never. And yeah, you will end up in some limbo state. And then as a, for an engineering team, it's not fun to handle it in the same manner at all. Right. So before we go ahead, let me digress a little bit. Not exactly the digression, but it's important thing. How many of you have heard about PCI compliance? I've worked on it, done something about it. A few. Okay. Very few, in fact. Okay. DSS stands for, I'll actually let you read it. It's a payment card industry data security standards. Any company that deals with card information that transmits stores or processes card data, they have to be compliant with this, this compliance. Okay. That's what it is about. Why it's important will come talk about it now. So what it enables is if, if, if you become a PCI compliant, it is, it is not a straightforward process, but it's not too painful either. Okay. If you become PCI compliant, what it enables you to do is it, you can start accepting card right on your payment page as opposed to being redirected to some other third party payments page. Right. That eliminates one browser redirect straight away. If you, if you, if you can know, right. And yeah, so it, it improves us, improve the user experience drastically because you can, you can open up numeric form. You can do a bunch of validations and whatnot. As I said, it, it just unlocks a whole bunch of checks that you can do right at the payment page instead of somewhere down the funnel. Right. It's like fraud control. You can do offer checks. You can do checks, something like, you know, this offer can be availed only on this type of card. Maybe this number of times, right? And then you can collect a very good user data, analytics data, like what kind of cards are being used to what, what is their propensity, a hotel customers, what kind of cards they would like to use and so on. It, it has, you can do a lot of good things about it. So I'll cover the last point in a moment. Right. Okay. So we talked about it prefer in line payment page as opposed to browser redirects. And bypass payment gate to aggregator. So in the payment word, there are payment gateways and then payment gateway aggregators. The line is not very fine. In fact, they, they blur into each other there, but they are typically two different entities in India. Usually until very recently only banks were allowed to be payment gateways. Okay. So all the other entities, like now you have things like HDSE payment gateway, ICICI payment gateway, access payment gateway and so on. All the other entities, you know, you have, you have, build as CC Avenue and on, they are actually payment gate to aggregators. Okay. So they are actually two different things. So there is a two browser redirect that happens. So try to bypass payment gate aggregators as much as possible. If you, if you can integrate with payment gateway provider directly, you will eliminate one browser redirect. Right. So while I'll cover the, I'll talk a little bit more detailed about authentication and authorized flow in a moment. Okay. So there is one more solution. Usually payment gateways let you do is, which is they will let you embed their payment page as an iframe in the, in your product page. Okay. It is a good thing. It's a good middle ground, but it has its own downsides. Right. It's a good compromise between you want to go to time to mark like you want to launch your product very, very fast, but you don't want to get into the PCI compliance thing because it's quite a long drawn process. Okay. The second option is of course you will own your payment page yourself. The big advantage as I talked about the big hurdle rather is a required PCI compliance, but it's actually a right long term solution because customers will be able to enter all the details on, on your page as opposed to some other page. Right. Okay. So this is about authentication and authorizes flow. So I'll just walk you through it. Okay. From the browser, though, as soon as customer clicks make payment. So what your server is going to do is it will talk to payment gateway. It will pass all the information, which is like credit card number, CVV, everything amount and payment gateway will respond with a 3D secure URL page, which is two factor authentication URL, which is where you will redirect the user to. Okay. The green lines you see they are the browser redirects. Red lines are all APIs. Okay. So from your, your page, your, your website customer will directly land on second factor authentication page. You have eliminated at least three browser redirects with this flow. Okay. He will complete the, he will enter his second factor authentication be it OTP or whatever it is. And on the response that response you take and then you give it, give that response as it is to the payment gateway and then ask it to authorize. Okay. Is the second factor authentication is it good or not banks will authorize. Okay. So this is fairly advanced, not advanced in the real sense. But for this, you will have to have a very good relationship with the bank and then you have to promise them certain volume of transaction and so on. But if you can pull this off, this is probably the best in class right now in, in, in the current ecosystem if you can pull it off. Right. Because there is just exactly one browser redirect customer will land directly on the payment page, 3d secure page, and then he will come back and then you are done. Okay. Okay. So until this, what we talked about is more or less static things. Right. In the sense that you do certain things once and then you are done, the payment conversion will go up. Right. But there is a whole bunch of factors that actually govern or determine your payment success rate. Unfortunately, which is your bin. We talked about bins. The impact. This is what we actually found out. So there may not be a legitimate reason for this or we don't know, but these actually do impact. There's a payment method. There's a amount range payment gateway fraud rules. And these are dynamic in nature because they actually change on a day to day basis on at some time and in early basis. Right. So yeah, so you have to have a bin based routing, which means that if you integrate with multiple payment gateways, then you know that certain bin ranges have a higher success rate on certain payment gateways. You just will figure it out if you do the analytics. Right. Do set up that bin based routing and then you are to improve success rate. They will. So banks and issuing. So by the way, there are fraud rules. They are typically spread across the entire ecosystem. We talked about payment gateway aggregators payment gateway card networks issuing bank. All of them have their own fraud rules may or may not be compatible, but they do have it. Right. What also happens is that they introduce us. They introduce a new fraud rule without letting anyone know. Right. They just introduce dynamically and then you get hit by it really bad. Okay. The only way to learn a new fraud rule that has been introduced is by doing real time analytics. This is actually real time analytics. Analytics. I'm talking about not some historical analytics because by the time if you try to analyze previous days data, then it's like you already lost the game because you're you're lost all those customers. Right. Yeah. So again, newly added authentication methods couple of years ago, one of the bands dynamically introduced a new second factor authentication in net banking. Right. We got hit really hard because of that. Right. You'll come to know about all these things. If you have real time analytics. Yeah. So this of course you will have added benefit of where the customers are dropping off. And good thing is you can correlate with other data that you gather, you know, for example, some tier to city customers are dropping off more often than not. Then you can correlate with the signal strength. Why what is it happening? Then you can correlate with the carriers and so on. Right. It's a very good information to have. You can you can actually use that to improve our conversion rate. Right. Okay. So we have covered the request handling part. Now it's a return journey. Right. Where you are the second part where customer is waiting. If I were to give just one advice here, which is integrate with callbacks. Okay. Which is all the payment gateways typically what they do is they will they will give you a callback method whenever there is a payment completion. Okay. It's a really good thing because you are not dependent on customers internet connection at all. Right. This will this will even though this won't help you improve the conversion rate because but it will help you improve the reliability. If the if the debit has happened, then you will come to know about it for sure. Right. Then how do you handle the failures? I covered couple of that some of the context. And the final point which is active reconciliation. So reconciliation is the process which happens between all the parties involved at the end of day on a periodic basis. Okay. So for example, if I as a e-commerce company trying to deal with some payment gateway, we exchange files for the payment transactions that happened two days earlier and then we do match up. Okay. So whenever there's a reconciliation happens and then you if there is an entry that shows up as a as a successful transaction, which you have identified it as a failure. Right. Then you will be able to handle it. Give the customer, you know, handle it in a graceful manner. Okay. So let fulfill the transaction or do whatever it is, but do it in a in a graceful manner. Right. So so with these things in mind, I don't know if you can see this, but this is what I would propose as a long term, a decent architecture schematic architecture for a for a payment processor. At the top layer, you have a business logic, the things which, which primarily would involve, you know, it could be offers, it could be order ready information and so on. And then you have reusable components, things like you have routing engine, user profile, downtime alert, fraud rules, PG plugin and so on. And right at the bottom, you have infrastructure components, you have like databases, analytics engine and so on. Let me spend like probably two minutes just to cover give like again high level recommendations. So these, these components are mostly the data that is a like key value in nature, you know, as a frauds rule, fraud score for a customer, you know, or what is the status of this bank, whether is it up or down, right? And then it's mostly read and then rare updates. So I would see, you know, you could use DynamoDB or Redis and then you could actually cash it in memory totally, right? This importance of this is that it has direct impact on the latency. Transactional store, this is like as it compliant, it has to be secure. It is typically 50-50 read write and then it is a really fast growing data store because every day there's going to be hundreds of thousands of transactions and usually once a transaction happens, it becomes a well, it becomes still in the sense that after couple of days, the data is just going to lie there around. You won't touch it very rarely will you touch it. So it's very good to have archival policy in place, right? My sequel is my, my choice, but you could choose any asset compliance database. So real time analytics, what people usually end up doing is you end up doing it on top of MySQL or you know, Mongo and stuff like that. Don't do that. This is the way to look at it is that you have a stream of signals coming in, you know, as the payments are being processed, the credit confirmation, debit card, what type of payment method, signal strength and so on. And then the kind of analysis that happens on this is actually moving window, which is what is the success rate in last 10 minutes? What are the fraud rules introduced in like last five minutes? Has anything changed? Right? So, and then typically you don't want to store the entire stream. You will typically consume only the summary. Right? You would standard solution. I would recommend this is our kinesis or Apaches Tom or Kafka or Apaches Tom Kafka and kinesis are the data pipes and then Apaches Tom is actually your computing engine. Right? You could use even some time series database as well. Okay. So reporting in BI, this is more, this will not have much of an impact on the success rate but more of a good practice to follow. Don't do it on top of your transactional database because that is just not going to scale. Right? Because the transactions and the queries are going to be OLAP in nature. You will want to pull out a whole bunch of historical reports and there is going to be very, very long running queries that would be running on this database. Don't do this. Rather, don't do it on transactional database. Use Redshift or something. Right? Right? So the bulk of the talk is done. I would talk about couple of moonshot ideas which is what you could do, you know, do something like, you know, when you know that it's a high value customer, the customer can be trusted, you know, just extend him the credit, you know, which is what Uber does it already. Right? So this is, again, so you can initiate authentication call much before the payments. So that will reduce your payment latency. This is a new thing in the play, which is issuer trusted third party authentication model where banks, some of the banks, they will be willing to offload the authentication piece to the merchant itself. Merchant could be a flipkart, a free charge, whoever it is, right? Which the beautiful thing about this is that the entire OTP and everything will happen on your page. You will, you can authenticate the customer in whichever way you want. It could be OTP. It could be, you could say, I trust this customer because he has transacted 10 times. I won't even authenticate. You know, that is good enough for me. I'll just let him go ahead. Right? Some of the banks have started doing it. City is the one. And I say, I say, quick check out this again. One more solution, which is you can think of it as a stored credit, stored card service for a net banking. Right? Then again, so how does UPI change over things nowadays? You can't have a payment stock and not talk about UPI, right? So, I mean, my personal opinion is it will not have much of an impact on the success rate at least one or two years down the line. But, but if, if you were to be building for the future, this is what you should be doing because this is what this is to payments what I like to call other to the identity, right? If you think about three years earlier, people were actually laughing at other, like, why would I need this and so on? But government has been pushing it slowly and steadily, you know. Initially, they said that, you know, other is not mandatory for everything. And then they said that suddenly they said, you know, other is mandatory for gas connection. They is that now UPI has been, they said that, you know, they are actually saying that UPI will tie to other, right? All of a sudden, other has become mandatory, right? So, good thing about UPI is that it, it, as I said, you know, there is no browser redirect that like very beautiful, you know, UPI interaction if you have used it, if you are able to pull it off. So, that's about it. I am pretty much done. If you have any questions, I'd like to take that. Thank you, Aaron. Can you have a small round of applause, please? Thank you. We have a few questions. So, we'll start with, yeah. Very good talk. Thank you. Cancel button. I, like you mentioned four or five pages, which a person goes through. And I have like half the time I see a cancel button or not for some reason, when I change my mind, the only thing I have to do is close the tab and giving, given that I'm a person who likes closure that doesn't feel the right thing to do. I know it's bad for business. That seems to be the obvious reason that you don't want to write a cancel reason. But is there any other reason that in the technology that a lot of pages don't write a cancel button for the transaction funnel? No. So, the, it's mostly a business driven decision, as you already talked about. If it were to be built by an engineer, you know, I would like to have a cancel button every time. It's like, you can think of it as actually a browser back button. You know, it cancel everything or just go to the previous page. I said, unfortunately, you know, the things we are dealing with here are, we have a, we have merchant page, which is like Flipkart, free charge, Amazon, whatever. Then you have payment gateway aggregator, payment gateway. All of them are so unbelievably disconnected that it's really horrendous. If you, from merchant's page, if you land on payment gateway page, there at least you can make the back button work. From payment gateway to payment gateway or the head banking page or the 3D secure page, there is no hope in hell that back button is going to work. Unfortunately, that's the state of affairs right now. They don't actually, unfortunately, as I said, they just don't. Because we are talking about some systems that were written like maybe 1985 or something. There's another question here. Here. Can you provide some more information on ITTP that you spoke? Oh, okay. So, so ITTP, as I said, issuer trusted third party. What it actually means is that the issuer here in this case, the issuer here is the entity that is issuing the card. HGSA bank, ICSA bank. Trusted third party means they are actually trusting the third party, which is the merchant page in this case. So they trust merchant to do the authentication on their behalf. Okay. So today, what is happening is both authentication and authorization are done by the same party, which is bank. So here, banks will tell that, you know, okay, flip card or free charge or whatever it whatever it is. It's a big enough merchant. I will trust you. You can do the authentication on my behalf. You can, you are free to use whatever authentication mechanism. I trust you. But the catch there is that I will not take the liability. In case of stolen cards and so on, they will not accept the liability, liability will lie with the merchant, which is the third, the third liability will lie with the third party for that. For you to be able to pull that off, you have to have a very good fraud model. And also, if you, if you think about it, it's a, it's a reputation on the hit on the bank. If, if a few cards get fraudulent cards get used through this route, it's actually customer is going to blame the bank. Right. So they will try the path very carefully. So if you can demonstrate that you have good one of fraud controls in your place. And then they'll actually come and audit your systems. They will, they might even come and audit your code. But if they are happy with that, and if you can pull it off as I said, this is like probably the best experience you can get in this current scenario. No, actually nothing. There's actually nothing. It's, it's only about liability. If we like one thing you have to remember about bank is that only thing they care about is liability. Nothing else. Trust me on this. They don't care about success rate at all. We used to go to all the banks and give them the actual data, you know. So yeah, the, the again, I want him the banks, but we used to tell them, you know, this is how terrible the success rate is. They said, you know, dude, my, I have this many customers, right? 100% out of that point 2% transact online. Out of that point 2% transact on your website. Why should I care about you? Right? That's the situation right now. Unfortunately. So they only care about liability. And then they cook only care about brand value because they don't want people to be putting on Facebook post saying that, you know, I lost my HDFC card and then I got skimmed somewhere. Any other questions? Yeah. I'm actually really impressed with the talk that nice recommendations for you. One recommendation that you did was that one can in case some service or a part of service is taking a lot of time. We can probably time that out and still issue, for example, you said offers and you know, issue that so are there any, you know, cases which you know off or any companies which do that currently or it's just a idea that you are throwing off. So the fraud control was I was actually something that we actually implemented. Okay. So if the fraud service was down, we decided to say that, you know, let's go ahead and trust the guy that, you know, let's go ahead with it. Right? But the offers was something actually more of an idea. We. So if you, at the end of the day, you would know it's a tussle between, you know, product and engineering, someone, someone has to win. Unfortunately. So any other questions? No. Okay. Thank you. That was a nice talk.