What a payment orchestrator actually does

A payment orchestrator is software that sits between your business and multiple payment processors, banks, and gateways. Instead of building separate connections to each one, you connect once to the orchestrator, and it routes each transaction to whichever processor gives you the best outcome for that specific payment.

The orchestrator decides the routing based on rules you set: lowest fee for this card type, fastest settlement for this currency, highest approval rate for this region. When a customer's card declines at your first processor, the orchestrator can automatically retry it at a second one without the customer knowing. It collects transaction data from all your processors into one dashboard and one reconciliation file instead of ten separate ones.

This is different from a payment gateway, which connects you to one processor. It is also different from a payment processor, which actually moves the money. An orchestrator is the traffic controller between you and all of them.

Key Takeaways

  • Payment orchestrators reduce declined transactions by retrying failed cards across multiple processors, which directly increases your revenue.
  • The cost of an orchestrator is usually a per-transaction fee (often $0.01 to $0.05 per transaction) plus a percentage, and you should compare this against the fees you currently pay across all your processors combined.
  • Routing rules matter more than processor count—an orchestrator with three processors you can configure beats one with ten that you cannot customize.
  • Integration complexity depends on your current setup; moving from one processor to an orchestrator takes weeks, but moving from multiple processors can take months.
  • Reconciliation and reporting are the biggest operational wins, because they eliminate manual work matching transactions across multiple bank statements and processor dashboards.

Understand what problem you are actually solving

Before you look at any orchestrator, know why you need one. The answer is not "because it exists." The real reasons fall into three categories: you are losing money to declined transactions, you are paying too much in processor fees, or you are drowning in reconciliation work.

If your decline rate is above 2 percent, an orchestrator with retry logic across multiple processors will recover 10 to 30 percent of those declined transactions—that is real revenue. If you are already using one processor and your decline rate is low, an orchestrator may not be worth the integration cost.

If you process in multiple currencies or regions, or if you have negotiated different rates with different processors, an orchestrator can route transactions to the cheapest option for each one. If you use only one processor at one rate, you are not saving money by adding an orchestrator.

If you currently log into three separate processor dashboards, read three separate settlement files, and manually match them to your accounting system, an orchestrator will consolidate that into one. If you already have one processor and one dashboard, the time savings are minimal.

Compare what each orchestrator actually connects to

Orchestrators advertise the number of processors they support—"connect to 50+ processors"—but what matters is which ones you actually use or want to use. A processor you do not use is worthless to you.

Make a list of the processors you currently use, plus any you have considered or negotiated rates with. Then check whether each orchestrator candidate connects to those specific ones. Some orchestrators are strong in North America but weak in Europe. Some connect to Stripe and Square but not to regional processors. Some require you to sign a separate contract with each processor, which defeats the purpose.

Ask each orchestrator: if I want to add a new processor later, how long does that take? Some add new connections in weeks. Others take months or require you to wait for a quarterly release. If your business grows and you need a processor you do not currently use, a slow integration timeline becomes a real constraint.

Evaluate routing rules and retry logic

The core value of an orchestrator is its ability to route transactions intelligently and retry failed ones. Not all orchestrators do this equally. Some let you set detailed rules; others offer only basic options.

Ask what rules you can configure. Can you route by card type (Visa, Mastercard, Amex)? By card region? By transaction amount? By customer geography? By processor success rate? The more granular the rules, the more precisely you can optimize. Some orchestrators also let you set rules based on real-time processor performance—if one processor's approval rate drops, the orchestrator automatically shifts traffic to another.

On retry logic: when a transaction fails, does the orchestrator retry it at a different processor automatically, or do you have to set that up manually? How many retries does it allow? How long does it wait between retries? Some orchestrators retry within seconds; others wait minutes. The timing matters because a customer's issuing bank may approve the same card at a different processor if the retry happens after a brief delay.

Calculate the actual cost, not just the headline rate

Orchestrators charge in different ways. Some charge a flat per-transaction fee ($0.01 to $0.05 per transaction). Some charge a percentage (0.1 to 0.5 percent). Some charge both. Some charge a monthly minimum. Some charge for retries as separate transactions.

To compare fairly, you need to know your current total payment processing cost. Add up what you pay across all your current processors—their per-transaction fees, their percentages, your monthly minimums, any gateway fees. Then calculate what you would pay with each orchestrator candidate, using your actual transaction volume and mix.

Do not forget to factor in the cost of integration. Most orchestrators require engineering work to connect—anywhere from two weeks to three months depending on your current setup. That is developer time and opportunity cost. If the orchestrator saves you $500 a month but costs $10,000 to integrate, you break even in 20 months. If it saves you $2,000 a month, you break even in five months. Both can be worth it, but you need to know which one you are looking at.

Check reporting, reconciliation, and data access

An orchestrator should give you one unified view of all your transactions across all your processors. That means one dashboard, one reporting interface, and one reconciliation file that you can feed into your accounting system.

Ask what data the orchestrator exposes. Can you read transaction-level detail? Can you filter by processor, by date, by amount, by customer? Can you export to CSV or connect via API? Can you see which processor handled each transaction, and why? Some orchestrators hide processor-level detail, which makes troubleshooting harder.

On reconciliation: does the orchestrator provide a file that matches your bank settlement? Does it handle partial refunds, chargebacks, and disputes across multiple processors? Does it reconcile automatically, or do you still have to match things manually? The better the reconciliation, the less time your finance team spends on payment accounting.

Assess integration effort and timeline

Integration complexity depends on your current setup. If you are moving from one processor to an orchestrator, you are essentially swapping one API for another—usually four to eight weeks of work. If you are moving from multiple processors to an orchestrator, you are consolidating integrations, which can take three to four months because you have to test each processor connection and make sure your retry logic works correctly.

Ask the orchestrator for a technical specification document and a sample integration timeline. Ask whether they have worked with your current processors before. Ask whether they provide sample code or SDKs in your language. Ask whether they have a sandbox environment where you can test before going live.

Also ask about ongoing support. If a processor changes their API or a transaction fails in an unexpected way, does the orchestrator have a support team that can help you troubleshoot? Or are you on your own? Some orchestrators have strong technical support; others expect you to figure it out.

Frequently Asked Questions

Do I need an orchestrator if I only use one payment processor?

Probably not. An orchestrator's main value is routing across multiple processors and retrying failed transactions. If you use one processor and your decline rate is below 2 percent, the integration cost will likely outweigh the benefit. Revisit this decision if your decline rate rises or if you add a second processor.

Can an orchestrator reduce my payment processing fees?

Yes, if you have negotiated different rates with different processors and can route transactions to the cheapest one for each type. It can also recover revenue from declined transactions that would otherwise be lost. But the orchestrator itself charges a fee, so you need to calculate whether the savings exceed the orchestrator's cost.

What happens to my customer data when I use an orchestrator?

The orchestrator sees transaction data but typically does not store card numbers—those stay with your processor or payment gateway. You should review the orchestrator's privacy policy and data handling practices, and confirm that they are PCI compliant. Ask whether they store transaction history and for how long.

How long does it take to switch from my current processor to an orchestrator?

If you are moving from one processor, expect four to eight weeks of development and testing. If you are moving from multiple processors, expect three to four months because you have to integrate each processor connection and test your routing rules. The orchestrator should provide a detailed timeline during your evaluation.

What if the orchestrator goes out of business?

You would need to reconnect directly to your processors or move to a different orchestrator. This is why you should ask about the orchestrator's financial stability, funding, and customer base. You should also confirm that your processor connections are portable—that you can move to a different orchestrator without renegotiating with each processor.