Every trading firm I have watched go through a payments crisis had the same architecture beforehand: one processor, one integration, one settlement account, and a founder who described payments as solved. The crisis is never the same twice. Sometimes it is an outage during the London session. Sometimes it is a risk review that ends the relationship. Sometimes the provider simply stops approving cards from the firm's best market. The response window is measured in days, and building a second integration under that pressure is the most expensive engineering anyone ever buys.
Concentration is the actual risk
Trading firms sit in a merchant category that acquirers treat as high risk, alongside the underwriting scrutiny and pricing that come with it. That classification changes the odds on every failure mode. Reviews are more frequent. Termination clauses are broader. Reserves are larger, and if you have not read the fine print on how a rolling reserve traps cash, that clause deserves an hour of your time before the next contract signature.
Beyond termination, three quieter concentration problems show up in the numbers long before anyone calls it a crisis. Approval rates differ sharply by issuing country, and no single provider is strong everywhere. Local methods matter more than card brands in several markets, and one provider rarely covers all of them. And settlement timing varies, so a firm on one provider has one cash cycle and no way to smooth it.
What the second provider actually buys
Redundancy is the headline, but the day-to-day value is comparison. With two live providers you can send the same traffic type down both routes and read the difference.
- Failover. When one route errors or times out, the checkout moves the customer to the other without a support ticket.
- Geographic routing. Send each country to whichever provider approves it best, which is measurable within weeks of running both.
- Method coverage. Cards through one, local bank transfers and wallets through another, crypto through a third if the client base wants it.
- Commercial position. A firm that can move traffic in a day negotiates differently from one that cannot move at all.
- Continuity during onboarding. Adding a fourth provider later is a routine project rather than an emergency, because the abstraction already exists.
The comparison only works if you can attribute outcomes correctly, which means one identifier per deposit attempt carried across providers and stored with the result. Without that, you have two providers and one opinion.
The cost side, stated honestly
Redundancy is not free and anyone selling it as pure upside is skipping the invoice. Each provider means a separate onboarding file, a separate KYB review, a separate reconciliation process, a separate chargeback workflow with its own deadlines and evidence format, and a separate settlement report to tie back to client ledgers. Support staff need to know which provider handled which deposit before they can answer a simple question about a missing payment.
There is also a real pricing effect: volume tiers reward concentration, so splitting traffic can cost basis points. That trade is usually worth taking, but only if you can see the full cost of each route rather than the headline rate, which is the argument for understanding the full anatomy of the merchant discount rate before comparing quotes.
Routing rules that retry hard declines are worse than no routing at all. Repeatedly hammering an issuer that already said no damages the firm's decline profile and can put the merchant account itself at risk.
Rules that hold up in production
Start with a static routing table rather than anything adaptive. Primary and secondary per country, per method, per currency. Simple rules are auditable and a support agent can explain them to a client. Add a cascade only for the response codes that justify it: issuer unavailable, timeout, generic decline. Never cascade on stolen card, closed account, or insufficient funds.
Cap retries hard, both per transaction and per card per day. Put a circuit breaker on each route so that a provider returning errors above a threshold is taken out of rotation automatically and a human is paged. Keep a manual override switch that a non-engineer can use at three in the morning, because the outage will not wait for a deployment. And make idempotency real: the same deposit attempt must never be captured twice because a retry crossed a delayed response.
Where this lives matters. Routing logic scattered across the checkout page, the CRM and a payment provider's own dashboard produces contradictory behaviour nobody can debug. Centralising it is the whole idea behind payment orchestration, whether you buy an orchestrator or build a thin routing layer inside your own broker CRM.
The numbers to run the strategy on
Four measurements, segmented by provider, country, method and card type. Approval rate on first attempt, because a deposit rescued by a cascade still cost you a customer's patience. Total cost per successful deposit including scheme fees, FX margin, reserve drag and chargeback handling, not the quoted percentage. Settlement lag from capture to available cash. Chargeback ratio by route, tracked against the thresholds your provider actually enforces.
Review them monthly and shift traffic on evidence. If one provider is thirty percent of volume and cannot be switched off without a code change, the strategy is not finished. The test of a multi-PSP setup is simple and worth running deliberately: turn off the largest provider for one hour on a quiet weekend and see what happens. Firms that pass that test sleep through the Tuesday email. The deeper mechanics of what moves the numbers are in our piece on approval rates.
"If you cannot switch off your biggest processor for an hour on a Sunday without a deploy, you do not have a payments strategy. You have a dependency."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Two live providers is the minimum for a high-risk merchant category; the second one is insurance and a benchmark.
- Cascade only on soft declines and cap retries, or the routing itself becomes an underwriting problem.
- Redundancy costs real money in reconciliation, KYB files and lost volume tiers. Budget it rather than discovering it.
- Judge each route on first-attempt approval, all-in cost per successful deposit, settlement lag and chargeback ratio.
Frequently Asked Questions
How many payment providers does a trading firm need?
Two live providers is the minimum that removes single point failure, and three is common once a firm sells into several regions with different local methods. Beyond that the reconciliation and compliance overhead usually outgrows the benefit, unless each additional provider is opening a market the others cannot reach at all.
What is cascading and when does it help?
Cascading means retrying a declined transaction through a second provider. It helps on soft declines such as issuer timeouts or generic do-not-honour responses, where a different acquiring route may be accepted. It does not help on hard declines like stolen card, closed account or insufficient funds, and retrying those damages the firm's decline profile with the issuer. Cascade only on the response codes that justify it, and cap the attempts.
Does running several PSPs weaken the pricing you get?
Usually the opposite. Providers price partly on volume, so splitting traffic can move a firm into a lower tier at each one. But a firm that can show live comparative approval rates and can shift traffic within a day is in a far stronger negotiating position than one that has nowhere else to go, and that position is worth more than a tier discount.