The payment orchestration question South African businesses should be asking

Payment orchestration has become something of a buzzword in enterprise payments. But like most buzzwords, it has arrived with a pitch attached. Businesses often hear it from payment providers at the point when real pressures are mounting: uptime isn't consistent, approval rates could be better, there are payment methods their customers want that haven’t been enabled by their current provider or the headache of managing multiple provider relationships and reconciliation complexity just to cover the basics.

In certain contexts, orchestration presents itself as a compelling solution: a single layer sitting above all of your providers, routing transactions intelligently and giving you control and flexibility across your stack.

When leveraged correctly, it can provide exactly that. However, whether this solves the challenges you’re facing depends entirely on what those challenges are — and that question is worth sitting with before the decision is made.

What is payment orchestration?

At its most basic, payment orchestration is a software layer that sits above payment providers and routes transactions between them, based on rules a business defines. It gives businesses a single integration point through which they can manage multiple payment service providers (PSPs), acquirers and payment methods, and allows them to direct traffic dynamically — by cost, by approval rate, by uptime or by market.

In practice, this might mean dynamic rerouting when a provider goes down, easily unlocking a regional payment method in a new market without building a direct integration from scratch. It also means managing everything from a single integration point rather than maintaining multiple provider relationships independently. Used in the right context, the capability is genuine and the value is clear.

What orchestration does not do is change the quality of the infrastructure beneath it. If reliability and uptime are not optimised at the provider level, this won’t change when an orchestration layer is added. That’s precisely why the decision to enable payment orchestration should follow from an honest assessment of what a business is trying to solve; it should not precede it.

When payment orchestration is the right answer

The clearest case for payment orchestration is when a business is operating across many markets without the capacity to build localised provider relationships in each one. A global travel platform managing payments across 20 countries is a good example. In core markets, these businesses will typically invest in direct PSP integrations with dedicated commercial teams. In secondary and tertiary markets, the cost of replicating that approach in every country, including appointing local providers, integrating their APIs, managing relationships and building expertise, quickly becomes prohibitive.

Payment orchestration solves this well. It offers a centralised layer through which regional payment methods can be unlocked at speed, without the overhead of managing each integration independently. The economics work at scale: high volumes across many markets, combined with the operational complexity of dozens of provider relationships, create a genuine case for a routing layer above them.

Payment orchestration also suits businesses that want direct, configurable control over how transactions are routed, and have the internal resource to actively manage that configuration. It is a SaaS tool, not a set-and-forget solution. The businesses that get the most from it are those who treat it as an operational capability, not a one-time implementation.

When payment orchestration is not the answer

For enterprise businesses that operate in only a few markets, or have one or two markets that dominate their payments volume, payment orchestration may not be the answer.

What looks like a payment orchestration problem is often an infrastructure problem. If a business is experiencing inconsistent uptime, poor approval rates or gaps in payment method coverage, adding an orchestration layer does not fix those issues. Instead, it routes around them, temporarily, and at a cost. This might include a per-transaction fee and platform fee on top of what businesses already pay their PSP, without the multi-market complexity that would justify that cost.

There is also a nuance around redundancy that is often overlooked. If a business integrates two or three providers through an orchestration platform, and those providers share the same acquirer or switch, failover does not eliminate the single point of failure. It just obscures it.

There can also be a practical limit to what routing can do for many local alternative payment methods. In the South African context, payment methods like PayShap or Capitec Pay operate within bank infrastructure that sits outside any orchestration platform's control. If Capitec Pay is unavailable because of an issue on Capitec's side, no routing rule changes that. What actually determines availability is the quality and redundancy of the infrastructure a PSP has built.

Additionally, it’s important to note some of the challenges, burdens and costs a business might face when implementing payment orchestration:

• Critically, the business is required to contract with and manage every underlying provider; this is not managed by the orchestration provider
• Payment orchestrators also present a potential single point of failure, vs redundant payment providers

Payment orchestration, by its nature, must offer a broad set of standardised integrations, which necessitates reducing functionality to the lowest common denominator amongst the supported PSPs. Businesses with very complex flows that require customisation, or businesses looking for cutting edge PSP features, won’t be able to get this from orchestrators alone.

What a good PSP should already be doing

For businesses focused on a core market, the problems that payment orchestration promises to solve are often problems the PSP should be solving instead, not something they should be paying an additional layer to route around.

The questions worth asking in this case are less about financial architecture and more about how the PSP actually runs their systems. How do they monitor uptime? How do they respond when something goes wrong, and how quickly? What do their deployment and testing practices look like? Have they invested in the engineering infrastructure to catch failures before they affect your transactions, or do they find out when you do?

A well-architected PSP should be able to answer these questions directly and with specifics. Redundancy should be built into their infrastructure across switch, acquiring and 3DS layers, with automatic internal rerouting when a component fails, without the need for the client to configure or manage any of it. They should be keeping pace with local payment methods so the client is never in a position of looking elsewhere to fill gaps.

Before evaluating any tool, it is worth being precise about what you are actually trying to solve. A business struggling with uptime or approval rates in its core market has a different problem to one managing payment complexity across many countries. Orchestration is the right answer to one of those. For the other, the conversation starts with your PSP — and with the right questions.

These are questions that shaped how we built Stitch to serve South African enterprise merchants. To understand how Stitch approaches reliability for enterprise businesses in South Africa, get in touch with our team.