Payment orchestration is a software layer between your online checkout and your payment providers. It decides which provider handles each transaction, automatically retries a failed payment through another provider, and presents every provider behind one API and one reconciliation view.
Payment orchestration is a software layer that sits between your checkout and your payment providers. Instead of your application talking directly to Paystack, Payfast or Stripe, it talks to the orchestration layer, which decides which provider should handle each transaction, retries through a different one when the first fails, and presents every provider behind a single API and a single reconciliation view.
The short version: a payment gateway moves one transaction to one processor. An orchestration layer decides which processor, handles it failing, and keeps the result consistent across all of them.
Payment orchestration vs. payment gateway
A payment gateway and a payment orchestration layer are not competitors. The orchestration layer sits above your gateways and coordinates them. The difference is what each is responsible for:
| Payment gateway | Payment orchestration | |
|---|---|---|
| Scope | One connection to one processor | Many providers behind one API |
| Routing | None; it is the destination | Chooses a provider per transaction |
| Failover | None; if it is down, you are down | Retries through another provider |
| Reconciliation | One report, in its own format | One normalised ledger across providers |
| Adding a provider | A new integration in your code | A change in a dashboard |
| Best for | One market, one currency, one provider | Multiple providers, markets, or a fallback |
Put plainly: a gateway moves a payment; orchestration decides which gateway moves it and keeps every gateway consistent. You still need gateways; orchestration is how you run more than one without re-integrating each time.
The problem it exists to solve
A single-provider integration looks simple, and for one market with one currency it usually is. The complexity arrives in three predictable waves.
Wave one: you add a second market. Your Nigerian provider does not settle in South African Rand. Your South African provider has no mobile money. Now you have two integrations, two webhook formats, two sets of error codes, and a checkout that has to know which one to call.
Wave two: a provider has a bad day. Every provider does. Without a fallback, their outage is your outage. Every transaction fails for as long as it lasts, and you find out from customers rather than from monitoring.
Wave three: economics. Different providers price differently by card type, by currency, by volume tier. Once you have more than one, routing on cost or on authorisation rate becomes worth real money, but only if the routing decision is somewhere you can change it.
Orchestration is the answer to all three: one integration, many providers, routing rules that live in configuration rather than in your checkout code.
What an orchestration layer actually does
Routing
Every transaction gets a decision: which provider handles it. The inputs are usually currency, country, payment method, amount, and provider health. A rule might be as plain as ZAR goes to Payfast, NGN goes to Paystack, or as involved as route to whichever provider has the higher authorisation rate for this card BIN this hour.
Failover and retries
When a provider declines for a technical reason (a timeout, a 500, a gateway outage), the orchestration layer retries the same payment through another provider rather than returning an error to the customer. The distinction that matters is between a technical failure, which is worth retrying elsewhere, and a hard decline such as insufficient funds, which is not. Retrying a hard decline elsewhere just annoys the customer’s bank.
Idempotency
This is the least glamorous part and the one that costs the most when it is missing. Networks time out. Users double-click. Retry logic fires twice. Without an idempotency key on charge creation, each of those can produce a second real charge on a real card. An orchestration layer assigns and enforces that key so a repeated request returns the original result instead of creating a new payment.
Webhook verification
Every provider signs its callbacks differently. Paystack uses an HMAC SHA512 digest in a header, Payfast uses ITN with a signature plus a source-IP check. Getting any of them wrong means an attacker can forge a “payment succeeded” callback and take goods without paying. Orchestration centralises that verification so it is implemented correctly once, not once per provider by whoever added that provider.
Server-side verification
A related discipline: never mark an order paid because the browser was redirected to your success URL. That redirect is attacker-controllable. The payment is confirmed when your server independently queries the provider and the provider says it was captured.
Reconciliation
Five providers means five settlement reports in five formats. Orchestration normalises transactions into one ledger so finance can answer “what did we take yesterday” without a spreadsheet merge.
When you should not use one
Orchestration is not free. It adds a dependency between you and your money, it is another system to reason about when something breaks, and it can add a small amount of latency.
Skip it if:
- You sell in one country, in one currency, through one provider, and have no concrete plan to change that.
- Your volume is low enough that a provider outage is an inconvenience rather than a material loss.
- Your provider already covers every payment method your customers ask for.
The honest test is whether you would notice the second and third waves above.
If you are already writing a if (currency == "ZAR") branch in your checkout,
you have started building an orchestration layer. The question is only whether
you keep building it yourself.
Build versus buy
Building it is entirely possible. What teams underestimate is that the interesting part, routing, is perhaps a fifth of the work. The rest is idempotency, signature verification per provider, retry classification, health checks, reconciliation, and then maintaining all of it as each provider changes their API.
Buying it makes sense when payments are important to your business but are not your business. Building it makes sense when your routing logic is genuinely unusual, or when payments are the product. If you are mapping out what the whole layer has to do before deciding, payment infrastructure for SaaS breaks it into five jobs and marks where billing stops and payments begin.
Frequently asked questions
What is payment orchestration in simple terms? It is a layer between your checkout and your payment providers that picks a provider for each payment, retries through another if one fails, and shows all of them behind a single API and one report, so you can run several providers without building a separate integration for each.
What is the difference between payment orchestration and a payment gateway? A payment gateway is a single connection to one processor. Payment orchestration sits above your gateways: it routes each transaction to a provider, fails over when one is down, and reconciles them all in one place. You use orchestration to manage several gateways, not instead of them.
Do I need payment orchestration? If you sell in one country, in one currency, through one provider you are happy with, probably not. It earns its place once you add a second provider, need a fallback for outages, or sell across markets and currencies.
Is payment orchestration expensive? It varies. Some platforms charge a per-transaction fee on top of your provider’s fees; others do not. PaymentHood, for example, adds no per-transaction fee. You pay only your chosen provider’s processing fees.
Can I keep my existing payment provider? Yes. Orchestration connects to the providers you already use and lets you add or switch others without changing your checkout code.
Where PaymentHood fits
PaymentHood is a payment orchestration platform with a unified API across 30+ providers, with routing, failover, idempotency, webhook signature verification and server-side confirmation handled for you. For stores on WooCommerce, WHMCS, VirtueMart, Phoca Cart or J2Commerce there are free plugins so the integration is a plugin install rather than a development project, and provider changes happen in a dashboard rather than in your checkout code.
If you want to see which providers are covered in your market, the provider directory lists all of them.