Payment orchestration platform: what it is, what it does and how to choose one
A payment orchestration platform is software that sits between a payment business and its providers: one API and one checkout on the merchant side, dozens of acquirers and local methods on the other, with routing, cascading, tokens, webhooks and reports in between. It does not replace licences or settlement; it replaces the integrations and the glue code a payment company would otherwise build itself.
What orchestration does
- One integration instead of many. Providers are integrated into the platform once; a client enables them in its network and never writes a provider adapter again.
- Routing. Rules by country, currency, BIN, amount, method, time window and merchant decide which terminal a payment goes to; weights split traffic between acquirers.
- Cascading. A declined payment is retried on the next terminal of the route group without the payer noticing, within the limits the rules set.
- One checkout, one vault. A hosted checkout in 29 languages shows the methods the routing allows; a card stored once is tokenised for every acquirer the client uses.
- Webhooks, journals, reports. The merchant gets one event stream; operations get a trace per payment; finance gets balances, fees and settlements in one ledger.
The layers of a platform
| Layer | What it holds | Who configures it |
|---|---|---|
| Merchant side | The API, the hosted checkout, the merchant cabinet, webhooks | The merchant integrates once; the client brands it |
| Decision | Routing rules, route groups, limits, restrictions, versions | The client’s operations team, in the flow builder |
| Vault | Cards as tokens, provider tokens behind them, expiry checks | The platform; the client sets the retention and the acquirers |
| Providers | Adapters for acquirers, local methods, Open Banking, crypto, payouts | The platform builds them; the client enables them with its accounts |
| Records | The journal of every attempt, the trace, the ledger, the reports | The platform; the client reads and exports |
| Deployment | The platform’s cloud or the client’s cloud account | The client decides |
What it does not do
An orchestration platform does not hold money, does not contract with merchants and does not replace the licences of the companies that use it. Settlement happens between the client and its providers; the platform records it. That is why Tranzify can serve a PSP in Poland, an acquirer in Saudi Arabia and a fintech in Brazil with the same software: each of them is licensed where it operates, and the software is the same.
Who uses it, and for what
A PSP replaces its own stack and its integration backlog; an acquirer adds a checkout, tokens and local methods on top of its processing; a fintech launches on its licence without building; a crypto exchange routes fiat deposits and withdrawals across providers; a marketplace pays sellers on local rails from one ledger; a large merchant with several PSPs cascades declines and keeps its stored cards across acquirers. The solutions pages describe each case, and the industries pages the flows of iGaming, forex, subscriptions and the rest.
How to choose one
- Catalogue depth in your regions. Count the local methods and the Open Banking providers in the countries you sell in, not the logos on the home page.
- Routing you can read. Rules should be written in a builder your operations team can audit, not in the vendor’s tickets.
- Deployment. Ask whether the platform can run in your own cloud account when a regulator or a bank partner requires it.
- Journals and retention. Every attempt, callback and retry for the years your regulator asks; a trace per payment that support can open.
- A way in and a way out. A migration path for merchants you bring from another platform, and an export of your data if you leave.
- The vault’s ownership. Tokens that belong to your network, not to an acquirer, so that a change of provider does not lose stored cards.
- The pricing model. A licence or a platform fee you can forecast, rather than a share of every transaction that grows with your success.
What orchestration changes in the numbers
The approval rate is the first number: a cascade recovers the share of declines that came from the provider rather than from the payer, and the back office shows it per route group by day. Cost per transaction is the second: routing by scheme, country and amount sends each payment to the acquirer with the better fee within the limits you set, and the ledger shows the fee per payment by terminal. Time to a new market is the third: a country becomes rules and accounts rather than an integration project. The blog post on measuring cascade recovery explains the first in detail.
Tranzify’s answer
Tranzify is the orchestration layer built for licensed payment businesses before being licensed to others: gateway API, hosted checkout, card vault, routing and cascading, alternative methods by region, payouts, crypto rails, webhooks, white-label networks and the admin and merchant cabinets. It runs in our cloud or in yours, with journals kept five years and logs ten, and it accepts, holds and transfers nothing.
Updated: 2026-11-08