Payment Orchestration: Multi-PSP Routing and Failover

Payment orchestration is the layer between your billing system and payment processors that decides which processor handles each transaction, routes retries when a charge fails, and switches traffic when a processor goes down. According to Stripe's own data, average payment acceptance rates across all industries sit at 85–90%, meaning 10–15% of attempted charges fail for reasons unrelated to insufficient funds — network errors, processor outages, card issuer quirks — that a different processor might have accepted [1]. For SaaS companies processing significant monthly volume, closing even half that gap translates directly to recovered MRR. This guide covers how payment orchestration works, when to add a second processor, how to design routing rules, and how to manage reconciliation across multiple payment service providers (PSPs).

What Is Payment Orchestration?

Payment orchestration is the logic that sits above individual payment processors and makes routing decisions in real time. A basic orchestration layer handles three jobs: primary routing (which PSP should handle this transaction by default), fallback routing (which PSP to try if the primary declines or errors), and retry logic (when and how often to retry a failed charge before marking it as failed). More advanced orchestration adds rules based on geography (route European cards to a European acquirer), card network (route Amex to a processor with better Amex rates), transaction size, or customer tier. Payment orchestration is distinct from a payment gateway — a gateway is one connection to one processor; orchestration manages multiple gateways simultaneously.

Why Do Companies Add a Second Payment Processor?

The primary reasons to add a second PSP are: acceptance rate improvement, geographic coverage, cost reduction, and resilience. Acceptance rates vary by processor because each has different relationships with card-issuing banks and different fraud models. A transaction declined by one processor is accepted by another 20–40% of the time when routed intelligently [2]. Geographic coverage matters because local acquirers typically achieve 5–15% higher acceptance rates on domestic transactions than global acquirers processing cross-border. Cost reduction comes from routing transactions to the cheapest processor for each card type — interchange-plus pricing means effective rates vary significantly by card network and issuer country. Resilience is straightforward: if your single processor has an outage (all major processors have had them), you lose revenue; with two processors, you route around the problem.

How Does Smart Payment Routing Work?

Smart routing uses a rule set evaluated at the moment of charge to select the best processor for each transaction. Rules are evaluated in priority order, and the first matching rule wins. A simple rule set looks like: (1) if card BIN is European, route to Adyen; (2) if transaction currency is GBP, route to GoCardless for BACS Direct Debit; (3) if customer is on enterprise plan and transaction is over $5,000, route to primary processor with 3DS2 disabled; (4) default to Stripe for all other transactions. More sophisticated routing uses ML models trained on historical acceptance data by BIN range, time of day, card type, and customer profile to predict which processor maximizes the probability of acceptance for each specific transaction. The routing layer must make its decision in under 100ms to avoid adding perceptible latency to checkout.

What Is Waterfall Routing and When Should You Use It?

Waterfall routing automatically retries a failed transaction on a secondary processor without customer intervention. When processor A declines or errors on a charge, the orchestration layer immediately attempts the same charge on processor B. From the customer's perspective, they see nothing — the charge either succeeds or fails, and the routing is invisible. Waterfall routing is most effective for soft declines (generic decline codes where the issuer didn't definitively reject the card) and processor errors (timeouts, connectivity failures). It is less effective for hard declines (stolen card, closed account) because the decline is the issuer's decision and a different processor will get the same result. Implementing waterfall routing well requires mapping each processor's decline codes to a classification (hard vs. soft vs. error) so your routing layer knows when to cascade. IXOPAY's 2024 payment benchmarks found that cascading fallback routing recovers 15–22% of soft-declined transactions that would otherwise be lost [2].

Which Payment Processors Should You Connect?

The right processor mix depends on where your customers are and what payment methods they use. For global SaaS companies, Stripe is a common primary for card processing due to its developer experience and global reach. Adyen is a strong complement for European and enterprise customers — it has superior acceptance rates with European issuers and supports local payment methods (SEPA Direct Debit, iDEAL, Bancontact) natively. GoCardless is the leading option for UK and European bank debit (BACS, SEPA), which is common for enterprise B2B contracts where customers prefer invoice-triggered bank pulls over card charges. Open-source billing platforms like Lago integrate natively with Stripe, Adyen, and GoCardless, enabling multi-PSP routing without building custom integrations for each processor. For the Asia-Pacific market, regional processors (Razorpay in India, Checkout.com for broader Asia) outperform global processors on domestic transactions.

How Do You Handle Processor Failover During an Outage?

Processor failover is the automated switch from a primary PSP to a secondary when the primary becomes unavailable. Your orchestration layer should monitor processor health continuously — checking response times and error rates on a rolling 60-second window. When error rates exceed a threshold (typically 5–10% of requests failing with 5xx errors or timeouts), automatically shift new transactions to the secondary processor. The failover decision should be fast (under 30 seconds from detecting the problem to rerouting) and the return to primary automatic when health recovers. Critically, failover must not double-charge customers: if a charge was submitted to the primary and the response timed out (ambiguous outcome), mark it as pending and check the processor's status API before retrying on the secondary. A timeout does not mean failure — retrying without confirming can result in two successful charges. Log every failover event with timestamps, error codes, and transaction IDs for reconciliation.

