Payment orchestration is a layer that sits between your checkout and your payment providers. It picks which provider gets each transaction, sends it, reads the answer, and retries somewhere else when the answer is a decline. You keep one integration instead of five, and you change routing rules without shipping code.
That is the short answer. The rest of this guide covers how the layer actually works, what breaks once it is live, and how to tell whether you need one at all.
What is payment orchestration?
Payment orchestration is the practice of running several payment providers behind a single integration, with rules that decide where each payment goes.
Take the word apart and it gets simpler. An orchestra has many players. Nobody asks the violins to also play the drums. Someone up front decides who plays when. Orchestration does the same job for payment providers: many of them, one place that decides.
Without it, every provider is a separate project. Each has its own API, its own way of signing requests, its own error codes, and its own idea of what a “declined” payment means. Add a fifth provider and you have five sets of quirks living in your checkout code.
Here is how different those quirks get. In our own platform we run five acquirers, and no two of them sign a request the same way:
| Provider | How requests are signed |
|---|---|
| UPC | RSA SHA-512 |
| OschadBank | HMAC-SHA1 |
| PayLink | HMAC-SHA1 |
| LiqPay | SHA1, Base64 |
| Hutko | SHA1 |
Five providers, four signing schemes. None of that is exotic. It is just the normal cost of talking to banks. The orchestration layer absorbs it, so your checkout sends one request shape and never learns any of these.
What is a payment orchestration platform?
A payment orchestration platform is the product that gives you that layer without building it. It ships the provider connections, the routing engine, and the reporting on top.
Three parts do the work:
- Connectors. One per provider. Each translates your request into that provider’s dialect and translates the answer back.
- A routing engine. Rules plus live signals. It answers one question per payment: who should get this one?
- A shared data model. One payment record, one status vocabulary, one report, no matter which provider handled the money.
Here is what “one status vocabulary” buys you, in one example. OschadBank answers with fifteen result codes. Most mean a decline, but three of them do not: code 5 is the issuer’s 3DS response, code 10 is an OTP check, code 11 asks the customer to confirm a random amount. All three mean “wait”, not “no”.
Get that wrong and you fail a payment that was still alive. Every provider has its own version of this list, and somebody has to keep all five straight. That is what the shared model is for.
The third part sounds boring and matters most. When each provider reports in its own words, nobody can answer “what is our approval rate this week” without a spreadsheet and an argument. A shared model makes that question a query.
We go deeper into the parts and what a buyer should demand from each in payment orchestration software: what it must do. The internal plumbing of the layer itself is covered in what is a payment orchestration layer.
How it works, step by step
Rules on a slide look tidy. Real routing is a pipeline, and every stage can drop a candidate. Here is the order our own engine runs, stage by stage.
Stage 1. Load the rules. Rules are scoped to one legal entity and can be time-bound. A rule that only applies on weekends simply is not in the set on a Tuesday.
Stage 2. Check for a block. A BLOCK rule stops the payment before any provider is picked. This is how you stop a card range, a country, or an amount band without touching code.
Stage 3. Apply the route. A ROUTE rule names a pool of providers. That pool becomes the candidate list. Only one ROUTE rule can match, which is enforced when rules are saved, not when a payment runs. Overlapping rules are a config bug, and the right time to catch a config bug is at config time.
Stage 4. Fall back to the default pool. No ROUTE rule matched? Then every provider account on the entity is a candidate.
Stage 5. Filter by capability and environment. Sandbox accounts drop out of live traffic. Then capability filtering removes providers that cannot physically handle this payment.
This stage hides a trap worth spelling out. Our catalogue lists Click to Pay as a supported method on all five acquirers. In practice only two of them, Hutko and OschadBank, accept a wallet cryptogram directly on our own checkout. The other three support the wallet on their own hosted page instead. Same word in the catalogue, two different integrations behind it.
If routing trusted the catalogue, it would send a wallet payment to a provider that cannot take it, and the customer would see a failure that no dashboard explains. So the capability check reads a separate, narrower source of truth. When you evaluate a platform, ask which one its routing reads. “Supported” in a marketing table and “supported” in the code path are not always the same word.
Stage 6. Filter by health, then sort by cost. Health is a score from 0 to 100, recalculated over a rolling window. Our formula is deliberately simple:
- 70% of the score comes from the success rate of recent requests
- 30% comes from response time. Under one second scores full marks. Ten seconds scores zero.
- a provider with no recent traffic gets a neutral 50, not a zero
Anything below 40 drops out. What is left gets sorted by cost, cheapest first. The cheapest becomes primary, the second cheapest becomes the fallback.
One more rule matters more than the other five. If every candidate scores below the threshold, the health filter is dropped and all candidates come back. A degraded provider beats no provider. A platform that fails a payment because nothing looked healthy has chosen purity over your revenue.
One payment through the pipeline
Abstract stages are easy to nod along to. Here is a single payment walking through them.
A customer in Poland pays 40 euro with a Visa credit card. The merchant has four provider accounts live.
- Rules load. Two rules exist for this merchant. One is weekday-only and does not apply today. One remains.
- Block check. The surviving rule blocks payments over 5,000 euro. This one is 40 euro, so it passes.
- Route check. No route rule names a pool for Poland. Nothing narrows yet.
- Default pool. All four accounts become candidates.
- Capability and environment. One of the four is a sandbox account and drops. Three remain. The customer paid with a plain card, so no wallet filtering applies.
- Health and cost. One provider has been timing out for the last half hour. Its success rate has dragged the score to 31, below the threshold of 40, so it drops. Two are left. Their cost for a foreign credit card at this amount is calculated, and the cheaper one wins.
Four candidates became one primary and one fallback, in six steps, in a few milliseconds. Nothing here is clever. It is bookkeeping done consistently, which is exactly what humans do badly and code does well.
Now change one thing. Make all three remaining providers unhealthy. Stage 6 gives up on filtering and hands all three to the cost sort. The payment still goes out. That single behaviour is worth more to your revenue than any routing rule you will ever write.
Who uses payment orchestration?
Merchants who have outgrown one provider, and platforms that move money for other businesses.
In practice you see four groups:
Merchants selling across borders. A provider that is excellent at home is often mediocre two countries over. Local cards, local methods, and local rules push you toward local providers, and suddenly you have four.
Subscription businesses. Their revenue depends on renewals, and renewals fail for boring reasons: expired cards, banks that decline the first attempt, issuers that behave differently at 3am. Retrying elsewhere is worth real money to them.
High-risk verticals. Travel, gaming, and marketplaces get shut off by providers with little notice. A second live provider is not an optimization for them. It is continuity.
Platforms and marketplaces. They move money on behalf of sellers, so they inherit every seller’s geography and risk profile at once.
Notice what these have in common. It is not size. A small merchant selling in six countries needs orchestration more than a large one selling in a single market with one provider that works fine.
Where it breaks in practice
Vendor pages stop at the happy path. These are the parts that bite after go-live.
Fallback is not free
Retrying a declined payment with a second provider sounds like pure upside. It is not.
Some declines are final. If the card is stolen or the account is closed, the second provider will decline it too. You have paid for another request, added seconds to checkout, and produced a second entry in your reports. Worse, some issuers treat repeated attempts on the same card as a fraud signal.
Retry the declines that mean “not now”. Do not retry the ones that mean “no”. A platform that retries everything is not smart routing, it is expensive noise.
Cheapest is not always cheapest
Sorting by cost is easy. Getting the cost right is not.
Real cost depends on the card brand, the card subtype, the amount, and the method. A provider that is cheaper on domestic debit can be dearer on foreign credit. If the platform sorts on a flat rate, it will confidently pick the wrong provider all day and show you a tidy report while it does.
Ask how the cost is calculated per payment, not per contract.
Health scores lag
Health is measured over a window. Ours defaults to one hour. That window is a trade-off, not a setting to leave alone.
A short window reacts fast and overreacts to noise. A long window is stable and slow to notice a provider that started failing ten minutes ago. Either way, the score describes the recent past, not this second. Routing on it means routing on slightly stale information, always.
Reconciliation gets harder, not easier
One provider means one settlement file. Five providers mean five files, five schedules, five ways of naming a refund, and five sets of fees deducted before the money lands.
The orchestration layer unifies the payment view. It does not automatically unify the money view. Ask what happens after settlement, not just before authorisation.
One integration becomes one dependency
You removed five integrations. You added one thing that every payment now passes through.
That is usually the right trade. It is still a trade. Ask about the uptime record, what happens during a deploy, and whether you can reach a provider directly if the layer is down.
What orchestration does not fix
Worth saying plainly, because the category is sold as if it fixes everything.
A bad approval rate stays bad. Routing moves payments to the provider most likely to approve them. If every provider you hold declines the same traffic for the same reason, routing just spreads the declines around. The fix there is the reason code, not the router.
PCI scope does not move. How you handle card data does that, and it is a separate decision. A layer that passes raw card numbers through keeps you exactly as in-scope as you were.
Somebody still owns payments. Rules encode decisions. Somebody still has to make the decisions, watch what they did, and change them when the market moves. Teams that buy a platform and assign nobody to it get a more expensive version of what they had.
A weak provider stays weak. If your acquirer has poor coverage in a market, adding a router in front does not give it coverage. It only makes it easier to send that traffic elsewhere.
Do I need a payment orchestration platform?
Probably not, if you have one provider and one market and the approval rate is fine. Adding a routing layer to a setup that works adds moving parts and solves nothing.
You do need one when at least two of these are true:
- You already have two or more providers. Someone is already routing between them. Right now that someone is a developer with an
ifstatement. - You are losing renewals or sales to declines you never investigate. If nobody in the company can name your top three decline reasons, that is the signal.
- A provider outage would stop your revenue. Not slow it. Stop it.
- You are entering markets where your current provider is weak. Local methods are usually the forcing function.
- Provider fees are a line item someone asks about. Once cost per transaction is a board question, routing on cost stops being theoretical.
And the honest version of the opposite case. If you are doing a few hundred payments a month in one country, the effort belongs in your checkout UX. The wins there are bigger and cheaper.
The quickest check takes a minute. Open last month’s report and answer three questions without asking anyone. How many providers did you use? What is your approval rate in your worst country? Who on your team changes the route if the main provider goes down tomorrow at ten in the morning?
Answered all three in a minute? You do not need orchestration yet, because you already hold payments in your hands. Went to a developer for even one of them? You are already paying for the missing layer, just not on a separate invoice.
How to choose a payment orchestration provider
Ask questions that are hard to answer with a slide. The five below separate products that route from products that only claim to.
1. What exactly does your capability check read? You are asking whether “supported” means a marketing table or the code path that runs at 3am. The Click to Pay example above is the shape of this problem, and every platform has its own version of it.
2. How is cost computed per payment? Listen for card brand, subtype, amount, and method. If the answer is a single percentage per provider, cost-based routing is decoration.
3. What happens when every provider looks unhealthy? The right answer is that the payment still goes out. Anything else is a platform that will fail your traffic to protect its own metrics.
4. Which declines do you retry, and where is that list? You want a specific list you can edit, not “our smart engine decides”.
5. What do I keep if I leave? Ask about stored card tokens specifically. Tokens that only work inside one platform are a lock-in mechanism, whatever the contract says. Ask whether network tokens are issued in your name.
How to compare the answers
Five questions produce five stories. Score them instead, so the comparison survives the meeting.
| Answer to question 1–5 | Score |
|---|---|
| Named a specific mechanism, file, or field you can verify later | 2 |
| Described the behaviour correctly but generally | 1 |
| Reframed the question or answered a different one | 0 |
Ten points available. Anything at 7 or above is a product that has met these problems. Below 4 means the demo is ahead of the engineering, and you will be the one discovering the gap.
Score them the same day, before the next call blurs the answers together. And write down the exact words for question 3 — the one about all providers being unhealthy — because that is the answer people revise later.
Two more things worth checking that have nothing to do with routing. Ask who is on the hook when a provider changes an API and the connector breaks. And ask to see the reporting model before you sign, because that is what your finance team will live in every month.
We keep a side-by-side of the market in payment orchestration platforms compared. The difference between orchestration and a plain gateway is unpacked in payment orchestration vs payment gateway.
What to do this week
You do not need a project to start. You need three numbers.
Pull your approval rate by country, not in total. An overall 92% can hide 60% in one market where the issuer declines foreign cards. That single split has started more orchestration projects than any vendor deck.
Count your top decline reasons. Take last month, group by reason code, and look at the top three. Then ask which of them a retry somewhere else would have recovered. If the answer is “most of them”, you have your business case in one line.
Time a provider outage on paper. Walk through what happens if your main provider is down for two hours on your busiest day. Who notices, how, and what do they switch to? If the answer involves a deploy, you already know the gap.
Those three numbers will tell you more than any comparison table. If they point at a routing problem, the next step is picking who to route to.
Our provider directory lists acquirers and payment methods by country and vertical. Use it to see who actually operates in the markets you are entering, before you talk to anyone.
