Today, we will dive deep, into the world of global payments. And today, I'll share with you how the empowering developers is the key to creating a seamless user experience.I will be sharing insights and lessons from my own journey and including the real world case study that we built in a paid doc. So before we get started, a few words about me. I'm a product manager at a paid doc with over seven years of experience as a product and tech leader in fintech, HR tech, and driving business growth across 69 countries in Europe, APAC, and Africa. I've built impactful b to b and b to b to c products for top financial institutions, major retailers, and a global job platform with over 50 millions monthly active users. So I adapt my leadership style for different countries and the cultures.

I have a leadership experience of four years, and I specialize in API first payment solutions SDK developer tools, creating the unified API for payments, CICD pipelines, and foundational services. So today, we've been talk we will be talking a little bit about attack and payments. So what is the Paydock? Paydock is the payment orchestration platform that built entirely for top tier financial institutions. It's fully white labels, and that enables them to provide them services to their merchants. So this helps businesses to increase the revenue and boost in and, increase efficiency and while they're also reducing the cost of building their own solutions in house. So Paydock recognized as a top tech, by fintech fintech magazine and won the best partnership award. So that's everything good, but, that's what Paydock does and what I do. But let's zoom out for a moment, and let me bring you to a life with a story about own experience buying something online.

I'm sure that everyone here has bought something online at least once. If you did, please pop message in the chat, and I hope that probably for you, the experience looks something like this. You browse the item and then you add the item to the basket. Then once you're ready, you press the one button, and then you proceeded to a checkout. You review the payment options and click just the pay button. Very simple and easy experience. But have you ever wondered how this experience will look like for merchants? So for merchants, it's, enabling payments. It's not that simple as it looks from for the customers. So for merchants, the enabling payments, it starts with the building, the checkout page that will display the region specific the payment method.

It will be card, buy now, pay later wallets, a to a payments, depending on the region of the merchants and their customer preferences in this region. So once they provide the payment details, then they have to securely collect the card information from the customer, and it means usually they have to use their third party components, to ensure the PCI DSS compliance and their high level security. So once the data collected, then the data will be tokenized, and merchant will perform a fraud check to make sure that transaction is not a fraudulent. And then based on the fraud decision, the merchant can choose and the regulation in the specific region, the merchant can choose additionally to perform a three d s check. If the three d s check's successful, then the merchant will initiate payments. And if the, payment is successful, then there will be displayed payment confirmed page to the customer. So if the payment fail, then the merchant will, redirect the customer back to the payment details, the page. But that's the how it looks on the high level.

But there is, more in the the devil is in the details. So the every merchant, the they need to define how the payment journey will look like in the corner cases and in the different scenarios. So, for example, what happens if the fraud provider will return the in review flag, meaning that they cannot stay if there's a fraudulent transaction or not. Shall merchant decline the transaction and potentially lose the revenue? Shall the merchant accept this and potentially there can be fraudulent transaction, so they will also lose? Or the merchants, they should additionally perform a three d s check. That all depends on the specific merchants and depends on their their risk appetite, basically. So and for merchants, as you notice this journey, it's not as smooth as it looks for the customer.

So for merchants, the going live with the payment solution, it can take up to a year. And if you're a big player like a Costco, you can afford to hire engineering dedicated engineering team and build everything in house. But what if you're a charity or mid sized merchant small business? That's just not realistic. Most, they will not have the dedicated engineering teams, and the cost of integration, all of these payment methods, it will be just too high too high. So these merchants, they would need a simple solution that developer friendly. It's just like the customers, they expect the one click checkout. The same merchants, they would need the one line integration so they can enable payments as simple as possible.

So but what if we could make payments as simple for merchants, at least for customer? And that's exactly what we, did as the in a pay dock, as the pay dock checkout solution. So we've done all work basically for merchants, and we've completed the integration of over 100 different PSP wallets, a to a payment, local payment methods, the card scheme, basically. And then paid off checkout will empower the midsize merchants to build the custom flows, but using the low code solution and using basically the UI. So for example, in Australia, there is a local payment scheme, of course, and the merchant would can be able to in just enable it using the UI and not integrate their direct API. So this scheme, it will allow to process the payments cheaper basically in the region.

