An outage can cost a merchant orders, margin and trust. The strongest route to recovery is usually to recapture payments and reduce future downtime—not to assume the processor will reimburse hypothetical lost revenue.
Three different things are described as “recovering the loss”
When a payment gateway fails, a merchant may say it lost $20,000 in sales. That figure often mixes attempted checkout value, genuinely abandoned customer demand, delayed but completed payments, and orders customers will place later. Even if $20,000 were unrecovered revenue, the lost profit would usually be less after merchandise, fulfillment and other variable expenses. The sum a provider is legally required to reimburse may be smaller again, potentially zero under the relevant contract.
To evaluate an outage, separate operational recovery from financial recovery and legal compensation. Operational recovery means completing pending or abandoned customer orders, preventing duplicate charges and reconciling ambiguous payment states. Financial recovery means protecting contribution margin that otherwise would be forfeited. Contractual or insurance recovery is a potential payment from a third party under enforceable terms or a covered claim. These three measures should never be combined as if they were interchangeable.
The distinction is timely. Adyen’s public status service on October 23, 2026 displayed a continuing issue involving delays in certain Pix refund requests first identified October 21. That is not evidence that Adyen’s entire card-processing network was down. A refund-status problem can harm customer trust and working capital without preventing every new sale. Merchants should scope any incident by affected payment method, geography, transaction stage and timestamps before estimating damages.
Payment acceptance can fail in several places
An apparent checkout outage may start in the merchant application, payment gateway, processor, acquiring bank, card network, issuer, wallet provider, authentication service or web infrastructure. An order can even be authorized successfully while the confirmation callback is delayed, leaving a merchant’s system showing it as unpaid. That requires reconciliation, not an automatic second charge.
Dave Finances tracked a particularly instructive example when Xendit’s payout failure repeatedly returned after being marked resolved. The published sequence described different affected banks and transaction bands, plus repeated recovery attempts. It demonstrated why the question “Was the processor up?” can have several answers depending on the product and payment path. A merchant making an economic claim needs a reproducible incident window and transaction-level evidence.
A status-page availability percentage is not itself the merchant’s successful checkout rate. An API can remain reachable while issuing an elevated share of payment errors. Authorization can succeed while webhook delivery lags. Card transactions might remain healthy while mobile-money transfers fail, or only refunds and settlements might be affected. A reliable postmortem therefore includes latency, attempts, payment success, duplicate IDs, authentication outcomes, abandoned checkouts and delayed webhook confirmations.
This resembles the Telecel-related outages affecting Paystack and PawaPay reported on Dave Finances: the front-end brand receiving a complaint may depend on another provider’s rail. Responsibility for fixing the issue and liability for merchant lost sales may sit under different contracts.
Calculate genuinely lost orders instead of counting failed requests
Take an illustrative retailer expecting 120 orders per hour at a $65 average order value. A two-hour disruption covers 240 expected orders and $15,600 in sales opportunity. Assume 85% of expected orders require the impaired payment method: 204 orders are exposed. A contingency payment method immediately reroutes 20% of those exposed orders, recovering 40.8 expected orders. After service is restored, targeted re-engagement converts 25% of the remaining 163.2 exposed orders, recovering another 40.8. The permanently lost equivalent is therefore 122.4 orders, or $7,956 in revenue.
Suppose each fulfilled order contributes 40% of sales after the variable cost of goods, payment processing and delivery. On that contribution-margin assumption, the modeled permanent loss is $3,182.40 before incident-response costs. The gross $15,600 demand window, $7,956 permanently lost sales and $3,182.40 lost contribution are all valid different answers to different questions. None of them is a proven recoverable claim against a processor.
This is a cohort model, not an asserted empirical outage rate. The assumptions are explicitly chosen to illustrate the mechanisms. In a real business, customer demand during the outage should be estimated against comparable day-of-week and hour patterns, seasonality, promotion campaigns and stock availability. Merchants should subtract sales completed on alternate channels or after the outage, while identifying duplicate authorization attempts before treating them as separate customer demand.
Figure 1. Original outage loss waterfall: 204 exposed orders, 81.6 recovered, 122.4 lost.
What the contract actually says matters more than the status page
Stripe’s general Services Agreement was modified September 28, 2026. It states that the service is not guaranteed to be uninterrupted or error-free and, subject to applicable law and exceptions, excludes categories including lost revenue, profits and business interruption. Its general aggregate liability cap for applicable claims is tied to the fees the user paid Stripe, excluding third-party pass-through fees, in the preceding 12 months. Certain excluded-claim categories are treated differently, so a one-line summary of the cap is not a substitute for reading the full agreement and country-specific terms.
This makes a common assumption unsafe: a processor being technically responsible for an outage does not automatically make it liable for the merchant’s business losses. A provider might offer goodwill credits, negotiate a commercial concession, refund a particular incorrectly charged fee or pay under a bespoke service-level agreement. Whether that happens depends on the agreement, actual breach, evidence, caps, exclusions, jurisdiction and any mandatory protections that cannot legally be waived.
A numerical example shows the mismatch. If a shop pays $2,000 per month in qualifying processor fees, 12 months produces a $24,000 theoretical reference amount under a fee-based cap. That does not entitle the shop to $24,000—or to any particular sum. The actual loss must be established, the claim must satisfy the contract, and exclusions can remove even a provable lost-profit claim. Conversely, if a contract offers explicit service credits, the credit schedule and claim deadline may be far more useful than the general theoretical liability cap.
Merchants using multiple service providers also need to identify which party promised what. The platform selling checkout software may not be the same legal entity as the acquiring processor, issuer or local payment-method operator. The contract may allocate fault to the provider of the underlying service, or disclaim third-party interruptions. A claims team that cannot identify its contracting counterparty and service definition is unlikely to produce a convincing demand for consequential losses.
Operational recovery: preserve state before retrying
The fastest route to preventing permanent sales loss often starts with trustworthy payment-state reconciliation. Stripe’s PaymentIntents model recommends creating one PaymentIntent per order or customer session and provides states such as requires_payment_method, processing, requires_capture and succeeded. Those states do not all mean the same thing. A timed-out browser request is not proof that the card was not charged. A merchant that blindly creates a new charge for every timeout can turn an availability incident into a duplicate-payment incident.
Both Stripe and Adyen document idempotency mechanisms that let applications retry requests without creating the same payment twice under supported conditions. Idempotency keys and provider-specific windows matter, as do webhooks and later reconciliation. An engineering team should first determine whether a particular payment exists under its original unique order ID, then repair the existing transaction where possible or request customer consent before a fresh charge.
In Adyen’s hosted checkout model, payment errors can return shoppers to checkout for another attempt, and the platform may send multiple webhooks for attempts associated with the same session. A merchant therefore cannot treat every callback as a new completed order. Order state should be derived from confirmed final payment outcomes, with deduplication and audit trails.
The experience reported in Dave Finances’ analysis of repeat failures across payment rails in Nigeria, Spain and Zambia illustrates why fault attribution and retry strategies must work across layered dependencies. A merchant should distinguish fail-fast failures from pending authorizations and callbacks before selecting a fallback.
Figure 2. Payment-state controls prevent ambiguous timeouts from becoming duplicate charges.
What really improves the recovery rate?
The order-recovery toolkit contains several options, but none is free. A second PSP can preserve checkout capacity during a failure of the first, provided both do not depend on the same underlying acquirer, gateway or network. Offering another payment method may redirect demand, although the customer might not have it available. Holding carts and sending payment links after recovery can recapture some sessions, subject to consent and marketing rules. Call-center or invoice-based arrangements may work for high-value orders but are expensive at scale.
A merchant should first map critical dependencies: frontend checkout, fraud screening, authentication, token vault, acquirer, processor, network, wallet and settlement system. Redundancy that shares the same vault or authentication service may fail at the same time. It also creates reconciliation complexity, token portability concerns, higher fixed costs and potentially different chargeback exposures. The relevant metric is not the number of PSP contracts, but independence of failure paths.
For a retailer with the same $7,956 modeled sales loss, suppose a genuinely independent secondary route costs $350 per month including minimum processing commitments and integration amortization. One severe outage avoided per year would make annual fixed backup cost of $4,200 economically worthwhile only if enough margin is actually preserved; at a 40% contribution margin, avoiding all $7,956 of permanently lost sales saves $3,182.40, still below the annual fixed expense. Avoiding two comparable incidents would preserve about $6,364.80 of contribution and exceed that annual cost. This simple break-even does not include customer retention, reputation or other operational gains.
Figure 3. Original backup-PSP break-even: annual $4,200 cost versus contribution preserved.
Why insurance may not rescue an ordinary processor outage
Business-interruption insurance is often misunderstood. The U.S. National Association of Insurance Commissioners says traditional business-income coverage generally relates to suspended operations following insured physical property damage, subject to policy conditions. A remote software or processor outage does not automatically satisfy that trigger. Cyber and contingent business-interruption extensions can offer broader cover, but coverage depends on definitions, waiting periods, named providers, exclusions and sublimits.
A merchant expecting insurance protection should check whether an outsourced payment provider counts as a covered dependent service; whether non-malicious technical outages qualify or only security incidents do; how many hours must pass before coverage starts; and whether proof of lost gross profit is required. If an outage lasts only two hours and the policy requires a 12-hour waiting period, a genuine interruption may still produce no payout. That is a contract example, not a statement that all cyber policies use that period.
The legal recovery route can become stronger if the provider breached a specific guaranteed uptime covenant with express service credits, misrepresented the service, caused direct losses within a contractual exception, or violated mandatory law. The merchant still needs to preserve evidence and comply with claims procedures. General claims that an outage caused financial stress do not replace causation, calculation and notice requirements. Counsel should review material disputes because enforceability varies by country and business contract.
A practical outage-loss evidence pack
| Evidence | Why it matters | Common analytical mistake |
| Time-stamped failed attempts | Identifies affected payment cohort | Treating every retry as unique demand |
| Provider status/incidents | Supports incident timing and scope | Assuming entire platform failed |
| PaymentIntent/transaction IDs | Reconciles completed and pending payments | Double-charging ambiguous orders |
| Baseline checkout conversion | Estimates counterfactual orders | Using gross traffic as guaranteed sales |
| Contribution-margin statement | Measures economic profit at risk | Claiming all lost revenue as lost profit |
| Customer recovery records | Subtracts later completed sales | Counting later orders twice |
| Contract and SLA | Determines possible remedy | Equating fault with legal liability |
A sensible recovery process is staged. In the first minutes, stop duplicate retries, establish impacted geographies and methods, and put a clear message at checkout. Next, route only unequivocally failed payments to approved alternatives while reconciling transactions that might already have been authorized. After recovery, segment abandoned checkouts, restore inventory and avoid sending payment links to customers who have already paid. Only once the operational ledger is correct should finance calculate permanent loss and assess a contractual claim.
The lost-customer tail may exceed the incident window
Lost contribution during a two-hour failure may understate the strategic impact if shoppers conclude a business is unsafe or unreliable. Yet measuring that long-term effect requires cohort evidence. Compare the repeat-purchase behavior of customers exposed to the failed checkout with otherwise similar unexposed customers, adjusting for acquisition channel, basket size and seasonality. Do not multiply the whole affected audience by lifetime customer value: many attempted orders would have failed for unrelated reasons, and many shoppers return once the site works.
A post-incident campaign can capture some of this tail, but indiscriminate discounts may turn successful recovery into margin destruction. If an abandoned checkout customer was already going to return, a 15% incentive creates unnecessary cost. Merchants should test follow-up messages against a holdout group so that the measured uplift reflects incremental completed orders rather than conversion that would have occurred anyway. Merchant service recovery is best treated as an experiment with contribution measured after promotional costs.
The bottom line for merchants
Most merchants have more control over checkout resilience and customer recapture than over the processor’s contractual liability. Build a model that distinguishes attempted payment value, actual abandoned orders, recoverable customer demand, contribution profit and enforceable reimbursement. If a merchant can recover 40% of endangered orders with a verified fallback and post-outage campaign, that often creates more certain value than an ambitious demand for consequential damages that the contract expressly excludes.
The test for a credible outage-response plan is whether a payment can fail without losing the order, charging the customer twice or contaminating financial reporting. Providers should publish clear incident histories and reconciliation tools; merchants should demand workable fallback arrangements and audit-grade state information. The most valuable protection is often designed before any provider fails.
Methodology
All merchant examples are hypothetical, not reported transaction records. Orders exposed = 120/hour x 2 hours x 85%; immediate recovery = 20% of exposed; later recovery = 25% of the remainder; permanently lost orders = 122.4; revenue = orders x $65; contribution loss = revenue x 40%. The two-outage fallback test compares annual $4,200 cost with modeled $3,182.40 contribution preserved per severe incident. Insurance and contract commentary describes primary published terms, not legal advice or a prediction that an individual claim will succeed.
Sources and primary documentation
Research cut-off: October 23, 2026. Sources are linked to the official or published pages; scenario assumptions and original calculations are identified in the Methodology section.
01. Stripe Services Agreement — General Terms, amended September 28, 2026 — The applicable general contract illustrates exclusions for indirect losses and the qualified 12-month-fee cap.
02. Stripe — contract terms and liability guidance — Provider help text emphasizes that consequential business interruption losses are often excluded.
03. Stripe developer reference — PaymentIntent lifecycle and payment statuses — Shows why processing, succeeded, canceled and requires-payment-method represent different payment states.
04. Stripe developer reference — idempotent request handling — Explains safe server-side retries and the limits of idempotency rather than blind charge resubmission.
05. Stripe developer reference — confirm payment and failure states — Documents which state transitions can occur after a payment is confirmed or fails.
06. Adyen operational status — Oct 21, 2026 Pix refunds incident — Live operational record for a specific Pix refund-delay incident, not a total payment-platform outage.
07. Adyen developer documentation — retry requests with idempotency — A second provider independently documents how its API uses request keys to avoid double processing.
08. Adyen developer documentation — hosted-checkout retries and webhooks — Merchant implementation guidance on repeat checkout attempts and multiple webhook events.
09. NAIC — June 2026 business interruption and physical damage triggers — Regulator-supported background on traditional interruption-insurance triggers and covered physical damage.
10. NAIC — 2026 cybersecurity insurance report and contingent risk discussion — Current market report clarifies that cyber and contingent interruption cover depends on detailed policy language.
11. Dave Finances — contemporaneous Xendit incident chronology — Original incident timeline illustrating why an apparently restored payment rail may fail again.
12. Dave Finances — Telecel disruption and multiple processor dependencies — Independent merchant-routing example with multiple upstream providers and different affected payment products.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574