By Maryna Rybalko and Viktor Bondarenko.
The article explores how Maryna Rybalko and Viktor Bondarenko applied Design Thinking and Workflow Engine to reimagine checkout, turning months-long payment integrations into a no-code, self-serve experience. The result: faster merchant onboarding, global scalability, and reduced development costs.
Maryna Rybalko is a Product and Tech Leader with 7+ years of experience driving transformative growth in FinTech and HRTech across 69 countries in EU, APAC, and Africa.
Viktor Bondarenko is the Enterprise Architect at Paydock, bringing over 13 years of engineering‑driven experience in designing and developing complex payment solutions.
What No One Tells You About Accepting Payments
Imagine an e-commerce merchant, ready to take their business online. They’ve built something great – a product people want, a brand they trust, and a growing audience ready to buy. They’ve validated demand, fine-tuned their offering, and now it’s time to take the next step: accepting payments and scaling the business.
But for many merchants, this step is more complicated than expected. What should be a seamless process often results in setting up an engineering team, dealing with multiple integrations, and building custom payment flows from scratch. What should take a few weeks can stretch into months, delaying launch and adding unnecessary complexity.
As businesses grow and expand into new markets, the need to support additional payment methods naturally arises. But with that comes increased technical complexity. Without the right tools, this can slow teams down. That’s why solving for flexibility and speed at the integration level becomes key to unlocking scalable growth.
At Paydock, we believe it’s time for a change. We’re driven by a culture of innovation and curiosity – a belief that the best ideas are still ahead of us, and the real breakthroughs come from asking better questions.
So, we asked ourselves: What if enabling payments could be as simple as flipping a switch? That’s why we went on a journey to reimagine the checkout experience. We envisioned checkout, where merchants can configure advanced payment flows in just three hours with a few lines of code. By simplifying the integration process, we aimed to make advanced payment technology more accessible, cost-effective, and scalable for businesses of all sizes.
Enabling Payments: A Merchant’s Journey
At a glance, the checkout looks simple. The customer selects an item, enters their payment details, fills out shipping info, and clicks “Pay.” But behind the scenes, for merchants, it’s far more complicated. To understand this journey, we applied the Jobs to Be Done (JTBD) framework, focusing not just on what merchants do but on what they aim to achieve at each step. Here’s how those jobs break down:
- Offer the Right Payment Methods
The journey starts with figuring out which payment methods customers expect – credit cards, Apple Pay, Klarna, PayPal, local wallets, and more. But offering them isn’t just a settings toggle. Each one comes with its own APIs, integration flows, and validation rules. Adding PayPal is different from integrating an acquiring connection or a BNPL provider. The more options merchants want to offer, the more complex it becomes. - Collect Payment Details Securely
Once the methods are selected, merchants need to collect customer payment information securely and in line with PCI DSS standards. That typically means relying on tokenisation and secure, pre-built card entry forms from third-party providers. Building a PCI-compliant system from scratch is possible—but it’s costly, time-consuming, and requires rigorous certification. - Preventing Fraud
Fraud is a major concern for every merchant. They need to ensure that each transaction is legitimate, without adding too much friction for customers, as that can hurt conversion and lead to lost sales. Most merchants end up integrating with a fraud provider or API to run checks before processing the payment. - Customer Authentication
In Europe, SCA (Strong Customer Authentication) is mandatory for card payments. This means merchants must integrate with a 3DS provider to perform 3DS checks. While 3DS does a great job at stopping fraud, it also means more steps for customers at checkout, which can hurt conversion rates. To make things smoother, merchants can use different SCA exemptions, like for low-value purchases, trusted beneficiaries, etc. Each exemption has its place and helps reduce friction, though merchants do take on the risk if there’s fraud. There’s also the option to send returning customers through a frictionless 3DS flow, which keeps things easy for them and still offers liability protection. Of course, figuring out when and how to adjust 3DS flow adds another layer of complexity, with more logic, coding, and integration to manage. - Workflow Mapping
And the cherry on top is workflow mapping. This is an exercise every merchant has to go through. They need to define what the customer payment journey should look like across different scenarios. For example, if a fraud provider can’t determine whether a transaction is legitimate and flags it for manual review, what should happen next? Should the merchant decline the payment, trigger a 3DS check, or go ahead and process it? That’s just one case – there are dozens of similar cases merchants need to handle.