So for merchants, the journey that will start in the UI, and the firstly, they will choose, like, a toggle on payment matters they want to enable depending on the region and the customer preferences. Then they will choose if they want, they will choose the fraud provider. So they they there is no vendor lock in. They can choose the different payment, the different providers to perform a fraud check. They can choose the different providers also to perform a three d s check. They can use the gateway solutions. They can use the stand alone services, and they can toggle on and toggle off if they want to do it, if they don't want to do it. And, for merchants, it's equally important to allow to style their checkout page so then they can keep the consistent user experience across them, all their websites.

So the checkout page will be styled based on their, design system that the merchant use. And then what merchant would need to do once it's configured here on the UI, then the merchant would need just to integrate one line of code to build in this widget to their website, and that's basically done. So and the best part here is that at any point of time, this configuration can be changed. So merchant can see if this they want to enable a new payment methods. Let's say they can easily do it, and they go to the UI and enable this payment methods. So what results we were able to achieve by introducing the pay dock checkout?

So, basically, pay dock checkout, it changed the way how the financial institutions stay on board their merchant to their platform. So the previously, to enable merchants to go live, it would take up to six months. It would cost you nearly half a million. So with the paid off checkout, you don't need to spend this money on the integration. You can use the one single engineer, and approximately, it it will cost, like, 10,000. So, the result is the 98% of reduction in the cost and 92% in acceleration to in time to market. So they don't need to wait and delay the launch. They can do it in, like, two weeks that the real examples that we the real feedback that, we've heard from the merchants that use the solution, and they enable it to their customers.

So and that's about the solution. But achieving these results, it's like, it's never possible. It's only with the technology. It's, not only about the building the solution. It's also about the learning and the adapting and the leadership. So scaling payments, it requires not just the technical expertise and know how to do it. It's more about the how to unite the people, how to build the culture of collaboration and the continuous improvement. So let's take a closer look on the key lessons learned and the best practices from the building the solution. So the first one is it can sound very obvious, but shift your mindset. Like, developers, when we think about the products we build for developers, we should think about them as the users. The developers, it's not the supports.

The developers, yes, they have a specific skills and expertise. At the same time, we should, enable them as simplest experience as possible. So the great developer experience, it means that developers, they don't they spend less time on the routine task, and they spend all their time on the creative task to understanding their architecture and designing the solution how to, basically enable it in the existing, system that we already have.

So the second, it's, the map, the developer journey. The same like we do for users, the journey. Try to understand, like, how this journey looks like for developers. Where is the key pain points there? Like, what is the repetitive task they're doing? And what what can be automated? What can be improved? And make the solution 10 x better. Make it, like, same as you would make for the customer. So leverage the existing technologies. Don't try to reinvent the wheel. There build stone existing foundations. There are a lot of open source really great technologies and tools that will allow that will provide the components for the solution. It's same as in our, solution. We use the temporal. It's the workflow engine that helped us to build the custom workflows, and it was very easy and, in a secure way as well. So, enhance the load documentation approach.

Like, I was thinking about it. It's like, does our phone comes with the loan manual? Personally, I don't even know because I never use it to send a message to a friend or do something like I want because it's so intuitive, and it's very easy to understand how to use it. And it's same for developers. We should strive to make it as simple as possible so they don't need to read the long manual on how to enable it. They should be able to do it very easy without the long documentation. So the behind the every great product is the team of the talented people. And behind the every team, there is a great leader. And the collaboration is a key. And leadership is the crucial to unite in the diverse team and the to create the exceptional solutions.

