The Payment Expert Podcast

In this episode, Kaivalya Paluskar from Payment IQ discusses innovations in cashier management, including the introduction of Cashier Plus, and how these tools streamline the onboarding and deposit process for operators. Learn how data-driven decisions and AI are shaping the future of payment experiences in iGaming.

Key Topics
  • Cashier management challenges in iGaming
  • Introduction of Cashier Plus by Payment IQ
  • The importance of the final deposit step in user acquisition
  • Reducing development time with Cashier Plus
  • Using data and AI to improve payment experiences
  • The 'No Ticket, No Release' philosophy in product updates
  • Future trends: AI integration and smarter payment solutions

Host: Louis Thompsett
Guest: Kaivalya Paluskar
Producer: Anaya McDonald
Editor: Anaya McDonald

Learn more about the latest payments insights: https://paymentexpert.com



What is The Payment Expert Podcast?

Welcome to The Payment Expert weekly podcast, brought to you by SBC Media. Each week we analyse the news driving the global payments industry forward; the innovation, the infrastructure, and everything that has to happen to make it all possible.

Louis (00:00.94)
Hello and welcome back to the Payment Expert Podcast, your source for the latest news, insights, and analysis on the payments industry. I'm Lewis Thompson, down with a mild case of coal today, so apologies, audience, if if you hear a few sniffles. I'm the news editor here at Payment Expert, and today I'm joined by KP, head of product at Payment IQ. Thank you very much, KP, for joining us today.

KP (00:19.249)
I'm Kim Xbook and today I'm joined by KP and

KP (00:30.449)
Likewise, very thank you for having me. and I'm looking forward to have a a good discussion.

Louis (00:39.938)
Well, we're we're very much delighted to have you indeed. And we're gonna start off by talking about the sign-up process and the cost of that, the player acquisition costs in iGaming. Obviously at every single stage of that, sign up that acquisition, it does cost money. but it's the cashier in particular, isn't it? The the last screen, I suppose, before a player deposits.

that's the most expensive place to actually lose a customer. Can you explain to us why that is?

KP (01:15.011)
Absolutely. basically if you look at it from a race perspective, it's it's the final leg. If you do not cross that finish line, you have not completed the race. so it's it's it's and and that final race is quite important. So at the cashier basically is the only screen where you have paid for everything else and got nothing back yet. so you pay for ad, you pay for bringing traffic to your website.

you run the marketing campaigns, you do a lot of product activities to basically make sure that you get those players onto your website. But nothing is concrete unless you get the to get them to a deposit to play. And that's where this is the I think most crucial part in the user journey.

Louis (02:06.061)
Sure. So if we imagine a a hypothetical scenario then where a player reaches the deposit page and then leaves, what specifically has an operator already paid to get the customer that far to to that stage? and what do they get back for it? if anything?

KP (02:11.034)
Mm-hmm.

KP (02:27.728)
Absolutely. Almost everything has been paid if you if I consider from that from a perspective of operators. You have paid for acquisition, which is can be via affiliates that you are bringing traffic from. You are you have paid for onboarding. So think about registration of email, registration process that you have. You have paid for verification, let's say for first-time depositors you have KYC in place.

So all these services will cost you. if you are running a bonus or a campaign with the partner, you have already paid for it. You have platform costs, which are usually intangible, but those are also paid for. And exactly like you mentioned, what comes back is nothing because there is no deposit in in the cashier yet.

Louis (03:22.167)
Hm, sure. and I suppose before that phase as well, if an internal payments team wanted to go and and change the cashier, I suppose they would have had to go and ask certain developers, then then wait for those developers to to complete that work. And obviously there are wait times involved in that as well. obviously that wait, d can you give us an insight into how long that that could be and also the cost of that wait for for an operator as well.

KP (03:27.012)
Mm-hmm.

KP (03:53.283)
It's it's quite an interesting topic actually, one close to my heart. because usually when you change something in the cashier, and and there is a cost associated with kind of yeah, in my previous question I parked under a platform cost where you know change something. payments team usually do not have a dedicated development team just to change the cashier. It is a part of a bigger team if you are managing cashier on your side.

so any change that you will do related with cachier when you are using in built in house cachier, it will require your dev team first of all to do an estimation, which can be depending on complexity, can be few weeks to few months.

But also you need to do a prioritization. You need to find a place. You need to convince them that this is the most important thing for the business. So that this is a two way challenge that a payments team faces usually to manage the in house cashier.

Louis (04:55.956)
Sure, and I I suppose when when working with operators and sitting down and having discussions with them before building anything that could service them, w were the particular things that have come up that you found i in certain conversations that I suppose would help them on that that acquisition journey for for the customers that they on board?

KP (05:18.344)
yes, so so this is where I think the we we kind of came up with a cachier plus, which is you know, when we interviewed fifteen plus different operators, and we realized these are the pain points we can we can we can take away and then solve them by by providing easier solution to manage the cachier. So easier solution to change anything that is inside cachier, be it a logo, bit font or maybe a journey sometimes.

where you want to have a payment method selection first and amount later, or maybe a bonus first. so this is what is a primary what what led to kind of introduction of cashier plus.