Through our discovery, it became clear that the real challenge wasn’t just integrating payment methods; it was managing the overhead of connecting fraud detection, 3DS, PCI compliance, and custom workflows. The goal became simple: make advanced payment flows configurable in just three hours with a few lines of code. No endless documentation. No scattered APIs. Just seamless, fast integration. This became our benchmark for reimagining checkout.
The Solution: Building the Component
Understanding that our future payment flows would span dozens of steps, branches, and third-party touch-points, we set out to design an architecture that could orchestrate those paths at scale while preserving fault-tolerant consistency across every transaction. A workflow engine became the natural centrepiece of that design.
We began by evaluating existing workflow engines, such as BPMN-based solutions, to find a platform that met our strict requirements. BPMN tools delivered invaluable process visualisation for business analysis, monitoring, audits, and rapid prototyping, yet their loose integration with our codebase and API contracts soon caused friction.
After building an initial prototype on top of a BPMN workflow engine, it made those limits clear. Graphical data-mapping without strong types proved error-prone, the engine demanded substantial infrastructure, and each test run had to execute an entire payment chain, slowing iteration. The approach simply could not scale to our needs.
We knew we needed a robust backend system to support this streamlined UI-based configuration. After evaluating multiple technologies, we decided to build our universal payment orchestration solution on top of a code-centric workflow engine. Bringing workflows into the codebase gave us strong typing, native contract support, lightweight infrastructure, and fast, granular tests.
This approach empowered us to quickly develop a “ready-to-use” solution, which we could then test with merchants to validate the feasibility of our vision.
Anchoring Checkout on this engine now delivers built-in fault tolerance and real-time transparency, empowering our team to iterate confidently while giving merchants clear, end-to-end visibility into every transaction.
Paydock Checkout Solution:

The Results
Paydock Checkout revolutionised merchant onboarding. Previously, enabling a merchant to go live with customised payment flows took up to 6 months, requiring a full development team. With 4 developers working 40 hours/week at an average $125/hour, the development cost per engineer would be $120,000, totalling $480,000, excluding QA and PM. With Paydock Checkout, merchants can now achieve the same results in less than 2 weeks with a single engineer, costing approximately $10,000. This results in a 98% cost reduction and a significant acceleration in speed to market.
With Paydock Checkout, merchants can now easily adapt their payment flows to meet the needs of different regions and markets. For example, if they operate in a region with Strong Customer Authentication (SCA) requirements, they can configure their payment flow to include 3DS authentication with just a few clicks. Merchants can also enable local payment methods tailored to each region, allowing for a seamless, localised checkout experience. This flexibility not only speeds up the go-live process but also enables merchants to quickly test different payment methods and optimise their payment experience globally.
How Other Teams Can Implement the Same Solution
Design Thinking has transformed how companies like Airbnb, Uber Eats, and IBM design for their users. It’s not just a buzzword – it’s a powerful approach that helps uncover what people really need and build smarter, more effective solutions. What if we applied the same thinking to payments? Let us show you how we did it.
Design Thinking follows five phases – Empathise, Define, Ideate, Prototype, and Test –and at its core, it starts with empathy: deeply understanding the user’s experience. In this case, the user is the merchant trying to enable payments on their site.