I I had the privilege working with the people from a different cultures and the different countries. And what helped me really in my experience is the really good book, The Culture Map. So it highlights how communication styles, they vary from their culture to con culture. Like, there are low context cultures like US. They prefer the direct communication. They value clear goals in the setting. At the same time, like, the cultures like in Japan, they rely more on the nuance, the shared understanding, and and indirect cues. So the key lessons I learned is be flexible and always be respectful. Adapt your leadership style to support your team. At the end of the day, your role is to help everyone succeed, not set up everyone to fail.

I wanted to share a few practical tools that I picked up during my leadership training program that really changed the way how I lead the technical team. The first is listening, and I mean, like, really listening. Listening. In fact, we're always trained to solve problems fast, but with people, we have to slow down. Level three listening is the highest form of listening that allows to, listen behind the words and hear the someone's worries and the hesitation. So I'll give you a real example. I was working on a custom feature for a client, and I needed, like, a rough estimation of an effort from the engineers to start the negotiation and understand, like, the cost of the development. And, like, I asked him, like, provide me an effort, and he came back to me with the number.

Like and I looked at this number, and I said, like, I was thinking it looked too high for the scope of work what we what needs to be done. So and then what I did is I started the conversation using the levels relistening. I didn't question the numbers. I just started, to ask the questions. I paid attention to his tone and what he was saying. And it turned out to be that he was worried that if these estimates can be used as a delivery date and that he will he didn't want to overpromise anything. So and we once we cleared that everything and we aligned, then we were able to reduce the cost, like, twice because we really solved the problem we wanted to solve. So that's how powerful the levels of releasing it can be. And the second is empathy. It's not about being soft. It's more about being human.

When people feel safe and supported, they take initiative, they share ideas, and they innovate more freely. Lead by example. Your team watches how you handle conflicts, how you treat others, and how you show up. So before we can lead others, we should lead ourselves effectively. We must first lead yourself. And self leadership, it truly starts with understanding our ourselves, our strengths, and acknowledging our gaps and making decisions aligned with your core values. Just as we dive deep into understanding the users, the same, we should invest in understanding yourself. Journaling was the key for me. I've been journaling for the five years. I made it a daily habit. And this is a very powerful tool for self self reflection and prose. When you lead with clarity, integrity, and purpose, you set an example for your team. And the people, they don't follow perfection. They follow authenticity.

They look what you do, not what you tell people to do. So before we finish, let me tell you a story. I was waiting for the tube as in London when I started talking to a stranger whom had this calm energy. I asked what he did for work, and he said, like, I spent twenty years as a police investigator. And as we wrap up, he told me something that I've never forgotten. The question is the answer. Learn to ask better questions. At the time, I didn't think how much of, much of it. But over years, especially working in tech and leadership, I've seen how true is this. Asking better questions help you be build better products, understand users more deeply, and also learn about, most learn more about yourself.

Because when we ask better questions, we don't just get better answers, we make better decisions. And the few key, few key points how to ask the better question, and that's basically what we can learn from kids. The first one is the key is ask open ended questions. The keys, they ask, open ended questions because they don't really know the answer. Be curious. Ask what oh, tell me more about it. It's different from asking the closed ended questions, like, that require on the yes or no answer. Like, in an example, is the user feedback positive about our API? We can rephrase it and say how user responding to our API solution to make it more powerful. Avoid leading questions. Sometimes the question is hiding the answer. Like, there aren't major risks with this approach, aren't they?

What instead, we can ask what risk or challenges do you see with this approach to open more space and avoid the leading question. And the last one is exploration is taken. It's more the dive deeper and, try to understand the core reasons. Like, it would blocking us from releasing this feature. We are waiting on API integration, why API why API integration is delayed, and then you can understand the real reasons, and you can solve the real problems. Thank you, everyone. Thank you for your time. I would appreciate you, for sharing your feedback. Please feel free to scan the QR code and connect with me on LinkedIn. So I would appreciate if you have any questions. I'm happy to answer them. Feel free to reach out on LinkedIn, and I'll I'll answer them.