Payment orchestration vs payment routing
Payment orchestration is the layer that connects a business to several payment providers through one integration and manages their connections, credentials, events, retries and reporting. Payment routing is one decision inside that layer. For each payment it picks the provider or rail that should carry it, judged on cost, speed and the chance of success. Every orchestration layer includes routing, but you can also use routing without the rest of that layer. Vendors use both terms loosely and sometimes interchangeably.
What payment routing decides
Routing takes one payment and picks where it goes. The inputs are facts about the payment and about your providers:
- The payment: the operation, amount, currency, and the countries and banks on each side.
- Your providers: which ones are connected, what each covers in that country and limits such as a maximum amount per payment.
- Your contracts: what the next payment costs at each provider, including the volume tier you're in this month.
- Reliability: how payments like this one have gone at each provider recently.
- Your preference: cheapest, fastest or a balance of cost and success.
The output is the provider to use, its expected cost and time, a fallback if it fails and the reasons for the choice. Least cost routing is routing on cost alone. Smart routing usually weighs cost against speed and the chance of success. The smart payment routing page covers it in detail.
What payment orchestration adds
Orchestration is everything around that decision that lets you run several providers as if they were one:
- One API and SDK across providers, where adding a provider means a configuration change and no new integration.
- Provider connections and their credentials, kept somewhere safe.
- Events and webhooks in one format across providers, giving your systems one set of statuses to handle.
- Retries and failover when a provider or a bank connection is down.
- Reporting and reconciliation across providers.
- For cards, tokenisation, so one stored card can be sent to different processors.
With cards, orchestration usually means routing transactions across acquirers and processors. In open banking the same idea applies to PISPs, account information providers and verification vendors. There, providers differ as much in the countries and banks they reach as in price.
Payment orchestration
- One API and SDK
- Provider connections
- Credentials
- Events and webhooks
- Retries and failover
- Reporting
Payment routing
Which provider should carry this payment, at what cost, and why?
Side by side
| Compared on | Payment routing | Payment orchestration |
|---|---|---|
| The question | Where should this payment go? | How do we run several providers as one? |
| Scope | One decision per payment | Connections, credentials, events, retries, reporting and routing |
| Inputs | Payment details, coverage, contract prices, reliability, preference | Everything routing uses, plus provider configuration and your systems' events |
| Output | A provider, expected cost and time, fallbacks and reasons | One integration and one view across providers |
| When you need it | Two or more providers can carry the same payment | You run several providers and don't want each one wired into your stack |
What to look for when you add a second provider
Before you pick a tool for a second provider, or decide to build one, ask these six questions:
- Does it hold or move funds? A tool that holds funds sits in your money flow. Holding funds is regulated in its own right.
- Where do your credentials live? Some vendors store your provider keys. Others read them from your own secrets manager when they need them.
- What does it see about your customers? Find out whether routing can work from masked metadata or needs names and account numbers.
- Do decisions show their reasons? When a payment goes to one provider, you should be able to see why, including the options it ruled out.
- Does it price under your contracts? The cost that matters is your negotiated price. Volume tiers can change the cheapest option during the month.
- How would you leave? If you stop using the tool, your provider contracts and credentials should stay yours.
Where Unirail fits
Unirail is routing intelligence for apps that move money. It puts your providers' APIs behind one API, starting with Plaid, Yapily and Enable Banking. It also tracks your contracts with them, including fees, volume tiers and renewals. For every payment, bank link or identity check it returns the provider to use with its estimated cost, ETA, success likelihood and reasons. In Execute mode Unirail reads the credentials from your own vault for each call and holds them in memory only. Your providers and your platform keep their licences and contracts.
In Decide mode it receives masked metadata only and your backend calls the provider itself. The decision engine can also run in your own infrastructure, by arrangement. How Unirail works follows a decision from request to outcome.