Case studies

How a PSP Contained an Acquirer Failure in Seconds — Before It Became a System Outage

Low-risk · Platform stability · Proactive monitoring • April 2026

Seconds Time to isolate Acquirer disabled via the interface, no engineering sprint

0 Downtime Traffic redirected through other channels

0 Merchants affected The failing acquirer stayed a local issue

At a glance

Client: A low-risk PSP processing high transaction volumes across e-commerce and financial services merchants
Challenge: One acquirer degrading: response time 30 s+, queues growing, failover slowing down — an outage could reach every merchant
Solution: Proactive monitoring + acquirer isolation via the platform interface
Result: Issue detected and isolated in seconds — zero system outage, zero client ticket required

Segment: Low-risk PSP
Trigger: Response time 30s+
Detected by: eComCharge support monitors

Solution used

Smart Routing

Case study 03 · names protected by NDA

Case study 03

Challenge

One of the acquiring partners began experiencing severe performance degradation — response times increased to 30 seconds or more.

This created a cascading effect

Transaction queues started to build up

System resources became overloaded

Failover to alternative channels slowed down

Even a single unstable acquirer can affect the entire system if not isolated in time.

Case study 03

Solution

The eComCharge support team detected the degradation directly on platform monitors — without waiting for the client to raise a ticket.

Once confirmed, the acquirer was isolated through the interface in a matter of seconds.

Depending on the situation, the team applies one of two approaches

Acquirer is slow but alive

Increase queue depth to handle more parallel requests — the partner continues processing while the load is managed.

Acquirer is unresponsive

Disable it completely and redirect traffic to stable channels immediately.

This decision is made by the support team in real time, with the option to involve an on-call engineer for confirmation.

Proactive detection — real-time isolation

The support team sees the problem on monitors before the client notices — and acts immediately

Without isolation

✕Slow acquirer keeps receiving traffic — queues grow uncontrollably
✕System resources exhausted — platform-wide performance degrades
✕Failover becomes less effective — merchants start seeing failures

With isolation

✓Problem detected on support monitors — before client escalation
✓Acquirer disabled via interface in seconds — traffic redirected instantly
✓System stays stable — local issue stays local

Step 1 Support monitors detect slowdown Response time and queue depth visible in real time

Step 2 Decision: slow or dead? Slow → increase queue depth. Unresponsive → disable completely On-call engineer if needed

Step 3 Isolation via interface Takes a few seconds. Traffic continues through stable channels. No client action required

Case study 03

What changed

Instead of allowing a single failing partner to degrade the entire system, the issue was contained at the source. Traffic continued to flow through other available channels without creating system-wide bottlenecks.

A local issue stayed local.

Case study 03

Result

The PSP

Had the issue detected by the eComCharge support team — proactively, before escalation

Isolated the underperforming acquirer in seconds via the platform interface

Avoided system overload and potential downtime

Maintained transaction flow throughout the incident

Reduced pressure on its own technical and support teams

When it matters

When acquirer isolation becomes critical

This capability matters when

An acquiring partner starts responding slowly or becomes unstable

Transaction queues begin to grow

Failover between channels becomes less effective

System performance depends on external providers

In practice, PSPs use this to

Temporarily disable unstable acquirers without stopping the entire system

Protect core traffic by redirecting to stable channels

Prevent technical incidents from turning into business outages

Single acquirer

What if you only have one acquirer?

This scenario is more common than it seems. Even when a PSP operates with a single acquiring partner, isolating that partner can still be the right decision.

Continuing to send traffic to a slow or unresponsive acquirer can overload the system — queues grow uncontrollably, and platform-wide performance degrades.

Temporarily disabling the acquirer helps

Protect system stability

Prevent resource exhaustion

Buy time to resolve the issue without escalating the incident

In one real case, the PSP had only one active acquiring partner at the time. Disabling it did not stop the business — it prevented the entire system from becoming unresponsive.

Results

Low-risk PSP · High transaction volume · Acquirer degradation incident

Seconds

Time to isolate

Acquirer disabled via the interface — no engineering sprint required

✓ Proactive

Detected by eComCharge

Support monitors flagged the issue before the client reported it

0 downtime

No system outage

Transaction flow maintained throughout the incident

✓ Contained

Local issue stayed local

One failing acquirer did not affect the rest of the platform

The support team doesn't wait for a client ticket. Response time and slowdowns are visible on eComCharge monitors — and when action is needed, isolation takes seconds, not minutes.

Want to discuss a similar setup for your platform?

Talk to us