"Payment orchestration" has become one of those buzzwords that vendors throw around without much precision. Everyone claims to offer it, few can explain what it actually means, and even fewer can articulate when it matters versus when it's overkill.
This guide is an attempt to bring clarity. We'll define the terms precisely, explain the technical architecture, and most importantly, help you determine whether orchestration is something your business actually needs—or whether you're being sold complexity you don't require.
First Principles: What is a Payment Gateway?
A payment gateway is the technical infrastructure that moves money from your customer's bank account to yours. When a customer enters their card details and clicks "Pay," the gateway handles the communication with card networks (Visa, Mastercard), issuing banks, and acquiring banks.
The key players in this process:
Acquiring Bank (Acquirer)
The bank that holds your merchant account. This is where the money lands before it hits your business bank account. Examples: Worldpay, First Data, Chase Paymentech.
Issuing Bank (Issuer)
Your customer's bank—the one that issued their card. When you charge a card, you're asking the issuing bank to authorize the transaction.
Card Networks
Visa, Mastercard, Amex, Discover. These are the rails that connect acquirers and issuers. They set interchange rates and processing rules.
Payment Processor/Gateway
The technology layer that orchestrates communication between all parties. Stripe, Adyen, Braintree, NMI—these are processors that provide the gateway infrastructure.
Modern processors like Stripe and Adyen are "full-stack"—they act as both the gateway (technology) and the acquirer (banking relationship). This simplifies setup but also means you're locked into their acquiring rates and their risk decisions.
What is Payment Orchestration?
Payment orchestration is an abstraction layer that sits above one or more payment processors. Instead of integrating directly with Stripe or Adyen, you integrate with the orchestration layer, which then routes transactions to the appropriate processor based on rules you define.
The orchestration layer makes decisions about:
Processor Selection
Which processor should handle this specific transaction? The decision might be based on card type, customer location, transaction amount, or historical performance data.
Failover Logic
If the primary processor declines or times out, should we retry on a different processor? With what parameters?
Token Management
Storing payment credentials in a processor-agnostic way, so you can charge the same card on different processors without the customer re-entering details.
Unified Reporting
Aggregating transaction data from multiple processors into a single view, with consistent formatting and terminology.
When Single-Gateway is Fine
Let's be honest: most businesses don't need payment orchestration. If you're doing under $5M/year in transaction volume, and your business is primarily domestic, a single processor like Stripe or Adyen will serve you well.
The advantages of single-gateway simplicity:
Simpler accounting
One payout schedule, one fee structure, one reconciliation process. Multi-processor setups create accounting complexity that requires dedicated resources.
Faster support resolution
When issues arise, you're dealing with one vendor. Multi-processor debugging often involves finger-pointing between providers.
Unified tooling
Stripe's dashboard, Radar fraud tools, and reporting are designed to work together. Orchestration layers often can't match the polish of native tooling.
If Stripe's approval rates, fees, and feature set work for your business, adding orchestration complexity doesn't make sense. Don't let vendors convince you that you need infrastructure you'll never use.
When Orchestration Becomes Necessary
There are specific scenarios where payment orchestration transitions from "nice to have" to "critical infrastructure":
International expansion with local acquiring. If you're selling to customers in Europe, APAC, and LATAM, local acquiring can significantly improve approval rates. A US-based Stripe account processing a German customer's card will see lower approval rates than a German acquirer processing that same card. Orchestration lets you route German cards to your German acquirer, US cards to your US acquirer, etc.
High-volume subscription businesses. When you're processing thousands of recurring charges daily, small differences in approval rates have material impact. A 2% improvement on $10M/month in rebills is $200K in recovered revenue annually. At this scale, multi-processor failover and intelligent retry logic pays for itself many times over.
Risk distribution requirements. If your business model attracts chargebacks (subscription boxes, nutraceuticals, etc.), you may need to spread volume across multiple MIDs to stay below network thresholds. Orchestration handles the routing logic to keep each MID healthy.
Negotiated rates with multiple processors. Large merchants negotiate custom rates with processors. You might have a better Visa rate with Processor A and a better Mastercard rate with Processor B. Orchestration routes each transaction to the lowest-cost option.
The Technical Architecture
Understanding the technical architecture helps you evaluate orchestration solutions and set realistic expectations. Here's what actually happens when a transaction flows through an orchestration layer:
1. Customer submits payment → Your checkout
2. Checkout sends card data → Orchestration layer
3. Orchestration tokenizes card → Vault storage
4. Orchestration evaluates routing rules
5. Primary processor selected → Transaction sent
6. If declined → Failover logic triggered
7. Response returned → Your checkout
8. Transaction logged → Unified reporting
The critical component is the network token vault. When you tokenize a card with Stripe, that token only works with Stripe. But an orchestration layer creates a processor-agnostic token that can be used across any connected processor. This is what enables true multi-processor routing without asking customers to re-enter cards.
Not all orchestration solutions implement this correctly. Some require the customer to re-tokenize when switching processors. Others have latency issues because they're making multiple API calls in sequence rather than intelligent, conditional routing.
Evaluating Orchestration Solutions
If you've determined that orchestration is right for your business, here's what to evaluate when selecting a solution:
Processor Coverage
Which processors are supported? Can you use your existing processor relationships, or do you need to establish new ones? How quickly can new processors be added?
Routing Flexibility
What rules can you define? Card type, geography, amount, time of day, custom metadata? Can rules be changed without engineering involvement?
Failover Intelligence
When a transaction fails, what happens? Simple retry on backup processor? Or intelligent retry based on decline reason code? (Hint: retrying a "stolen card" decline is pointless and costly.)
Latency Impact
Every layer adds latency. How much does the orchestration layer add? For checkout conversions, every 100ms matters.
Pricing Model
Per-transaction fee? Monthly platform fee? Does the cost make sense given your volume and the expected benefits?
How Tagada Approaches Payment Orchestration
At Tagada, payment orchestration is built into the core platform rather than bolted on as a separate layer. This architectural decision has important implications.
Because our checkout, subscription engine, and payment infrastructure share the same data layer, routing decisions can incorporate signals that standalone orchestration tools can't access. We know if this customer has churned before. We know their lifetime value. We know which products they're purchasing and their historical payment patterns.
This means routing rules can be more sophisticated: "Route high-LTV customers to our premium processor with better service. Route first-time customers through our fraud-optimized flow. Route subscription rebills through the processor with the best retry success rate for this card type."
We currently support Stripe, NMI, Adyen, Bridge, Airwallex, OceanPayment, and are continuously adding processors based on merchant demand. The routing logic runs at the edge with sub-50ms overhead.
Practical Recommendations
Based on our work with hundreds of merchants:
Under $5M annual revenue: Stick with a single full-stack processor (Stripe, Adyen). Focus on optimizing your checkout flow and reducing cart abandonment. Payment infrastructure isn't your bottleneck.
$5M-$20M annual revenue: Consider orchestration if you have specific pain points: international expansion, high decline rates on subscriptions, or processor concentration risk. Don't implement it just because you can.
Over $20M annual revenue: Orchestration should be part of your infrastructure. The revenue impact of improved approval rates and reduced fees justifies the complexity. At this scale, even small optimizations have meaningful dollar impact.
Conclusion
Payment orchestration is a powerful tool, but it's not universally necessary. The right question isn't "Should we have payment orchestration?" but rather "What specific problems would orchestration solve for us, and do those problems justify the added complexity?"
For businesses that genuinely need it—international merchants, high-volume subscription businesses, enterprises with complex processor relationships—orchestration is transformative. It can recover meaningful revenue, reduce fees, and provide resilience against processor issues.
For everyone else, it's overhead that distracts from more impactful work. Be honest about which category you're in.