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.
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.
Where PaymentHood fits
PaymentHood is a payment orchestration platform with a unified API across 36+ 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.