What Are the Most Common Payment Routing Mistakes?

The most common mistake is routing by geography alone without considering card BIN data. A UK cardholder living abroad, or a company headquartered in Germany with a US-issued corporate card, will not benefit from routing to a European acquirer — the issuer bank is still American. Route by card BIN prefix, not customer billing address. The second common mistake is not classifying decline codes before cascading. Routing a hard decline to a second processor wastes a transaction attempt, adds latency, and may trigger additional fraud signals with the issuer. Third, teams often build retry logic without idempotency: the same payment intent is submitted twice, and if the first charge succeeds after a delay, the customer is double-charged. Use processor-generated idempotency keys on every request. Fourth, companies neglect to test failover paths in production — failover scenarios discovered during an actual outage are far more costly than those found in pre-production testing. Schedule regular failover drills.

How Does Multi-PSP Reconciliation Work?

Reconciliation across multiple processors is significantly more complex than with a single PSP. Each processor has its own settlement timeline (Stripe settles in 2 business days; Adyen settlement timing varies by country and contract), its own payout currency, its own fee structure, and its own dispute and refund timelines. Your reconciliation process must: pull settlement reports from each processor daily, match each settled amount to the original charge in your billing system, account for processor fees, currency conversion losses, and chargebacks, and flag any discrepancies for manual review. Build your reconciliation pipeline to be processor-agnostic — a common data model that normalizes charge IDs, amounts, currencies, and statuses from each processor into a single format. For the underlying billing audit trail that feeds reconciliation, see how immutable billing logs support accurate revenue reconciliation. Reconciliation errors compound across processors — a fee classification error with one processor will repeat for every transaction routed there, so catch and fix them early.

How Should You Handle Payment Method Diversity Across Processors?

Different payment methods are supported by different processors, and your orchestration layer must route to the processor that supports the requested method. Bank debits (ACH in the US, BACS in the UK, SEPA in Europe) are only available through processors with the relevant banking scheme connectivity — Stripe supports ACH and SEPA, GoCardless specializes in BACS and SEPA, Adyen supports most schemes globally. Credit and debit card routing is more flexible because most processors support all major card networks. Routing rules for payment method should take precedence over geography rules: if a customer pays via SEPA Direct Debit, always route to a SEPA-capable processor regardless of other criteria. Your billing system must store the payment method type alongside the customer's payment token and pass it to the orchestration layer at charge time. Open-source billing platforms like Lago store payment method metadata per customer and per subscription, making method-aware routing straightforward to implement. For how real-time subscription events flow through to payment triggers, see how event-driven billing architecture handles subscription payment initiation.

What Metrics Should You Track in a Multi-PSP Setup?

The core metrics for payment orchestration are: overall authorization rate (successful charges / attempted charges, across all processors), authorization rate per processor per card type (to identify where each processor is underperforming), fallback rate (% of transactions that cascaded to a secondary processor), fallback success rate (% of cascaded transactions that succeeded on the secondary), processor latency (p50 and p99 response times per processor), and settlement timing variance (how consistently each processor settles on schedule). Track these metrics daily and set alerting thresholds: if overall authorization rate drops below your 30-day average by more than 3 percentage points, investigate immediately. Authorization rate drops are early signals of processor issues, fraud model changes, or card scheme updates. Segment all metrics by card network, BIN country, plan tier, and transaction amount — authorization rates vary significantly across these dimensions and aggregate metrics hide the signals that matter.

When Does Payment Orchestration Become Worth the Complexity?

Payment orchestration adds engineering complexity and operational overhead. For most SaaS companies below $1M MRR processing primarily card payments from a single geography, a single well-configured processor with smart dunning is sufficient — the acceptance rate gains from multi-PSP routing do not justify the reconciliation and engineering cost. The inflection point is typically around $2–5M MRR, when the dollar value of recovered soft declines and processor resilience exceeds the cost of building and maintaining the orchestration layer. Geographic expansion is the other common trigger: the moment you have significant customer volume in a second region where a different processor achieves meaningfully better acceptance rates, multi-PSP becomes economically obvious. Build orchestration incrementally: start with a secondary processor for fallback only, measure the recovery rate, then add routing rules as you learn where your primary processor underperforms.

Citations

1. Stripe, "Global Payment Authorization Rates," 2024 data. Average authorization rates across industries: 85–90%; gap attributable to non-fraud soft declines and processor network errors.
2. IXOPAY, "Payment Cascading and Acceptance Rate Benchmarks," 2024. Cascading fallback routing recovers 15–22% of soft-declined transactions; transactions declined by one processor accepted by an alternative processor 20–40% of the time when routed intelligently.
3. Adyen, "Interchange and Authorization Rate Data by Region," 2024. Local acquirers achieve 5–15% higher acceptance rates on domestic transactions versus global cross-border processing.
4. Spreedly, "State of Payment Orchestration 2024." Companies processing over $5M annually with multi-PSP setups report average 2.3 percentage point improvement in overall authorization rates versus single-processor setups.
5. GoCardless, "Direct Debit vs. Card for B2B SaaS," 2024. Bank debit chargeback rates are 97% lower than card chargebacks; B2B enterprise customers on direct debit have 23% lower involuntary churn than card-paying equivalents.