Case studies

How a PSP Solved a Performance Crisis Without Doubling Its Infrastructure

Low-risk · SaaS · Dedicated infrastructure • April 2026

7 sec Processing time Back to normal, queue wait time eliminated

2 servers vs a 2–3× upgrade Only what was actually needed

Days Time to resolve Configured and deployed while the issue was active

At a glance

Client: A low-risk PSP working with e-commerce and financial services merchants, including several high-volume clients
Challenge: One large merchant's load pushed processing time up for everyone on the shared pool — a full infrastructure upgrade looked like the only way out
Solution: Dedicated server allocation for a high-volume merchant — 80/20 traffic split
Result: Processing time returned to normal · no infrastructure scaling required

Segment: Low-risk PSP
Platform: eComCharge SaaS
Timeline: Days

Solution used

Dedicated merchant infrastructure

Case study 04 · names protected by NDA

Case study 04

Context

The PSP operates on eComCharge's SaaS payment platform — a shared cloud environment where infrastructure resources are pooled across all tenants.

In a typical SaaS model, dedicated infrastructure per merchant is not an option. Resources are shared by default, and one client's load can affect everyone else on the platform.

eComCharge is one of the few SaaS payment platforms that allows PSPs to allocate dedicated infrastructure — both at the PSP level and at the individual merchant level — without leaving the shared environment or migrating to on-premise.

Case study 04

Challenge

A large merchant pushed significant traffic through the platform and consumed the majority of shared system resources. The result was complaints from two directions at once

The large merchant reported increased response times

Smaller merchants on the same platform started experiencing degradation too

The obvious fix would have been to scale up the entire PSP infrastructure by 2× or 3×. But that would have meant paying for resources that nobody else actually needed — all other merchants were performing fine before this happened.

The problem was not a lack of total capacity. It was a lack of isolation.

Case study 04

Solution

Instead of scaling everything, the eComCharge team allocated two dedicated servers specifically for the high-volume merchant — at a fraction of the cost of a full infrastructure upgrade.

Before and after: dedicated infrastructure

Two affordable dedicated servers solved what would otherwise have required doubling the entire infrastructure

Before

Shared pool — all merchants

Large merchantconsuming 80% of resources
Small merchant Adegraded ↓
Small merchant Bdegraded ↓
Small merchant Cdegraded ↓

After

Dedicated servers — large merchant only

Large merchant80% of traffic → dedicated

20% stays in the shared cluster

Shared pool — freed up

Small merchant Anormal ✓
Small merchant Bnormal ✓
Small merchant Cnormal ✓

Alternative: scale everything 2–3× Full infrastructure upgrade — expensive and unnecessary for the actual problem

What was actually done 2 servers Two dedicated servers for one merchant — problem solved within days at a fraction of the cost

The configuration is done manually: the eComCharge team assesses the merchant's traffic patterns and needs, then sets up the routing split accordingly. When the issue is already active, this is completed within days.

Case study 04

What changed

The large merchant stopped competing for shared resources. Smaller merchants immediately saw their performance return to normal. And the PSP avoided a costly infrastructure upgrade that would have been disproportionate to the actual problem.

Two affordable dedicated servers solved what would otherwise have required doubling the entire infrastructure. The solution was proportional to the actual problem.

Case study 04

Result

Transaction processing time returned to the normal 7 seconds — queue wait time eliminated

The high-volume merchant received guaranteed dedicated capacity

Smaller merchants stopped experiencing degradation

Problem resolved within days — without scaling the entire PSP instance

Case study 04

When this matters

This approach is relevant for any PSP — regardless of risk profile or vertical — when

A high-volume merchant starts affecting performance for others on the same platform

A PSP wants to offer performance guarantees to its largest or most demanding clients

Scaling the entire infrastructure would be disproportionately expensive

A merchant requires guaranteed throughput as part of their service agreement

The larger the portfolio and the more varied the merchant mix, the more likely this situation becomes.

In practice

How PSPs use this in practice

PSPs use dedicated infrastructure to

Isolate their largest or most demanding merchants from the shared environment

Guarantee transaction processing capacity without over-provisioning for everyone

Prevent one merchant's load from degrading the experience for others

Support enterprise-level service agreements with specific performance commitments

The allocation is configured manually by the eComCharge team — not a self-service feature, but a managed configuration that can be deployed quickly when needed.

Results

Low-risk PSP · eComCharge SaaS · Dedicated merchant infrastructure

7 sec

Processing time restored

Back to normal — queue wait time eliminated

2 servers

Instead of 2–3× upgrade

Proportional solution — only what was actually needed

✓ All merchants

Performance restored across the board

Large and small merchants both benefited

Days

Time to resolve

Configured and deployed quickly while the issue was active

The problem was not a lack of total capacity — it was a lack of isolation. eComCharge supports dedicated infrastructure per merchant within a shared SaaS environment — something most payment platforms do not offer.

Want to discuss a similar setup for your platform?

Talk to us