Louis (06:03.33)
Yeah, sure. And I suppose it helped as well solve other issues. I know, you know, operators perhaps have have issues with player conversion, certain players dropping off, internal teams get getting slowed down, as we mentioned earlier, with any new cashier change decisions that they have to make. from your end, are they kind of separate pro problems or are they sort of one problem showing up in three ways? And and how do you help solve for that?

KP (06:11.46)
Mm-hmm.

KP (06:31.6)
I think it's one problem, but it's a combination of it's it's it's kind of a loop, not a list rather. The conversion dropping off and you know, team slowing down. because yeah, b currently the cashier is operating as a black box. You know, what happens inside you are kind of unaware of. So you do not know what is the you you you understand there is a problem, but you cannot find out the nitty-gritty details of it.

So you try something out for conversion. then the dropping off, you observe, you try to change something, and then it slows down team because they cannot fundamentally find out what was the the actual, let's say, problem and what we're trying to fix. It's all based on I would say a gut feeling, not a data back decision.

Louis (07:24.216)
Sure. so is is there one thing within those problems? Or, you know, I'd said three, but y you've kindly corrected and said it's one problem in i in three ways. Is there anything within that kind of experimentational phase, as it were, that that helped you kind of directly change how you built Cash Air Plus within that kind of you know, development phase of things? Were there any things that you thought, hey, this could be great for it? But then in the end

KP (07:29.274)
Mm-hmm.

Louis (07:54.562)
decided on on on another route for development.

KP (07:58.735)
Yeah, so the the the way I looked at it from when when coming up with solution is why, what and how, you know, so so why there is a problem and for that kind of I realized when having a conversation, like I mentioned it was a more of a black box. So why certain things are failing or let's say credit card journey is not so good as a crypto journey in within the payment completion, for example. So that why becomes quite important and then you have

the what as a problem, like what is it that I need to change? And then how will I exactly like you mentioned, how will I prove that it works, you know, via experimentation. So that's where I would say the thought process was.

Louis (08:43.7)
Mm. And I suppose on on the other side of that coin, on the flip side, were there anything was there anything that perhaps certain operators asked for or suggested that that you you looked at and then decided, actually this is probably not a good idea to build this this feature in.

KP (08:47.248)
Mm-hmm.

KP (09:03.088)
quite interesting.

I can yeah, I can think of like at least for now I do not have that in in in inside embedded where they wanted us to take a decision on certain things based on our data points. and I wanted to kind of empower them to make the decisions themselves. So they are this is where I would say I changed my mind. so

Maybe to give you an example, like a preset amount, right? Whether it should be a slider or it's it's a boxes, what it should be, can you make a decision for us? I said, yeah, I can make a decision, but why not I give you power to change that quickly? So that's how I looked at it.

Louis (09:58.777)
Hm, yeah, interesting. Obviously there's the tools to achieve a decision, but obviously, I guess keeping that that choice, that final decision with an operator was an important part of what you guys were w were trying to relay there.

Absolutely. so let's go into the product a a bit more. There are three parts if I'm not mistaken. You've got your the builder, the preview and the data segment. I suppose in a in a simple way. What does each area of of the product let a payment person do at their desk, perhaps that that they couldn't do last year? How does it empower them and I suppose how does it kind of help streamline the

KP (10:20.058)
Mm-hmm.

KP (10:24.474)
Mm-hmm.

KP (10:41.829)
Yeah.

Louis (10:45.9)
the things they're doing and maybe they can then go and work on more value added opportunities within their within their organisation.

KP (10:54.896)
yeah, absolutely. so so I think builder is something which is quite unique compared with other let's say available tools in the market, I would say. so the way it works is we have server side rules, but the fundamental challenge there is you cannot simulate the production. So we introduce something called as player personas, which you can define

So the builder part allows you to build different experiences that you might want to have for different markets, different types of players like VIP, FTD. So Builder is quite a flexible tool that which was not available in the past for payments team. So this is a tool for payments team basically, which you do not need do not need to be technical, do not need to be tech savvy. So so builder is a tool that a payments team uses to build different types of experiences.

But the next part, which is a preview, is I built it, but I'm still not comfortable because you know I do not know what the player will see. So that is where the preview part comes in, where we evalu on basically we allow you to mock a production where a player persona and the payment method rules are rendered on a runtime and you see what a player sees. So

You can simulate an experience easily for a VIP. What is an experience for a F T D. You can preview it. So you see what your player sees, which is quite also unique. And this is was the pain point was mentioned by a lot of payments team as well. And and and

Louis (12:38.125)
Yeah, I suppose it's it's knowing the the UX before the UX becomes available. Yeah, yeah.

KP (12:42.562)
Before launching it, yeah. Exactly, exactly. So it's it's it's UX is absolutely in front of your eyes, the cashier renders itself and you see just by changing the player persona, what are the different choices that they have? Maybe related with bonus, maybe related with amount, maybe related with payment method. And the last piece is the data piece, which is the the black box kind of terminology that I used before. We open that by showing you

