A payment gateway carries one payment to one acquiring bank. Payment orchestration sits above several gateways, picks which one gets the payment, and turns their different answers into one shared language. They are not rivals. You can run a gateway with no orchestration, but you cannot run orchestration with no gateway underneath.
That is the short answer. Below is what each layer really owns, the part where the split gets messy, and how to tell which one your problem belongs to.
What is a payment gateway?
Your payment gateway is the service that takes card details from the checkout and sends an authorisation request to the acquiring bank on your behalf.
It does four jobs. It accepts the card data, it protects it in transit, it speaks the bank’s protocol, and it hands you back a yes or a no. Everything else a gateway sells you sits on top of those four.
The word gets used loosely, and that is where half the confusion starts. Ask five vendors what a gateway is and you get five answers, because most of them also sell acquiring, or fraud tools, or both, under the same name.
What is payment orchestration?
Payment orchestration is running several providers behind one integration, with rules that decide where each payment goes.
The layer holds the connections, the routing rules, and one shared model of what a payment is. When a provider declines, the layer can try the next one without your checkout knowing anything changed. If you want the mechanics of the layer itself, start with what is payment orchestration — this article stays on the boundary between the two.
What is a payment orchestration platform?
The payment orchestration platform is the bought version of that layer. You get the provider connectors, a rules engine, and reporting, instead of building them.
The important word is above. The platform does not replace your gateway contracts. It sits on top of them and calls them. The gateways stay. What goes away is the code in your checkout that knew about each of them.
Buyers usually want a feature list at this point. That belongs in a separate piece — see payment orchestration software: what it must do for the demands worth making. And if you would rather see the machinery than the shopping list, a look inside the orchestration layer takes the lid off.
The difference, line by line
Here is the split as it shows up in a contract and in a codebase.
| Question | Payment gateway | Orchestration layer |
|---|---|---|
| How many providers does it talk to? | One acquirer, sometimes a few | Many gateways |
| Who decides where a payment goes? | Nobody. It is the only road | Rules plus live signals |
| Who holds your merchant account? | The acquirer behind it | Nobody. It holds none |
| Who moves the money? | The acquirer | Nobody |
| What does it return? | Its own status codes | One shared vocabulary |
| Where do stored cards live? | Its vault, usually | Its vault, or yours |
| Who handles a chargeback? | The acquirer, through it | It shows you the case, that is all |
Read the fourth row twice. An orchestration layer never touches your money. It is a decision and translation layer, and the funds go from cardholder to acquirer to your bank account exactly as before.
That single fact answers a lot of questions people ask in vendor calls. Settlement timing does not change. Your acquiring fees do not change. Your chargeback ratio does not change on the day you switch it on.
How the two work together, step by step
One payment, both layers, in order.
1. Your checkout collects the card. Or a hosted page does. Hold that thought, because that choice decides your PCI scope later.
2. The layer picks a provider. Rules first, then filters. Sandbox accounts drop out of live traffic. Providers that cannot handle this method drop out too.
3. The layer translates. Your one request shape becomes whatever that gateway wants: its field names, its amount format, its signature.
4. The gateway does the bank part. It reaches the acquirer, the acquirer reaches the card scheme, the scheme reaches the issuing bank. Two of the three steps happen on rails nobody in this chain owns.
5. 3DS happens, if it happens. The cardholder may be sent to their bank to confirm. Where the customer goes next depends entirely on the gateway.
6. The answer comes back in the gateway’s own words. The layer turns it into a shared status and, if the answer was a soft decline, may try the next provider.
Steps 3 and 6 are the whole value of the layer. Everything else in that list would happen with or without it.
Five gateways, five dialects
This is the part vendor pages skip, so here it is with real numbers. The platform I work on runs five acquiring integrations. Two of them sit inside banks, the rest are independent, and as far as our code is concerned all five are gateways. None of the five agrees with another on anything that matters at the wire level.
| Integration | Request signature | Amount format | Credential fields |
|---|---|---|---|
| UPC | RSA SHA-512, your PEM key | Integer minor units | 6, of which 3 required |
| OschadBank | HMAC-SHA1 over a built MAC string, hex key | Decimal string, two places | 10, of which 3 required |
| PayLink | HMAC-SHA1 over key + base64 body + key | Decimal string, two places | 4, of which 2 required |
| LiqPay | SHA1 of key + base64 body + key, then base64 | Plain decimal number | 3, of which 2 required |
| Hutko | SHA1 of sorted values joined by a pipe | Integer minor units | 4, of which 2 required |
Look at the amount column. Two of the five want 1250 for twelve fifty. Two want the string 12.50. One wants the number. Get that wrong in one direction and you charge a hundred times too little. In the other direction, you charge a hundred times too much, and you find out from a customer.
Now look at the field counts. Twenty-seven credential fields across five gateways, and no two of them name the merchant identifier the same way. UPC wants a Merchant ID and a Terminal ID. OschadBank wants a Merchant and a Terminal. LiqPay wants a public key.
Three of them have a field called private_key, and it means three different things: an RSA key in PEM form for UPC, a shared secret for PayLink, and a SHA1 salt for LiqPay. Paste one into the other and nothing errors. You just get a signature that fails every time, and a support ticket that takes a week.
Signatures cut both ways. The gateway signs its callback to you, and you have to check that signature before you believe a word of it. You check UPC’s callback against an X.509 certificate you load from them. You check LiqPay’s with the same shared secret that signed the request going out. OschadBank builds four different strings to sign — one for authorisation, one for reversal, one for completion, one for the response coming back — and picking the wrong one fails the check for a reason no log explains. That verification code is what teams forget to write. It is also what stands between you and a forged callback marking an unpaid order as paid.
The status vocabulary problem
Every gateway invented its own list of answers. The layer’s job is to collapse them into one list your reports can count.
| Integration | Shape of the answer | Distinct codes mapped |
|---|---|---|
| PayLink | One resultCode | 63 |
| UPC | One TranCode | 25 |
| LiqPay | One status word | 22 |
| OschadBank | ACTION and RC, read together | 14 actions, 60 codes |
| Hutko | A status word, meaning set by which call you made | 3 separate maps |
All of that collapses into 12 payment statuses and 15 decline reasons on our side. Roughly two hundred provider words become twenty-seven of yours.
Three traps live in that table, and none of them is obvious from a specification.
Same word, opposite meaning. Hutko returns hold in an order status to say the money is held. Hutko also returns hold in a capture response to say the capture was refused. One word, two meanings, and only the call you made tells you which.
Success that does not look like it. PayLink treats 100, 101 and 102 as approved: full amount, partial amount, and purchase amount only. Treat anything that is not 100 as a failure and you refuse money the bank already gave you.
A decline that is not one. UPC code 131 means extra authentication is required. Code 601 means the customer walked away without finishing. Neither is a no from the bank, and both land in the declined bucket if nobody read the manual. OschadBank does the same thing with actions 10 and 11: one asks for an OTP, the other asks the cardholder to confirm a random amount.
That last one has a sting. In OschadBank’s answer, 10 in the ACTION field means an OTP check is pending, while 10 in the RC field means partially approved. Same digits, different field, opposite outcome.
The flow nobody can normalise
Here is where the neat picture breaks, and it is worth being honest about it.
Our provider contract has one method for finishing 3DS after the cardholder comes back from their bank. Exactly one gateway of the five implements it: Hutko, with a step-one and step-two call pair. The other four return a defined refusal, each for a different reason.
- UPC does 3DS on its own payment page, so there is no step for us to finish.
- LiqPay handles it internally and tells us the result later.
- PayLink closes the loop through a
getTranStatecallback. - OschadBank closes it through a
BACKREFcallback.
An orchestration layer can flatten field names, amounts and status codes. It cannot flatten where the customer’s browser goes. One of these flows takes over the screen and one does not, and no adapter makes those the same thing.
So the honest version of “one integration” is this: one integration for your server, and at most two or three shapes of checkout that your front end still has to know about. Any vendor who tells you the number is one has not integrated a redirect gateway and a host-to-host gateway in the same product.
Where the boundary breaks in practice
Five things bite after go-live. All of them sit exactly on the seam between the two layers.
Some limits also stay with the gateway, whatever sits above it. UPC refuses a capture once 30 days have passed and answers with code 506. No routing rule moves that deadline. The layer can warn you before it lands, and that is all it can do.
Tokens stay where they were born
A gateway that stores your customers’ cards gives you a token. That token works with that gateway. It is meaningless to the gateway next door.
Follow that through and the marketing claim falls apart. If your saved cards live in gateway A’s vault, you cannot retry a failed renewal on gateway B, because at authorisation time nobody outside A can turn that token back into a card number. Routing on the first attempt still works, because you have the card in hand. Every later charge is locked to whoever vaulted it.
There are two ways out, and both cost something.
- Hold the card data yourself. That pulls a vault into your PCI scope, and everything that comes with it.
- Get network tokens issued in your own name. Cheaper to live with, slower to arrange: it is a conversation with the schemes and the acquirer, not a config change.
Our own card service takes the first road. Card numbers are encrypted through HashiCorp Vault Transit with an aes256-gcm96 key, and the key is set to rotate every 2160 hours, which is 90 days. That number is a choice, not a rule: PCI DSS v4.0.1 requirement 3.7.4 asks you to define a cryptoperiod and change keys at the end of it, and leaves the length to you.
PCI scope follows the card form, not the layer
Adding orchestration does not move your PCI DSS scope by itself. What moves it is where the cardholder types the number.
If the card form is served from a hosted page and never touches your site, you sit in the lightest questionnaire. If the form is on your page, even as an embedded frame you control, you are in the heavier one. That is true whether or not a routing layer sits behind it.
Two requirements make this concrete, and both stopped being optional on 31 March 2025. Requirement 6.4.3 says every script on a payment page must be authorised, inventoried and integrity-checked. Requirement 11.6.1 says you must detect unauthorised changes to that page, at least weekly.
There is a twist worth knowing. In January 2025 the PCI Security Standards Council removed both from SAQ A and replaced them with an eligibility question: you must confirm your site is not open to script attacks, or get that confirmation in writing from your provider. So the paperwork got shorter and the responsibility did not. If you validate under SAQ A-EP or SAQ D, both requirements apply in full.
You pay for both layers
A gateway charges you per transaction. An orchestration platform charges you too, usually per transaction as well.
Routing on cost only pays for itself when the gap between your cheapest and dearest provider is bigger than the layer’s fee. In a single market with one currency and near-identical rates, it often is not. Do that arithmetic on last month’s real volume before anyone builds a business case out of it.
Reconciliation gets harder before it gets easier
One gateway means one settlement file. Five gateways mean five files, five schedules, five names for a refund, and five ways of deducting fees before the money lands.
One question sorts the serious platforms from the rest: what does it match on? An order reference you set, the gateway’s own transaction id, or the amount and the date? Only the first survives a partial refund and a fee deduction landing on the same day.
The layer unifies the payment view on the day you switch it on. The money view stays as fragmented as your provider list, unless the platform does settlement matching too. Ask about that specifically, because it is the part finance teams inherit and nobody demos.
Both layers can be down
You removed five integrations and added one thing that every payment now passes through. Usually that is the right trade. It is still a trade.
Ask what happens during a deploy, ask for the incident history, and ask whether you can reach a gateway directly if the layer stops answering. A platform that cannot answer the last question has quietly made itself a single point of failure.
Gateway, processor, acquirer, aggregator: who is who
Four words get used as if they meant the same thing. They do not, and the difference decides who you call when something breaks.
- Acquirer. A bank with a licence from the card schemes. It holds your merchant account and it settles your money. Only a bank can do this.
- Processor. The technical engine behind the acquirer. Often a separate company. You rarely talk to it directly.
- Gateway. The API in front of that stack. It is what your code sees.
- Aggregator or payment facilitator. Someone whose merchant account you use instead of holding your own. Faster to start, less control later.
- Orchestration layer. Above all of them. Decides which of your gateways gets this payment.
The middleware label you see in search results usually means the same thing as orchestration, described from the engineering side rather than the commercial one. If someone hands you the word, ask whether it routes or merely translates. Those are different products with the same pitch.
Do I need a payment orchestration platform?
Probably not, if one gateway covers your market and your approval rate is fine. Adding a layer to a setup that works buys you moving parts and solves nothing.
The gateway alone is enough while all of this holds:
- one market, one currency, one set of card brands
- one acquirer who has never threatened to drop your vertical
- an outage you could survive by waiting it out
- nobody in finance asking what a payment costs by brand and country
You have outgrown it once two of these are true:
- You already run two or more providers. Something already routes between them. Right now that something is an
ifin your checkout, and one developer remembers why. - Your saved cards are stranded. Renewals can only be retried on the gateway that holds the token, and you have started noticing.
- A single provider outage stops revenue. Not slows. Stops.
- You are entering a market where your gateway is weak. Local methods are usually what forces the move.
- Provider cost has become a board question. Once someone asks for cost by card brand, flat-rate thinking stops working.
A quick test, and it takes about a minute. Open last month’s report. How many providers are in it? What is your approval rate in your worst country, not overall? If your main gateway went down at ten tomorrow morning, who changes the route, and does that need a deploy?
If the third answer involves a release, you are already paying for the missing layer. You are just not getting an invoice for it.
What to do this week
Start with three numbers, not a project.
Split your approval rate by country. An overall 92% can hide 60% in one market where issuers decline foreign cards. That one split has started more orchestration projects than any vendor deck.
Read your top three decline reasons. Group last month by reason code, then ask which of them a second provider could plausibly have recovered. Soft declines are worth retrying. A stolen card is not, anywhere.
Ask your gateway who owns the tokens. Get the answer in writing before you plan anything else. It decides whether routing is possible on the second attempt or only on the first, and everything else follows from that.
Those three numbers tell you more than any comparison table. If they point at a routing problem, the next question is who you would route to.
And if you are still mapping which acquirers and methods even operate in the countries you are entering, our provider directory is the cheaper place to start than a round of sales calls.
Standards and requirement numbers in this article were checked against PCI DSS v4.0.1 on 1 September 2026.