Step 1: Empathise
The Empathise phase is all about understanding the user’s experience deeply – putting yourself in their shoes to identify their pain points, needs, and motivations.
In this stage, we focused on understanding the challenges merchants face in the complex payment ecosystem, from offering the right payment methods to handling fraud checks and ensuring compliance. To guide our efforts, we used the Jobs to Be Done (JTBD) framework, which helped us focus on not just what merchants do, but what they are ultimately trying to achieve at each step of the payment journey. While you might choose a different framework or approach for empathy, the core of the Empathise phase remains the same: truly understanding the user’s perspective in order to build a solution that meets their needs effectively and efficiently.
Step 2: Define
The Define phase is about translating insights from the Empathise stage into a clear, actionable problem statement.
We realised that the core challenge wasn’t just integrating payments – it was managing the complexity of various systems, compliance, and workflow. So, we defined our challenge simply: make advanced payment flows configurable in three hours with just a few lines of code. This became our benchmark for reimagining the checkout experience and guiding our solution moving forward.
Step 3: Ideate
The Ideate phase is all about generating and exploring a wide range of ideas to solve the challenge at hand. The goal is to think creatively and come up with innovative solutions that will meet the users’ needs effectively.
In this phase, we focused on developing a user-friendly, UI-based solution that empowers merchants to configure and customise their payment workflows with minimal technical effort. With Paydock Checkout, merchants could design their ideal payment process using high-level building blocks, without writing a single line of code. For instance, if a merchant wants to integrate a fraud check into their payment flow, they simply need to connect their fraud service via the Dashboard, select the payment flow that includes the fraud check, and they’re done. It’s a fully managed, no-code configuration that puts the power back in the hands of the merchants.
Step 4: Prototype
The Prototype phase is where ideas take shape. The goal is to create a tangible, testable version of the solution that helps validate assumptions, uncover potential problems early, and provide insight into what works and what doesn’t.
In this phase, we focus on building a working model of the concept to test its feasibility, gather feedback, and refine it further.
Prototyping gave us the opportunity to test the solution early, uncovering limitations and preventing unnecessary resource investments. For instance, when we initially tested a payment orchestration solution using a BPMN-based workflow engine, we identified key issues during the prototype stage. This allowed us to quickly replace it with a code-centric workflow engine without significant investments, ultimately saving both time and resources.
Step 5. Test
The Test phase is where we refine our solution based on real-world feedback. The goal is to validate the effectiveness of the prototype, ensuring it meets user needs and performs as expected in real environments.
During this phase, we gather insights from actual users, identify any remaining issues, and make necessary adjustments before full-scale implementation.
Based on user feedback, we added more customisation options to better tailor the solution to specific merchant use cases. This allowed us to enhance the flexibility of the payment flows and ensure they could adapt to the unique needs of different businesses.
Design Thinking helped us create a user-focused payment orchestration solution. By understanding merchant pain points, defining a clear problem, and testing ideas through prototyping and user feedback, we developed a flexible, no-code solution that simplifies payment workflows and enables merchants to easily scale and adapt to market needs.
Conclusion
We’ll wrap the article with a story….
A while back, whilst waiting at a tube station in London and I started a small talk with a stranger. He had a calm, positive energy, and something about him made me curious. I asked what he did for a living. Turns out, he’d spent 20 years working as an investigator for the police. As we were wrapping up, he said something that stuck with me ever since: “The question is the answer. Learn to ask better questions.”
At the time, I thought it was just a clever line. But the more product work I’ve done, the more I’ve realised how deeply true it is. Asking better questions isn’t just a nice-to-have – it’s foundational. The quality of the questions we ask shapes the direction we go, the problems we choose to solve, and how well we understand the people we’re building for. If you ask shallow questions, you get shallow answers and you risk building solutions that look great on the surface but don’t actually help anyone.
So, if there’s one piece of advice we would give to other teams looking to improve checkout (or any product experience), it’s this – start by improving your questions:
Dig deeper.
Don’t just ask what users want, ask why it matters to them.
Don’t just ask how to build faster, ask what’s slowing them down.
That’s where real insight lives and where real innovation begins.
As for us, we’re continuing to evolve Paydock Checkout by giving merchants even more control – more customisation options, more flexibility to adapt workflows to local needs, user behaviours, and regulations. But at every step, we’re staying grounded in that same mindset: listen closely, ask better, and keep solving for what truly matters.