Whatever happens inside the cashier. So we have a leak diagram where I say most likely your cost of acquisition is going down. When all players who are opening your cashier for me are genuinely interested in buying your services. So anything after that is impacting your acquisition cost. And and and this is where the data comes in. The second is also we have

A lot of different features like even recording a session for specific types of failures. Of course, not with the sensitive data. We mask all the input fields, but you see how the user was clicking inside the cacher, how were they navigating? Was there a behavioral issue? Where did they hesitate? Where did they got frustration about? And you can change the messaging, you can change the ordering based on that frustration or the hesitation that your player behavior has.

So that's a data piece.

Louis (14:11.352)
Hmm, in interesting stuff. I want to pick up a a bit more on on on the preview that you mentioned, 'cause obviously you you you can test the cashier on, you know, fake VIP, fake first timer, whoever before anyone sees it. Has that kind of enabled in certain feedback that you might have seen certain operators maybe catching something that that they would only have found out previously had it, you know, already gone live and had to sort of post correct that that that launch.

KP (14:15.726)
Yeah, sure.

KP (14:23.066)
Mm-hmm.

KP (14:31.834)
Yeah.

KP (14:40.216)
Absolutely. Actually the last week we had we had an incident on that and that's why it's kind of fresh for fresh fresh in my mind. So I'll give an example where an operator could not find out the the challenge in F T Ds with a three D secure. Okay. So they're they're they their deposits were failing for F T Ds, but they could not figure out why. So only in when when you have a recording functionality available you can find out now.

Why the FTDs are failing only for my 3D secure mark, let's say 3D secure transactions in a certain market. Now you have that data. Now you have that possibility. Before this, it was only that my transactions are failing. Or some even for this operator, they did not even notice that these were failing. So this is what I would say, which was not possible today, and with this new.

functionalities and features it is possible.

Louis (15:41.783)
Mm, absolutely. And and you mentioned obviously with with the builder part, that that helps the payment scene particularly, and I suppose it helps how they run perhaps th their team day to day. Is there any example that that you've heard of where, you know, th they've had that kind of value added time given back to them to focus on other things? What's it enabled them to do?

KP (16:06.52)
Yes, it's it's it's absolutely mind blowing for me that how much experimentation that iGaming industry does in in in especially around cashier, they they change their cashier journeys or running of the campaigns on a regular basis. So one of the frustration was how quickly I can change stuff. Okay. If the operator is seeing that the provider is down, can they put a message?

on on cachier immediately. And all of these little changes that needed a a technical team or technology dependency. And we wanted to remove and give as much flexibility to payments team to change this. And this is where the cashier builder comes in where without a a a technology team dependency, you can do all these changes to your cashier and just with a click of a button put that changes in production.

Louis (17:04.194)
Hm, interesting stuff. you've got a line I I believe at Payment IQ if if I'm not mistaken called No Ticket, No Release, No Discussion. so f from your end, tell us a bit about that line, where it came from and where do developers still have to get involved I it within a certain to a certain degree.

KP (17:26.858)
yeah, I would say before that line I would say yes, that they they would need to get involved in certain degree in initially setting up the cashier. But that's for me more or less a one-time effort where you involve your development team to get things set up or or integrate into, I would say. and once that is done, this is where that line comes in, where you have basically no ticket.

no release needed and no discussion needed because this was exactly the journey mentioned by one of the operators first i need to create a ticket then i need to wait for that ticket to be prioritized then it's deployed and after that there is a discussion on how the things are going so now with this cacher plus builder you can make the changes with yourself so no ticket no release you don't need to wait you can just click the button

And no discussion is basically you have data. Now it's not on the gut feeling. So you can prove based on data either I was wrong or I was right. So that's where this line comes from. Quite punchy one I would say. Yeah.

Louis (18:41.79)
Yes, punchy indeed. brilliant stuff, KP. I mean, so lastly, then obviously no one likes to, I suppose, rest on the laurel. So I mean, looking ahead into how further you can support operators in the next maybe twelve, twelve months, eighteen months. what are some of the things that you and and payment IQ are looking at to kind of push the push the needle even further for your for your clients?

KP (19:09.696)
yeah, I think few we have few things in mind where we can I think now start using utilizing exactly like I said, the data back decision making, but also utilize some of the AI capabilities into Cachier. How can I be more smarter in providing the user experience customizable one? So just to give an example, how can I introduce AI to s change the

the the preset values on a user specific level on an average let's say if you have done last three deposits or which which which is averaging around 60, then it makes sense for me to show you the preset amounts which are similar or more or less around 60. Or how can I use AI to change even dynamically the payment method display depending on the market, depending on the timing

So this is one of the thing like I said to you initially I said no to it, but now realizing that how important it is for me to also bring that into my roadmap.

Louis (20:18.622)
Absolutely. interesting stuff, KP, and and look forward to everything in the future as it gets developed. Unfortunately that that is all we have time for today, but thank you very much to KP for joining me. If you're not already subscribed to the Payment Expert Podcast and you've been watching, please do make sure to subscribe wherever you do get your podcasts with plenty more insight and analysis coming up over the weeks and months ahead.

And for the latest news as it happens, you can head over to paymentexpert.com. We'll see you next time.

KP (20:51.504)
Thank you, Louise.