Payment orchestration platforms: how routing across acquirers and PSPs works
A payment orchestration platform sits between a merchant's checkout and several acquirers and PSPs, and picks a route for each payment by card, country, currency, cost or approval rate, with failover, retries and one vault.
A payment orchestration platform is a layer of software between a merchant's checkout and several acquirers and payment service providers. The merchant integrates once; for each payment, the layer decides which provider to send it to, by rules on the card, the country, the currency, the cost or the approval rate. It also fails over when a provider is down, retries a decline only where the card schemes allow it, keeps saved cards usable on every route, and reconciles what each provider pays out.
What a payment orchestration layer is
Without one, a merchant connects its checkout to one payment service provider or acquirer, and every card payment goes there. With payment orchestration, the checkout talks to the layer, and the layer holds connections to several providers behind it.
The providers still do the processing. Each keeps its own contract with the merchant, sends the authorisation through the card schemes to the issuer, and settles its own payments. The layer only chooses, records and translates: one API, one payment ID and one set of response codes for the merchant, whatever happens behind it.
Routing rules: by card, country, currency, cost or approval rate
Payment routing is a list of rules the layer reads for every payment, top to bottom, until one matches. Typical inputs are:
The card. Its scheme, whether it is debit, credit or commercial, and the country of the issuer, all read from the first digits of the card number.
The country and currency. Many merchants send cards issued in a country to an acquirer in that country, and settle each currency with the provider that holds it.
Cost. What each provider charges for that kind of card, where approval rates are similar.
Approval rate. The share of payments each provider has had approved for that kind of card, measured by the merchant on its own traffic.
Volume and contracts. A share of traffic kept on each provider, or a monthly minimum promised in a contract.
A rule can name one provider, split traffic between two to compare them, or list a primary and a backup.
A worked example: the cheaper route is not always cheaper
With illustrative numbers, a merchant sees 2,000 payments a month from UK-issued cards, at 80 euros each: 160,000 euros of attempts. Acquirer A charges 0.9% and has approved 88% of these cards; acquirer B charges 1.1% and has approved 93%, fees being charged on approved payments.
Illustrative, per month | Acquirer A | Acquirer B |
|---|---|---|
Approval rate | 88% | 93% |
Approved payments | 1,760 | 1,860 |
Approved value | 140,800.00 EUR | 148,800.00 EUR |
Fees | 1,267.20 EUR (0.9%) | 1,636.80 EUR (1.1%) |
Kept after fees | 139,532.80 EUR | 147,163.20 EUR |
A rule on cost alone sends these cards to A. A rule on what the merchant keeps sends them to B, which earns 7,630.40 euros more a month, because five more points of approval are worth more than 0.2% of fees. For cards where both providers approve at the same rate, the cheaper one wins, and the layer can hold both rules at once.
Failover: when a provider does not answer
Payment failover handles the provider, not the customer. If a request times out, the connection fails or the provider returns a technical error, the layer sends the payment to the next route and the customer sees one checkout.
The catch is the payment that was approved but whose answer was lost. Before failing over, the layer asks the first provider for the payment's status, and if it was approved there, it either keeps that result or reverses it. Mastercard's gateway documentation says the same for its own API: after no response or a timeout, resend the request with the same order and transaction IDs, so a repeat is recognised as one payment, not two.
Retries: when the scheme says not to ask again
A decline is different. It is the issuer's answer, carried back as a decline code, and the card schemes set when a merchant may ask again, through any route.
Visa's rules group decline codes into four categories (Visa Core Rules and Visa Product and Service Rules, 18 April 2026, Table 7-2):
Category 1, issuer will never approve. Codes such as 14 (invalid account number), 41 (lost card), 43 (stolen card) and 46 (closed account). After one of these, a merchant "must never resubmit" the request for the same payment credential.
Category 2, issuer cannot approve at this time. Codes such as 51 (not sufficient funds), 91 (issuer or switch inoperative) and 96 (system malfunction). Reattempts are permitted, up to 20 attempts in 30 days.
Category 3, data quality. Codes such as 54 (expired card) and N7 (CVV2 failure), and in Europe 1A, additional customer authentication required. Up to 20 attempts in 30 days.
Category 4, generic. All other decline codes, with the same limit.
The same rules say that a merchant or acquirer that reattempts a declined request "must not intentionally manipulate any data elements" of the original, naming among others the acquiring identifier, the acquirer and merchant country, the MCC and the electronic commerce indicator (Section 1.7.2.1). A retry through a second acquirer is still the same merchant and the same payment, not a way to make it look like another one. How a given cascade fits the rules is a question to settle with each acquirer.
Mastercard sends a merchant advice code with a decline. Its gateway documentation lists 03 as "do not try again", 02 as try again later, 24 to 30 as retry after one hour, 24 hours or up to 10 days, and R0, R1 and R3 as stop payment and revocation orders.
So the layer needs one table: each provider's own codes mapped back to the scheme's, the category or advice of each, and a count per card across every route. An insufficient-funds decline sent at once to a second acquirer usually fails again and still counts.
Tokens and the vault: a saved card that works on every route
Routing a returning customer's card to any provider needs the card itself, not one provider's reference to it. A token from a PSP's own vault usually works only at that PSP, so a card saved there cannot move to acquirer B. An orchestration layer keeps its own vault: it stores the card number once and gives the merchant a token that it can send to any route.
That vault holds card numbers, so it sits fully inside PCI DSS, which applies to every entity that "store, process, or transmit cardholder data" (PCI SSC). The Council's tokenisation guidance calls the data vault the most attractive target for attackers, and puts every part of the tokenisation system in scope (PCI DSS Tokenization Guidelines). The merchant's systems that see only tokens can fall outside it; the guide on PCI DSS for a payment gateway covers that scoping.
The card's security code is never kept. The Council says it is sensitive authentication data, not to be stored once the purchase it was collected for is authorised, even encrypted and even with the customer's consent (PCI SSC FAQ).
Network tokens add a second layer of payment tokenisation. EMVCo describes an EMV Payment Token as a replacement for the card number that is "constrained in how it can be used", for example to a specific merchant, and that travels from the point of purchase through the acquirer and the networks to the issuer (EMVCo). A network token issued for the merchant can go through whichever acquirer gets the payment, where that acquirer accepts them, and the Payment Account Reference links tokens back to one card for fraud checks.
3-D Secure across providers
3-D Secure is an exchange between the merchant and the issuer: EMVCo describes it as messages about the transaction, the payment method and the device, which the issuer uses to authenticate the customer, with a challenge only for riskier payments (EMVCo). EMVCo also notes that the European Banking Authority recognised in 2019 that EMV 3DS supports strong customer authentication under PSD2.
When each PSP runs its own 3-D Secure, a failover to a second PSP can mean a second challenge for the customer. When the layer runs its own 3-D Secure server, the customer authenticates once and the result, with its electronic commerce indicator, goes with the authorisation to whichever acquirer gets it, where that acquirer accepts authentication done outside it. A Visa 1A decline in Europe then has a clear path: authenticate, then retry.
Reconciliation across providers' settlement files
Each provider pays out on its own schedule, in its own file format, usually net of its own fees, refunds and chargebacks. Three providers mean three settlement files and three kinds of payout reference at the bank.
Reconciliation across them works in three steps:
One payment ID. The layer gives every payment its own ID and records each provider's reference for every attempt, approved or not.
Settlement lines to payments. Each line of each file is matched to a payment by that reference, with the gross amount, the fee and the net.
Payouts to the bank. Each payout is matched to the sum of its lines, and each difference (a missing payment, a fee not agreed, a chargeback not booked) becomes an item to investigate.
When a business needs orchestration, and when one acquirer is enough
One acquirer is often enough. A merchant selling in one or two countries, at volumes where a point of approval is worth little, gains less than it costs to run several contracts, integrations and settlement files.
Orchestration starts to pay when:
Sales cross many countries, and local acquirers approve local cards better.
Downtime is expensive, and a second route has to take over within seconds.
Volume is large, so a point of approval or a tenth of a percent of fees is worth the work.
Payment methods vary by market, and no single provider covers them all.
The merchant wants to switch providers without asking customers to save their cards again.
Frequently asked questions
Is a payment orchestration platform a PSP? No. It does not process or settle payments, and it does not hold the merchant's money; the providers behind it do. It chooses the route, keeps the vault and the records, and translates the answers.
Can a declined card be retried through another acquirer? Only where the scheme allows it. At Visa, a Category 1 decline is never resubmitted for that card, and other categories allow up to 20 attempts in 30 days, counted across every route; a Mastercard advice code 03 means do not try again.
Who is responsible for PCI DSS when the layer keeps the vault? Whoever runs the vault. It holds card numbers, so it is in scope in full, while merchant systems that only see tokens can be kept out of scope.
Does a merchant need a contract with every acquirer? Yes. Each acquirer or PSP behind the layer signs the merchant, or the platform serving the merchant, after its own checks.
See it working
Our white-label payment gateway includes routing that sends each payment to the processor with the best results for its card type and country, and retries declines elsewhere when the reason allows, with merchants free to keep their own acquirer contracts. Its ledger reconciles payouts daily with processors and banks, and the full source code is handed over. To plan a gateway around your own routes, start your project at paynoramic.com.
