Why Your Payment Gateway Isn't an Orchestration Platform Yet | Nornhill

Transitioning a basic payment gateway into a multi-region orchestration platform requires a layered approach: Unification, Core routing loops, Risk & Compliance, Intelligence, and Self-Service.

Transitioning a basic payment gateway into a multi-region orchestration platform requires a layered approach: Unification, Core routing loops, Risk & Compliance, Intelligence, and Self-Service.

In 2023, the company shifted from B2C to B2B, offering our platform to other clients to test if this business model could last. Three years later, the decision paid off, thanks to a lot of hard work from everyone, especially the Payment team.

For years, clients, management, and the industry saw a Payment Gateway (PG) as just a technical tool. A way to connect merchants to payment providers and move card data. It was seen as a simple pipe that just needed to be big enough to handle peak traffic. But today, PG is a high-volume, multi-region payment system, and calling it a utility no longer fits.

Our PG has been more than just a gateway for a while. It has quietly grown and changed:

  • 130+ integrations and 170+ payment methods.
  • 3.6M unique users across 40+ countries.
  • 18M transactions monthly with nearly 0.04% of chargebacks (yeah, such a low rate because of diverse LPMs, bank transfers, and crypto)
  • 500+ monthly configurations of client brands. Dozens of bespoke merchant configurations per brand, per country, per product.

Indeed, now, PG does more than just move data. PG handles complex operations. Let's look at the strategy that came out of our operational challenges and how it helped us focus, deliver, and grow into a Payment Orchestration Platform.

Product planning | Nornhill
Product planning and prioritization representation

When Product Operations Reached a Breaking Point

It might sound odd, but success brings its own debt. What made me rethink PG strategy wasn't new technology, it was the pain of daily operations. As we grew, our manual workload piled up. Over two years, our operations backlog grew five times. The more clients we brought in, the more our top Product Operations (ProdOps) team got buried in configuration tickets, manual routing, and custom setups.

Related Insight

When 5x Growth Breaks Your Operations Team
Read how we transitioned from manual forms to Configuration-as-Code and self-service dashboards.
Read Article

I realised we were running a complex, maturing system, but still treating it like a simple pipeline. So, the Payments team stopped focusing solely on a Gateway, its features, and occasional fixes and started planning for a Payment Orchestration Platform (POP). Here's how I defined that change, assessed our situation, and created a roadmap to turn our operational pain into product strengths by 2026.

Self-evaluation and Aspiration

You can't plan for a system unless you can describe it clearly. I stopped talking about a list of features and instead defined the POP in clear layers. To explain it, you need to know your product and understand where it is in its development. You also need a clear vision of where you want to go. For me, that meant comparing our Payment Gateway (PG) to a Payment Orchestration Platform (POP).

There are many opinions and discussions about PG and POP. On LinkedIn, you might see posts from people who compare PG and POP or share related content. Other well-known companies also talk about the need to change payment gateways. These resources are a good starting point, but as a payments product manager, it's important to understand the differences yourself.

Most services make Payment Gateways seem less complex than they are and often exaggerate what Orchestration Platforms can do. That's just how marketing and sales work, and sometimes these comparisons get a bit ridiculous.

So, always start with your own situation. Don't overlook the strengths and services your product provides. In payments, few people talk about important topics like reconciliation, how money moves in RTGS, or clearing and settlement. Most articles just cover card payments, processing, and surface-level topics. Stories you can tell your kids to explain what you are doing.

Getting back to the main point. Once I had a clear vision, I described each layer and its services. This approach worked well for me.

  1. Unification: The single technical entry point (APIs and integration adapters).
  2. Core: The brain of orchestration (payment methods, merchant accounts, routing, cascading).
  3. Risk & Compliance: Fraud prevention rules, vaults for sensitive data, tokenisation services, segmentation, and regulatory hooks.
  4. Intelligence: Reconciliation, FX, fees, balances, settlement data, reporting, and even monitoring.
  5. Self-Service: The Merchant Dashboard, no-code builders, and configurations of the payment widget.

After that, management stopped asking if we had certain features and started asking which layer was limiting our scalability.

I did an honest review of our platform, rating each layer as Strong, Basic, or Weak. This wasn't for management (it was mainly for me), and I even underestimated some areas to better explain things to the C-level team. For example, our Unification layer is Strong because we integrate quickly and handle large volumes. But our Self-Service layer is Weak since we depend too much on the ProdOps team to set up routes and settings manually. Many services, like reconciliation and fraud prevention, are at a basic or decent level. The real bottleneck isn't the code (okay, mostly it isn't). It is the delegation.

The Narrative

To address this complexity, I required more than a simple feature list. I needed a clear narrative to guide our team over the next 12 to 24 months. I structured the roadmap around a three-phase progression: Orchestrate, Delegate, Monetise.

The process begins in 2026 with Orchestration. The immediate objective for the payments team is to transition decision logic from static configuration files to a dynamic visual builder. The team is developing engines to manage payment service providers (PSPs) and payment methods across regions, experiment with payment flows and retry strategies, and enable direct user interaction through the payment widget. These capabilities allow acceptance goals to be set without requiring code modifications.

Once these engines are stable, the focus in the second half of the year shifts to Delegation. At this stage, manual configurations are transferred from internal back-office systems to the Merchant Dashboard. The guiding principle is that merchants should have the autonomy to adjust limits or toggle providers independently when it is safe to do so. This approach applies to every aspect that merchants can handle themselves, from simple payment method switching to routing, smart retries, and even chargeback management.

By 2027, this progression positions us to Monetise. With a mature platform established, we can transition client discussions from offering basic "payment processing" to delivering "payment performance", emphasising guaranteed outcomes and revenue recovery.

The 2026 Focus

A strategic narrative remains theoretical until it is translated into actionable work. To bridge the gap between my high-level vision and the operational realities of our teams, I narrowed the H1 2026 focus to three specific Objectives and Key Results (OKRs), each with clearly defined quarterly outcomes.

Payment orchestration gantt | Nornhill
Typical Gantt charts are still actual and very helpful to focus teams on projects and clients on outcomes

We are overhauling the Payment Widget not only to update the user interface, but also to support complex new flows such as Fiat-to-Crypto on-ramps. Concurrently, we are deploying Card Cascading (aka Smart Retries) as a controlled experimental environment to demonstrate that intelligent retries can generate measurable revenue increases. Most importantly, we are systematically migrating high-volume manual tasks from internal queues to the Merchant Dashboard.

Why Definitions Matter

Understanding customer needs is essential, and delivering the right products is our responsibility. However, it is even more important to define what the final product should be in the next 12 to 18 months (not in 3-5 years), rather than getting lost in ongoing feature requests.

Evolving into a Payment Orchestration Platform goes beyond renaming or updating our appearance. This transition reflects a real change in our positioning. Since it includes many services, complex logic, operational processes, and a team of 100, its impact is significant. By addressing weaknesses, we position ourselves as an Orchestration Platform, enabling us to grow from a business unit into a comprehensive business entity with its own merchant base.

At the same time, the company gains a significant asset that provides a unique value proposition and competitive advantage in an industry with limited differentiation among providers.

I chose to share this roadmap transparently with our clients to strengthen our relationship. We are not just promising new features; we are aligning on an evolving operational model. Merchants now see the payment gateway as a sophisticated platform, which supports a higher willingness to pay.

So, the question for product people managing infrastructure is whether they are operating their systems based on historical models and clients requests or actively building for their current and future state.

Canonical URL: https://nornhill.com/insights/payment-orchestration-strategy | LLM Observability Feed: https://nornhill.com/llms.txt