Processor Concentration Risk: How Much of Your Revenue Runs Through One PSP?

It's worth being precise about why, because "don't put all your eggs in one basket" is not the argument. Concentration is often a rational choice: one provider means one integration, one reconciliation, one negotiation. The risk isn't using one processor. The risk is not knowing what depends on it, which is why concentration is usually the first thing a payment resilience assessment measures.

The four layers of concentration

Concentration hides at more layers than most teams check:

Provider concentration. The obvious one: what percentage of gross revenue is processed by your largest PSP?

Account concentration. Subtler: multiple products or entities running through one merchant account share one risk profile. Account-level actions (reserves, restrictions, terminations) hit everything at once, and processors can take them with limited notice.

Token concentration. For recurring revenue, this is usually the deepest layer. If stored credentials live in one processor's vault, your ability to charge existing customers is locked to that provider regardless of how many others you've integrated. Migration is possible but slow. Weeks at best, and never mid-incident.

Flow concentration. A single webhook consumer, queue, or reconciliation job that all payment events pass through is a concentration point that appears on no vendor dashboard.

How to measure it

The provider layer takes an afternoon: attribute last quarter's revenue to the processor that carried it, and compute your largest provider's share. Then do the harder passes: share of recurring revenue whose tokens are vaulted with that provider (renewal exposure), share flowing through your largest single merchant account (account exposure), and the count of processing-critical components with no redundant path (flow exposure).

Express the result in currency, not percentages - "84% of MRR" lands differently than "£412k a month exposed across three critical paths." Revenue framing is what gets remediation prioritized. Then treat it as a living number: every new product, provider, or vault decision moves it. This continuous, revenue-weighted mapping is the core of what PayRes measures, and concentration is typically the first finding a new map surfaces.

What actually goes wrong

Concentration converts three ordinary events into revenue incidents:

Outages. Rare per-provider, near-certain across a stack over time: Stripe's failover resource cites survey data showing 92% of enterprise e-commerce businesses hit payment disruptions within two years. With full concentration, provider downtime equals company downtime.

Account actions. Risk teams freeze funds and restrict accounts unilaterally. For a concentrated business this is an existential event, and it arrives with far less warning than an outage.

Forced migrations. Pricing changes, policy changes, deprecations, or a vendor exiting your segment. Concentration turns "we should switch" into a multi-quarter program executed under pressure.

The regulatory angle: DORA Article 29

If you're an EU financial entity (or sell to them) concentration risk is no longer just prudent, it's codified. The Digital Operational Resilience Act, applicable since January 17, 2025, requires financial entities to manage ICT third-party risk (Articles 28-30), including a preliminary assessment of ICT concentration risk at entity level (Article 29), a register of ICT providers, exit strategies for critical providers, and it explicitly covers operational and security payment-related incidents (Article 23). Supervisory guidance extends the concern to fourth parties. Your providers' providers. For regulated readers, the measurement exercise above isn't optional homework; it's the evidence base your register and exit strategies are supposed to stand on.

Even outside DORA's scope, its logic travels: enterprise customers increasingly ask vendors resilience questions in procurement, and "we've quantified and mitigated our processor concentration" is becoming a due-diligence answer worth having.

Reducing concentration without multiplying chaos

Adding a second processor is one lever, and not automatically the right first one. We've written a full decision framework on it. Options in rough order of cost:

1. Map and monitor. Know the number; alert when it drifts. Cost: near zero.
2. De-risk tokens. Evaluate network tokens or processor-agnostic vaulting so credentials aren't captive, even before adding a provider.
3. Split accounts deliberately. Separate merchant accounts along product or entity lines to contain account-level actions.
4. Add a provider with a validated path. If you do add a PSP, budget for testing the failover, not just building it. An untested backup reduces the number on paper only.
5. Document the exit. DORA's exit-strategy requirement is good practice for everyone: know, in writing, how you'd leave your largest provider.

The one-line takeaway

You can't manage a dependency you haven't measured. Calculate the share of revenue riding on your largest provider, account and vault this quarter, then decide what number you're comfortable with. PayRes produces that map and keeps it current from a read-only connection.