Payment Orchestration: Routing Between Processors.

A broker signs a second acquirer because the first one keeps declining Polish cards. Six weeks later the deposit page has two buttons, clients pick whichever they used last, support cannot tell which provider a payment went through without checking two dashboards, and finance is reconciling two settlement files against one client ledger by hand. The second acquirer solved a decline problem and created four new ones.

Orchestration is the answer to that mess. The client sees one deposit form. Behind it, a routing layer chooses a provider per transaction, retries elsewhere when it makes sense, and writes every attempt into one place.

What the routing layer decides on

Rules are evaluated per transaction against attributes known before the payment is sent. The set that carries most of the value in this industry is short:

• Issuer country from the card BIN, matched to the acquirer with the best local approval performance.
• Card brand and product type, since some acquirers price and perform very differently on commercial cards.
• Amount and currency, routing large deposits to the provider with a better limit profile and avoiding an unnecessary conversion.
• Client segment, so a returning client with a clean history can take a lower-friction path than a first-time deposit.
• Provider health, taking a provider out of rotation automatically when its response times or decline rate cross a threshold.

None of this requires machine learning to be useful. A firm with two acquirers and a table of approval rates by issuer country can write a dozen static rules that recover a meaningful share of lost deposits. Sophistication comes later, and the measurement discipline behind it is the same one described in approval rate work.

Cascading, and the limits on it

When a payment is declined, the orchestration layer can present the same transaction to a second provider. This works because a decline is frequently a decision by one risk stack rather than a statement about the cardholder, and a different acquirer with a different descriptor and a different fraud model may approve it.

Two constraints apply. Scheme rules limit the number of attempts a merchant may make against the same card and distinguish between decline codes that permit a retry and codes such as stolen card or do not honour that do not. Repeated retries against a hard decline generate fees and can attract a monitoring programme. The other constraint is duplication: a retry after a network timeout can double-charge a client if the first attempt actually succeeded, so idempotency keys and a reconciliation pass are not optional.

Tokens, and who owns them

Card details are stored as tokens, and the question of which system holds those tokens decides how free a merchant really is. A token issued by one processor is worthless to another, so a firm that vaulted five years of stored cards with a single provider cannot simply move. Migration is possible through a provider-to-provider transfer, and it is a project rather than a switch.

Network tokens issued at the scheme level, and orchestration platforms that operate their own vault, both reduce that lock-in. For a firm that expects to change acquirers, and in this industry that is most firms, keeping the vault independent of any single processor is worth negotiating for at the start rather than discovering later.

One ledger, or the reporting is fiction

The part that gets least attention and causes most pain is reconciliation. Each provider produces its own settlement file with its own fee structure, its own timing and its own reference format. Without a unifying layer, a firm's payment reporting is an assembly of exports, and nobody can answer a simple question like the true cost per deposit by country.

The right design writes every attempt, approval, decline, refund and chargeback onto the client record with the provider, the reference and the fee attached, before anything is exported. Then the deposit history a support agent sees, the AML view a compliance officer sees and the cost analysis finance runs all come from the same rows. In a broker back office this is a design decision made once, and retrofitting it after two years of mixed data is considerably harder.

Build it or buy it

Dedicated orchestration platforms are real products with real value at scale: many providers, high volume, complex routing that changes weekly, and a team dedicated to payments. They also add a fee per transaction on top of processing costs, and they become another integration in the middle of the money.

For a trading firm with two or three providers, my position is that the routing belongs in the system that already holds the client record. The rules are simple, the volumes are known, and the value of orchestration for that firm is 80 percent the unified ledger and 20 percent the clever routing. Buying a platform to get the ledger is paying a transaction fee for a database table. The calculation changes as the provider count grows, which is the trade-off examined in running multiple payment providers.

Whichever route a firm takes, the operational rule is the same: no processor should be irreplaceable. Contracts, tokens and reporting all need an exit path, because in this sector an acquirer relationship can end with a policy change rather than a negotiation, and the firms that survive that week are the ones that had a second route already live and tested.

"The value of a second processor is not the second processor. It is that you now have a comparison, and a comparison is the only thing that tells you the first one was underperforming."

— Roman Onta, Executive Director, SINGUARD

Frequently Asked Questions