Single PSP risk: what happens when your only provider says no

Most merchants start with one payment provider, and for good reasons: one contract, one integration, one dashboard, one settlement file. The trouble is that the same simplicity becomes the biggest risk in the business once revenue depends on it. If that provider goes down, freezes the account, raises the reserve or declines more of your traffic, there is nowhere else for payments to go.

This article explains what can go wrong, what a second provider does and does not fix, and how to add one without building a second integration. It does not argue that every merchant needs five providers. It argues that every merchant should know what they would do on the day their only provider says no.

What is single-PSP risk?

Single-PSP risk is the exposure a business carries when all of its payments depend on one payment service provider or acquirer. Every failure at that provider, technical or commercial, becomes a failure of the whole business, and the provider’s view of your risk becomes the only view that matters.

The risk is not that providers are unreliable. It is that the merchant has no options when something changes, whether the cause is an outage, a compliance review or a pricing decision.

What can go wrong with a single provider?

Five things come up again and again. The table summarises them; the sections below explain each.

Risk	What happens	What reduces it
Outage	Payments fail until the provider recovers	Failover to a second provider; non-card methods for scheme outages
Account freeze or termination	Processing stops; funds may be held	A second, already-live relationship; clean chargeback and fraud ratios
Rolling reserve	Part of every payment is held back for weeks	Spreading volume; negotiating with an alternative in hand
Approval-rate ceiling	Declines you cannot route around	Local acquiring and routing by card country and issuer
Price leverage	Little room to negotiate fees	A credible, tested alternative

Outages

Every processor has incidents. Even card networks do: in June 2018, Visa suffered an eight-hour service disruption that hit card payments in the UK, which its European chief executive blamed on a partial degradation of its processing system rather than a cyber attack, according to PYMNTS. A second provider would not have helped with that particular incident, because it was the network itself. It does help with the more common case, where one provider’s gateway, acquiring connection or a specific method fails and the rest of the market keeps working.

Account freezes and terminations

A provider can pause or close a merchant account after a risk review, a spike in disputes or a compliance concern. When that happens, processing stops and funds may stay held while the review runs.

Termination can follow the business. Stripe’s documentation explains that Visa and Mastercard operate terminated merchant files, Mastercard’s MATCH and Visa’s VMSS, that acquirers must screen every applicant against them, and that listings remain active for five years. It adds that most processors automatically reject listed businesses or principal owners. Some reasons are quantitative: MATCH reason code 04, excessive chargebacks, applies when monthly Mastercard chargebacks exceed 1% of sales transactions and total USD 5,000 or more. A merchant with one provider and a bad month can lose more than one relationship.

Rolling reserves

A reserve is a temporary hold on part of the merchant’s funds. Stripe describes a rolling reserve as holding a set percentage of each new transaction for a set window, such as 30 days, and releasing it when the window ends. Its worked example uses 25% for 30 days. Reserves exist to cover future disputes and refunds, and providers set them according to how they see your risk.

Example figures, for illustration only. A merchant processing 1,000,000 euros a month under a 10% rolling reserve with a 90-day window has about 300,000 euros held at any time once the reserve is fully built. With one provider, that figure is whatever the provider decides, and an increase lands on cash flow immediately.

Approval-rate ceilings

Each acquirer has its own relationships with issuers, its own risk settings and its own coverage of local markets. Stripe’s guide on authorization rates notes that banks are often more likely to approve domestic payments, which is why locally optimised acquiring helps acceptance, and that businesses with high chargeback rates tend to see more declines. A provider that acquires cross-border in a market where a competitor acquires locally may have a lower ceiling there however well you integrate. With one provider, you cannot measure that gap, let alone close it.

Price leverage

When a provider knows you cannot leave, renegotiation is a formality. A second provider that already carries live traffic changes that conversation, because moving volume becomes a real option rather than a threat. We do not quote typical savings here, because they depend entirely on volume, vertical and markets.

How does a second provider reduce the risk?

A second provider turns single points of failure into choices:

• Outages become failover events: payments that time out or error at one provider go to the other.
• Freezes become partial: one account under review slows growth instead of stopping revenue.
• Reserves and pricing become negotiable, because volume can move.
• Approval rates become measurable, because the same segment can be compared across two providers.

It does not remove the underlying causes. A merchant with high chargebacks will be reviewed by both providers. A second provider buys time and choice; it does not replace good risk management.

Do you need a second integration to add a provider?

Not if the integration sits with an orchestration layer rather than with each provider. With orchestration, your systems integrate once, with one API, one transaction model and one webhook format. Adding a provider becomes configuration: credentials, eligibility rules and routing, rather than new code in your checkout and back office.

The hardest part to move later is stored card data. If saved cards live in your current provider’s vault, moving them requires that provider’s cooperation. Stripe’s documentation, for example, says it transfers card data only to a PCI DSS Level 1 processor, needs the receiving processor’s attestation of compliance or Visa registry listing, and has a standard timeline of 10 days after it receives valid data. That is workable, but it is not something to start on the day of a freeze. Tokenizing cards in an orchestrator’s vault from the start means both providers can be used for returning customers.

What should a backup PSP checklist include?

Use this list when adding a second provider:

1. Start underwriting early. Onboarding a new provider takes time, and high-risk categories take longer, because some merchant categories need extra checks by the acquirer and the card schemes.
2. Check coverage, not just pricing. Confirm countries, currencies, methods and payout support for your actual traffic, and whether it acquires locally in your largest markets.
3. Own your tokens. Store cards in a vault you control so both providers can charge returning customers.
4. Write eligibility rules. Define which payments each provider may receive by country, method, currency, amount, customer group and customer verification level.
5. Keep it warm. Send real traffic to the backup every day. A provider that receives nothing for months and then a sudden surge may treat the surge as a risk event, and you will not know whether the route works.
6. Define failover triggers. Decide which errors and timeouts move traffic, and keep issuer declines under separate cascading rules.
7. Normalise statuses and webhooks. Map each provider’s statuses to one model, credit customers only from the final webhook, and use idempotency keys so a failover cannot create a duplicate charge.
8. Plan reconciliation. Two providers mean two settlement files, two fee structures and possibly two reserves. Decide who reconciles them before launch.
9. Monitor each provider separately. Track approval rates by segment, error rates and chargeback ratios per provider, so you notice a slide before it becomes a review.
10. Write an exit plan. The European Banking Authority’s outsourcing guidelines expect payment institutions to have documented, tested exit plans for critical functions, with objectives, a business impact analysis, assigned roles, success criteria and indicators that trigger the exit. Merchants are not bound by them, but the structure works for anyone.
11. Test it. Switch a share of traffic deliberately and confirm that payments, refunds, payouts and webhooks all behave.

What are the trade-offs?

A second provider is not free. Expect another contract and due diligence process, possible minimum fees, volume split across two pricing tiers, and more reconciliation. Each provider monitors chargeback and fraud ratios on its own share of your traffic, so low volume at one provider can make its ratio jumpy. For some merchants, a well-managed single provider plus a documented plan is the right answer for now. The mistake is not choosing one provider; it is having no plan for the day it stops working.

How does Omno reduce single-PSP risk?

Omno puts one API in front of many payment providers for Pay-In and Pay-Out. Routing and PSP-eligibility rules decide which provider receives each payment. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. Cards are tokenized so they are not tied to one processor, and every decision is written to the routing-decision log, with final statuses delivered by webhook. The payment orchestration page shows how providers are added and configured.