What Happens When a Third-Party API Stops Working?
A well-designed integration detects the outage, queues the affected work instead of losing or duplicating it, retries within set limits rather than endlessly, and reconciles once the provider recovers. Without that design in place beforehand, an outage in a payment gateway or messaging provider can silently stall orders or double-charge customers on recovery.
Detect Outages and Distinguish Authentication From Provider Failures
Imagine an online marketplace seller during a festive sale, when the payment gateway they depend on has an outage right at peak traffic. The first practical challenge is telling the difference between two very different problems that can look identical from inside the business's own system: the provider itself being down, versus the business's own credentials or configuration having failed.
This distinction matters because the response is different — a provider outage needs queueing and retries, while an authentication failure needs someone to fix a credential immediately, and treating one as the other wastes time that matters most during a peak-traffic event.
Queue Work and Avoid Duplicate Execution
When the gateway is unreachable, the checkout attempt shouldn't simply fail and disappear — it should be held in a queue, marked as pending, so it can be retried automatically once the provider is back, without the customer needing to start over and risk being charged twice if the original attempt actually went through moments before the failure was detected.
This queueing has to be built with the same duplicate-prevention logic covered elsewhere on this site — a unique reference per attempt, checked before any retry executes — because an outage is exactly the scenario where duplicate charges or duplicate orders are most likely to slip through if that check isn't in place.
Use Bounded Retries and Communicate Degraded Service
Retrying a failed request makes sense, but only within limits — a fixed number of attempts with increasing delay between them, not an endless loop that keeps hammering a provider that's already struggling, or that leaves a customer's checkout hanging indefinitely with no feedback.
Customer-facing communication matters just as much as the technical retry logic. A clear message — 'payments are temporarily delayed, we'll confirm shortly' rather than a generic error — reduces the number of customers who assume the transaction failed and try again through a different method, which is itself a common source of accidental duplicate payments during an outage.
Reconcile After Recovery and Review Missed Events
Once the provider is back, every queued item needs to be processed and, just as importantly, checked against what actually happened on the provider's side during the outage — because some transactions may have completed on the provider's end even though the business's own system never received confirmation before the failure.
This reconciliation pass is where an outage either gets closed out cleanly or leaves a lingering mess — a customer charged whose order never fulfilled, or an order fulfilled that was never actually paid — and it deserves a deliberate review, not an assumption that the queue processing alone caught everything.
Plan Provider Changes and Continuity Alternatives
For a business where an outage in a single provider — a payment gateway, a messaging API, a courier's tracking feed — genuinely stops operations, it's worth evaluating whether a backup provider for the same function is worth the added complexity, particularly for a business whose peak sale events are exactly when an outage is most damaging.
This isn't necessary for every integration; a low-stakes, low-frequency connection rarely justifies the cost of a second provider. But for anything on the critical path of taking a customer's money or confirming their order, the question is worth asking deliberately, rather than only after a real outage has already caused damage.
Outage-to-reconciliation flow
A flowchart from outage detection through queueing, bounded retry attempts with a customer-facing status message, provider recovery, and a final reconciliation step comparing the business's queued records against the provider's own transaction log to catch anything that completed on one side but not the other.
Frequently asked questions
Can operations continue during an outage?
Often yes, in a degraded form — orders can still be taken and queued even if a payment or messaging provider is temporarily down, as long as the system is built to hold and retry that work rather than fail outright. Full continuity depends on how central that specific provider is to completing the transaction.
How do we avoid duplicate transactions on recovery?
Check each queued item against a unique reference before processing it when the provider comes back, and reconcile against the provider's own record of what happened during the outage — some attempts may have actually succeeded on the provider's side even though your system never received confirmation.
Have a specific situation to work through?
This article covers the general case. Tell us what you're actually dealing with and we'll respond directly.