Payment Orchestration: When and How to Route Across Multiple PSPs

What Payment Orchestration Actually Means

Payment orchestration is the practice of routing transactions through multiple payment service providers based on rules, performance data, and business logic. Instead of being locked into a single PSP, you create an abstraction layer that can send each transaction to the optimal provider.

When You Need It (And When You Do Not)

You probably do not need orchestration if:

• You process less than 10,000 transactions per month
• You operate in a single market (e.g., Netherlands only)
• Your current PSP acceptance rate is above 95%
• You only accept cards and iDEAL

Orchestration starts making sense when:

• You expand across multiple European markets
• You need local payment methods per country (Bancontact, Przelewy24, Sofort)
• Authorization rates vary significantly by PSP and market
• PSP downtime directly impacts revenue
• You need to optimize processing costs across providers

Architecture Patterns

The Adapter Pattern

Create a common interface that each PSP implementation satisfies:

interface PaymentGateway {
    public function createPayment(PaymentRequest $request): PaymentResponse;
    public function getPayment(string $id): PaymentStatus;
    public function refund(string $id, int $amount): RefundResponse;
}

class MollieGateway implements PaymentGateway { /* ... */ }
class StripeGateway implements PaymentGateway { /* ... */ }
class AdyenGateway implements PaymentGateway { /* ... */ }

The Router

A router decides which gateway handles each transaction:

class PaymentRouter {
    public function route(PaymentRequest $request): PaymentGateway {
        // Country-based routing
        if ($request->country === 'NL' && $request->method === 'ideal') {
            return app(MollieGateway::class);
        }

        // Cost optimization
        if ($request->amount > 50000) {
            return $this->lowestCostProvider($request);
        }

        // Performance-based routing
        return $this->highestAcceptanceProvider($request);
    }
}

Failover Strategy

When a PSP returns an error or times out, automatically retry with a different provider:

class PaymentOrchestrator {
    public function process(PaymentRequest $request): PaymentResponse {
        $providers = $this->router->ranked($request);

        foreach ($providers as $provider) {
            try {
                $response = $provider->createPayment($request);
                if ($response->isSuccessful()) {
                    return $response;
                }
            } catch (GatewayTimeoutException $e) {
                $this->metrics->recordFailover($provider, $request);
                continue;
            }
        }

        throw new PaymentFailedException('All providers failed');
    }
}

Routing Strategies

Cost-based: Route to the cheapest PSP for each transaction type. Requires tracking per-transaction costs including interchange, scheme fees, and PSP markup.

Performance-based: Route to the PSP with the highest acceptance rate for the specific card type, country, and amount combination. Requires collecting and analyzing acceptance data.

Availability-based: Simple failover. Use primary PSP, switch to secondary when primary is down.

Market-based: Route to the PSP with the best local payment method coverage per country.

Data You Need to Collect

For effective orchestration, track per transaction:

• PSP used, payment method, card brand, issuing country
• Authorization result (approved, declined, error)
• Response time
• Processing cost
• Any failover attempts

Aggregate this data to build routing intelligence. Without it, you are guessing.

Start Simple

1. Begin with failover only. Primary PSP plus one backup. This alone prevents revenue loss during outages.
2. Add market-based routing. Route local payment methods to the PSP with best coverage.
3. Introduce cost optimization only when transaction volume justifies the complexity.
4. Performance-based routing requires months of data. Collect first, optimize later.

Payment orchestration is powerful but complex. Start with simple failover, add market-based routing when you expand across borders, and only invest in dynamic optimization when your transaction volume makes the engineering investment worthwhile.