Circuit Breaker Pattern is a software design pattern that stops a system from calling an external dependency, such as an acquirer API, a KYC vendor or a core banking service, once it has failed repeatedly, and lets traffic through again only after a test call succeeds. The breaker moves between closed, open and half-open states: failures are counted until a threshold trips it, calls then fail immediately, and after a timeout a trial call decides whether it closes. Without one, a single slow provider exhausts shared resources and takes unrelated features down. Retries belong inside the breaker. Under DORA, such controls help decide whether a vendor outage stays degraded service or becomes a reportable incident.
How does a circuit breaker work
The breaker wraps every call to the dependency and moves between three states. In the closed state, calls pass through and failures are counted; a success resets the count. When failures reach the trip threshold, the breaker opens: every call fails immediately without reaching the dependency and returns an error or a fallback. After a reset timeout, the breaker goes half-open and lets a trial call through. If it succeeds, the breaker closes; if it fails, it opens again and the timer restarts.
Production systems usually trip on a failure rate over a sliding window rather than a raw count, for example 50% of the last 100 calls, with a minimum call volume so that two failures out of three calls at 3 a.m. do not cut off a provider. Slow responses can count as failures too, since a dependency answering in 25 seconds is functionally down for a checkout.
Why payment systems need circuit breakers
Without a breaker, one slow provider takes everything down with it. Illustrative example: a platform sends 50 payments a second to an acquirer whose API starts hanging until a 30-second timeout. Within 30 seconds, 1,500 requests are waiting, the thread pool is exhausted, and unrelated features such as refunds and balance checks fail because they share the pool. With a breaker set to trip at 50% failures over 10 seconds, the platform stops calling the acquirer after a few hundred failed attempts, answers in milliseconds, and the routing layer sends new payments to a backup acquirer through failover.
The breaker also protects the struggling provider. If thousands of clients keep calling with retries, a provider that could recover in a minute stays overloaded for an hour.
Circuit breaker vs retry
Retry logic handles brief, transient errors: a dropped connection, a one-off server error. A circuit breaker handles persistent failure. Retries should run inside the breaker so that each retry counts towards the failure rate; retries outside it multiply load on a provider that is already failing. For payments, a timed-out request may have succeeded at the provider, so the system checks status or relies on an idempotency key before sending the same payment elsewhere.
Circuit breakers, resilience rules and due diligence
The EU Digital Operational Resilience Act (DORA), applicable since 17 January 2025, requires financial entities to report major ICT-related incidents and, for ICT services supporting critical or important functions, to keep documented and tested exit strategies. DORA does not name circuit breakers, but they are one of the code-level controls that decide whether a vendor outage stays a degraded service or becomes a reportable incident. In technical due diligence on a payments platform, breaker configuration per provider and the history of trips show whether one vendor can take the whole platform offline.