Home/Research library/Customers Can’t Pay

Guide · Payment reliability

What Happens When a PSP Goes Down?

Minute zero: customers press Pay At 10:00:00, customers are checking out normally. At 10:00:05, authorization latency begins rising. At 10:00:12, one request times out before it reaches the payment provider. At 10:00:14, another request reaches the provider, is authorized by the

Source-imported researchEditorial verification pending

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

What Happens When a PSP Goes Down? A Payment Outage Timeline

Minute zero: customers press Pay

At 10:00:00, customers are checking out normally.

At 10:00:05, authorization latency begins rising.

At 10:00:12, one request times out before it reaches the payment provider.

At 10:00:14, another request reaches the provider, is authorized by the issuer, but its response does not return to the merchant.

At 10:00:20, a third payment succeeds and appears in the provider’s system, but the webhook confirming it is delayed.

At 10:01, some customers see errors. Others see loading indicators. A few reach confirmation pages. Support receives the first message from a customer who sees a pending card authorization but no completed order.

The payment provider has a problem.

That statement is true, but it is not yet specific enough to guide a safe response.

When a PSP goes down, new payment requests may fail, time out, remain pending, or complete without an immediate confirmation. Authentication, authorization, status retrieval, webhooks, captures, refunds, and reporting may be affected differently. Merchants should classify each payment by its known state before retrying, failing over, fulfilling, or telling the customer that it failed.

Why PSP outages are rarely binary

A payment service provider is not one endpoint connected directly to one bank.

The customer-visible payment path may depend on:

checkout scripts;

payment-method configuration;

card or account tokenization;

fraud screening;

3-D Secure infrastructure;

acquirer connections;

processor links;

payment networks;

issuing banks;

local payment-method operators;

provider databases;

queues;

webhook systems;

status APIs;

reporting systems;

and merchant callback endpoints.

A full outage can affect most or all of those services.

A partial degradation may affect only one.

Google’s reliability guidance distinguishes user-visible, black-box symptoms from internal, white-box system signals. Both are necessary: customer-facing failures reveal impact, while endpoint, queue, dependency, and resource metrics help locate the cause. (Google SRE)

Partial outage

A partial outage means that some functions, traffic, regions, or payment methods remain available.

Examples:

authorization requests time out while status retrieval still works;

cards fail while a local bank-payment method remains available;

one acquiring route is degraded;

European traffic is affected while another region operates normally;

webhooks are delayed while synchronous payment creation still succeeds;

or capture fails while new authorizations continue.

Full outage

A full outage means that the provider’s relevant merchant-facing payment services are broadly unavailable.

Even then, “full” must be scoped.

The provider’s dashboard might be unavailable while existing payment processing continues. Alternatively, the public checkout may be unreachable while server-to-server status requests remain possible.

Endpoint-specific failure

One endpoint can fail independently of another.

For example:

payment creation fails;

charge-detail retrieval works;

capture requests time out;

refund requests remain available;

and webhooks arrive late.

The merchant response should differ by operation.

A failed refund request does not justify disabling new checkout payments. A failing authorization endpoint does.

Regional outage

A provider or its infrastructure dependency may fail in one geographic region or data path.

Merchants should compare:

customer region;

merchant server region;

provider region;

acquirer;

payment method;

and API route.

A global average may show only a small error increase while one country experiences near-total payment failure.

Downstream issuer or network issue

A merchant can observe elevated payment errors even when the PSP itself is healthy.

The affected component may be:

one issuer;

one card network;

an acquirer;

a local payment method;

an authentication provider;

or telecommunications infrastructure.

Do not announce a “PSP outage” solely because authorization rates fall.

Confirm the service boundary first.

The payment functions that can fail independently

Payment initiation

The merchant attempts to create a payment, charge, or provider-side payment object.

Possible outcomes:

known rejection before processing;

accepted request and returned response;

timeout before dispatch;

timeout after dispatch;

or provider-side acceptance with no merchant response.

Authentication

A customer may be redirected to 3-D Secure, a banking application, an OTP flow, or another verification process.

A provider incident can prevent:

challenge initialization;

redirect creation;

result return;

or correlation of authentication with the payment attempt.

Authorization

The PSP may successfully create a payment object but fail to deliver the authorization to the acquirer, network, or issuer.

Alternatively, the authorization may succeed while the PSP fails to return the result to the merchant.

Status retrieval

The primary payment request may fail while a read-oriented charge-detail or payment-status endpoint remains available.

This distinction is operationally valuable because status retrieval can reduce the number of unknown payments without creating another financial request.

Webhooks or payment events

Payment processing may continue while the event-delivery system is delayed.

The result is a growing gap between:

provider state;

merchant payment state;

and merchant order state.

Capture

A card authorization can succeed while a later capture operation fails.

For merchants using authorization and delayed capture, this creates a specific backlog:

authorized payment;

uncaptured funds;

potentially fulfilled order;

and a shrinking capture window.

Refund and void

Customers may continue requesting cancellations or refunds during an outage even if refund processing is impaired.

A refund backlog must be tracked separately from failed checkout payments.

Reporting and dashboards

Operational dashboards can fail while payment APIs work, or payment APIs can fail while reporting remains available.

A dashboard is one observation surface. It is not necessarily the authoritative payment state.

The PSP Outage Timeline

The times below illustrate sequence rather than universal response targets. Actual escalation thresholds should reflect merchant volume, payment risk, service-level objectives, and provider contracts.

T+0 to T+2 minutes: first signal

Customer symptom

Some customers see:

a longer spinner;

a timeout;

“Something went wrong”;

repeated authentication;

or no order confirmation.

Other customers continue paying normally.

Merchant observation

Potential first signals include:

elevated p95 or p99 payment latency;

rising timeout rate;

increase in unknown payment states;

lower authorization responses;

missing webhooks;

customer-support contacts;

synthetic-checkout failures;

or a provider notice.

A provider status page may not yet report an incident.

That does not prove that no provider incident exists. Public status information is published according to the provider’s detection, confirmation, scope, and communication process. Project- or merchant-specific monitoring can reveal impact before a public incident is posted or can show that the merchant is unaffected by a broader incident. Google Cloud, for example, distinguishes a public health view from project-relevant service-health events. (Google Cloud)

Merchant action

Alert the payment on-call team.

Preserve request and response evidence.

Stop automated systems from treating every timeout as a final failure.

Compare symptoms across endpoints, methods, issuers, and regions.

Open an incident record if customer impact or cross-team coordination is already required.

Google’s incident-management guidance recommends declaring incidents early when customers are affected or multiple teams are needed, then assigning clear command, operations, communication, and planning responsibilities. (Google SRE)

Data required

payment-intent ID;

request ID;

provider reference where available;

endpoint;

payment method;

region;

latency;

HTTP or transport result;

provider error;

authorization result;

authentication state;

and timestamp.

Principal risk

The first automated response creates more damage than the outage:

retry storm;

duplicate authorizations;

uncontrolled failover;

or cancellation of payments that actually succeeded.

Communication

Internal:

Investigating elevated card-payment latency and timeout rates. Do not classify timed-out payments as failed until status is confirmed.

Customer-facing communication is usually premature unless the impact is already clear and substantial.

Exit criterion

The team has enough evidence to determine whether the signal is:

merchant-specific;

provider-specific;

issuer- or method-specific;

regional;

or a false alarm.

T+2 to T+10 minutes: impact confirmation

Customer symptom

The checkout experience becomes inconsistent.

One customer’s card fails immediately. Another remains on a spinner. A third receives an issuer authorization notification but sees no merchant order.

Merchant action

Build an impact matrix.

Dimension

Questions

Endpoint

Is payment creation failing? Does status retrieval work?

Operation

Are authorization, capture, refund, and void affected equally?

Method

Are cards, wallets, bank payments, and local methods affected?

Region

Which customer and server regions show impact?

Provider route

Is one acquirer or processing route affected?

Payment state

How many attempts are failed, pending, successful, or unknown?

Event delivery

Are webhooks absent, delayed, duplicated, or out of order?

Customer

What error or uncertainty does the customer see?

Data required

Use both:

black-box evidence: synthetic payment results, customer errors, checkout completion;

white-box evidence: endpoint errors, queue depth, provider responses, status-retrieval success, event lag, and internal logs.

Reliability monitoring is strongest when user-impact metrics can lead responders toward more detailed diagnostic metrics. (Google SRE)

Principal risk

The team assigns blame before confirming the failure boundary.

A provider-wide conclusion may be incorrect when only:

one merchant release;

one certificate;

one DNS route;

one acquiring connection;

or one issuer cohort

is failing.

Communication

Provider escalation should include:

merchant account or project;

affected endpoint;

region;

payment method;

representative timestamps;

provider references;

error classes;

and observed impact.

Do not send raw customer credentials or unnecessary payment data.

Exit criterion

The incident has a working scope statement, such as:

Card authorization requests from the EU application cluster show elevated read timeouts. Payment-status retrieval remains available. Wallet payments and North American traffic appear unaffected.

That statement is operationally useful. “The PSP is down” is not.

T+5 to T+15 minutes: customer containment

Containment limits new ambiguous payments while preserving viable payment routes.

Possible actions

disable only the affected payment method;

temporarily remove the affected route;

keep unaffected methods available;

stop automatic customer retries;

extend a pending-payment screen;

preserve cart and order state;

suppress repeated payment-button activation;

show a temporary service message;

or pause fulfillment for unknown outcomes.

Customer message for a confirmed method outage

Card payments are temporarily unavailable. Your order has not been submitted through this payment method. Choose another available method or try again later.

Use this message only when the merchant knows that the payment did not enter processing.

Customer message for an unknown outcome

We are confirming the status of your payment. Please do not submit another payment yet. Your order information has been saved.

Principal risk

A generic message tells customers that payments failed when some actually succeeded.

Those customers may:

retry;

switch method;

contact support;

or create a second order.

Exit criterion

New customer traffic can no longer enter a known unsafe path, while unaffected methods and confirmed successful journeys remain available.

T+5 to T+20 minutes: payment-state protection

At this phase, the merchant separates payment attempts into certainty classes.

Known pre-processing failure

The request did not leave the merchant or the provider definitively rejected it before financial processing.

Possible action:

allow another attempt;

offer another method;

or route through a documented alternative.

Known payment failure

The provider or payment method returned a final unsuccessful result.

Possible action:

present an accurate failure message;

allow a new attempt when permitted;

or ask the customer to choose another method.

Known success

The provider confirms successful authorization or payment.

Possible action:

prevent another payment;

create or recover the order;

and wait for or reconcile later asynchronous events.

Pending

The payment method or provider reports that processing continues.

Possible action:

keep the order pending;

wait for events;

retrieve status;

and avoid customer or system retries that create a second payment.

Unknown state

The merchant sent a financial request but cannot determine the outcome.

Possible action:

freeze a new attempt;

retrieve status;

reuse a provider-supported idempotent identity when applicable;

inspect events;

and send unresolved items to reconciliation.

RFC 9110 explains that an idempotent request can be repeated after a connection failure because its intended server effect remains the same. It also warns that clients should not automatically retry non-idempotent requests unless they know the operation is idempotent or know the original request was not applied. Payment creation therefore requires an application- and provider-level idempotency contract, not merely an HTTP retry. (IETF Datatracker)

Principal risk

The order system changes UNKNOWN to FAILED because a timer expires.

Time has passed, but no new evidence has been obtained.

Exit criterion

Every affected payment attempt is assigned to a state queue with a documented owner and next action.

T+10 to T+30 minutes: failover decision

Failover may restore payment acceptance.

It can also create duplicate payments when the primary provider’s in-flight state is unknown.

Failover is more appropriate when

a request was blocked before leaving the merchant;

the primary provider definitively rejected it before processing;

the affected endpoint or region is clearly isolated;

the alternative route supports the payment method and token;

merchant fraud and authentication controls remain active;

order and payment-intent identity span both routes;

and the merchant can reconcile late results from the primary provider.

Failover is dangerous when

the original request timed out after dispatch;

provider status cannot be retrieved;

a primary authorization may still arrive;

payment credentials cannot be moved safely;

the customer has already completed authentication;

the backup route uses a different merchant or recurring-payment context;

or no cross-provider duplicate-control process exists.

Hypothetical duplicate sequence

Primary PSP receives an authorization request.

The issuer approves it.

Merchant receives a timeout.

Merchant immediately sends the order to the backup PSP.

Backup authorization is approved.

Primary provider later delivers the original success event.

The outage created uncertainty. The failover decision created the duplicate.

Merchant action

Before failover:

lock the payment intent;

determine whether the primary request was dispatched;

retrieve primary status where possible;

set a maximum unknown-state exposure;

record the failover reason;

create a separate attempt beneath the same payment intent;

and monitor for delayed success on both routes.

Exit criterion

Failover is either:

activated for a precisely defined safe cohort;

held because payment state is uncertain;

or rejected because integration prerequisites are missing.

What happens to new payment attempts?

New attempts can take several paths during an outage.

They fail before leaving the merchant

Examples:

merchant circuit breaker blocks dispatch;

internal dependency fails;

provider DNS cannot be resolved;

connection cannot be opened.

This may be a known pre-processing failure, but merchants should confirm how connection establishment and provider ingress behave before treating every connection error as proof that no request was accepted.

They reach the PSP and receive a known error

The provider may reject the request because:

a dependency is unavailable;

the endpoint is overloaded;

processing is paused;

or validation fails.

A provider error is not always a final payment failure. The error contract should state whether an object was created or financial processing began.

They time out

A timeout describes the merchant’s observation, not the payment result.

The request may be:

unreceived;

queued;

processing;

authorized;

or completed.

They remain pending

Some methods are asynchronous under ordinary conditions. During an outage, their pending interval may lengthen.

Do not treat all long-running payments as failures merely because a card-payment expectation was applied to them.

They succeed

A PSP can continue accepting and processing some traffic while:

one endpoint degrades;

event delivery stops;

reporting lags;

or one dependency fails.

This is why the merchant’s response must be scoped.

What happens to in-flight payments?

In-flight payments are the most operationally dangerous population because the merchant may not know what happened financially.

Request sent, no provider reference

The merchant has the least direct retrieval capability.

Use:

merchant payment-intent ID;

idempotency key;

trace data;

timestamp;

amount;

payment-method token reference;

and provider support escalation.

Do not create a second attempt automatically.

Provider object created, authorization unknown

Retrieve the provider object if the status endpoint is available.

Authorization approved, merchant order missing

Recover the order from the successful payment rather than charging again.

The merchant should be able to correlate:

payment intent;

provider reference;

authorization;

customer;

amount;

currency;

and original order contents.

Customer abandoned while the payment was processing

Customer departure does not cancel a provider-side payment automatically.

The payment must still be resolved and reconciled.

Customer retries manually

The checkout should locate the existing payment intent.

If the first attempt is pending or unknown, it should not silently create a second attempt.

What happens to authentication?

Authentication can fail independently of authorization.

Challenge initialization fails

The merchant or PSP cannot create or display the authentication step.

The payment may be:

unsubmitted;

waiting for authentication;

or in a provider-specific state.

Customer completes authentication, but result return fails

The customer may have satisfied the issuer challenge while the merchant receives no completion event.

Do not immediately start a new unauthenticated payment.

Retrieve the authentication and payment state.

Authentication works, authorization fails

The provider may recover enough to complete authentication while the authorization route remains unavailable.

Authentication success does not mean the payment succeeded.

Authorization works, authentication dependency fails

Transactions requiring a challenge may fail while transactions receiving another permitted authentication treatment continue.

This can create issuer-, country-, device-, and transaction-specific outage impact.

What happens to webhooks?

Payments can succeed while webhooks stop

The provider’s synchronous payment path and its asynchronous delivery system may use different services.

The merchant then sees:

approved payment in the PSP;

no webhook;

order still marked pending;

no fulfillment;

and eventual webhook backlog.

Webhooks can arrive after provider recovery

Recovery may release a large backlog.

This can produce:

delivery bursts;

duplicate deliveries;

out-of-order states;

database contention;

downstream queue growth;

and delayed fulfillment.

Queue and event platforms commonly use at-least-once delivery. AWS documents that standard SQS messages may be delivered more than once or out of order and advises idempotent consumers. The same engineering principle applies to payment-event processing: repeated delivery must not repeat the financial or fulfillment outcome. (AWS Documentation)

Do not replay the whole backlog blindly

For each event:

verify authenticity;

check event or payment-reference uniqueness;

compare it with current merchant state;

reject invalid state regression;

retrieve provider status after conflict;

apply fulfillment idempotently;

record the final transition.

What happens to captures?

A provider outage may begin after authorization but before capture.

Customer impact

The customer may see an authorization hold.

The merchant may have:

an approved order;

reserved inventory;

or shipped goods.

The funds may not yet be captured.

Merchant risk

authorization expires before capture;

capture request is duplicated;

capture amount differs from the order;

fulfilled order remains unpaid;

or finance mistakes an authorization for settled revenue.

Recovery

Build a capture backlog containing:

payment intent;

order;

authorization;

provider charge ID;

amount;

remaining capturable amount;

capture deadline;

fulfillment state;

retry count;

and reconciliation status.

Capture retries must be idempotent. A queue redelivery must not capture the payment again.

What happens to refunds and voids?

Refund and void APIs may be impaired even when new payments have recovered.

Customer impact

A customer who was promised an immediate refund may see no returned funds.

Merchant risk

support issues another refund;

cancellation worker retries repeatedly;

void is mistaken for a completed refund;

or merchant order state changes without a corresponding provider operation.

Recovery

Track each remediation operation independently:

refund intent;

original charge or capture;

amount;

operation ID;

provider refund ID;

submission state;

final result;

and customer communication.

Provider recovery is not incident closure

At 10:42, the provider reports that payment processing has recovered.

New authorization latency returns to normal.

The incident is not over.

Service recovery

The provider can accept and process new requests.

Payment-state recovery

The merchant has established the status of payments created during degradation.

Event recovery

Delayed webhooks have been delivered and processed.

Operational recovery

Queues, workers, databases, and support channels have returned to manageable levels.

Financial recovery

Authorizations, captures, voids, refunds, and settlements have been reconciled.

Customer recovery

Affected customers have:

received their products;

received accurate order confirmations;

had extra authorizations reversed;

received refunds where needed;

or received a clear explanation of what happened.

Google’s outage examples distinguish restoration of a service from the longer recovery of affected dependencies and capacity. The same principle applies to payments: the primary API can recover while backlog, state, and reconciliation work continues. (Google SRE)

The backlog-processing phase

Throttle recovery traffic

After service restoration, merchants may release:

API retries;

status checks;

capture jobs;

refund jobs;

webhook processing;

customer refreshes;

and support-triggered actions

at the same time.

An unthrottled release can create a second degradation.

Use:

bounded concurrency;

rate limits;

exponential backoff where appropriate;

jitter;

priority queues;

circuit breakers;

and per-operation retry budgets.

Prioritize by financial risk

A possible order is:

Unknown authorizations at risk of duplicate retry

Approved payments missing orders

Time-sensitive capture operations

Customer cancellations and voids

Refund obligations

Delayed fulfillment events

Reporting and noncritical updates

The exact priority depends on the merchant model.

Keep customer-triggered and system-triggered retries separate

A customer returning to checkout should not race an automated recovery worker.

Both must coordinate through the same payment-intent state.

Define the backlog exit criterion

The provider saying “resolved” is not the criterion.

Useful criteria include:

no unresolved payment older than the defined threshold;

webhook lag below the operational limit;

capture backlog cleared;

refund backlog accepted;

reconciliation exceptions assigned;

customer-support volume returning to baseline;

and no continued duplicate-payment signal.

Reconciliation after a PSP outage

Reconciliation establishes financial truth after the event-delivery and order systems have diverged.

Compare at least four records

Merchant payment-intent ledger

Merchant order ledger

Provider transaction records

Settlement, acquirer, or bank records when available

Identify known exception classes

payment approved, order missing;

order marked paid, provider payment failed;

authorization approved, capture missing;

capture completed, webhook missing;

refund submitted, result unknown;

customer retried and created two authorizations;

failover providers both succeeded;

duplicate webhook, one financial payment;

payment event linked to the wrong order;

or settled payment absent from the merchant ledger.

Select a canonical payment

When duplicate successful payments exist, identify the one representing the intended payment for the order.

Do not decide based only on which webhook arrived first.

Review:

payment intent;

customer;

order;

amount;

currency;

provider reference;

authorization and capture times;

fulfillment;

and settlement.

Remediate extra authorizations

Where supported, void or reverse an unintended authorization before capture.

The customer’s issuer controls when a released hold disappears from the account display.

Remediate duplicate captures

Issue a refund for the unintended captured payment using a uniquely identified refund operation.

Do not refund both successful payments.

Repair merchant state

create or recover missing orders;

correct fulfillment;

reissue confirmation;

update accounting records;

and preserve an audit trail.

Customer remediation

Customer sees an error and no charge

Your payment did not complete. No completed order was created. You can try again or choose another payment method.

Use only after confirming failure.

Customer sees a pending charge and no order

We found a payment attempt that is still being confirmed. Please do not submit another payment. We will update the order when the final status is available.

Payment succeeded, order was delayed

Your payment was successful, but the order confirmation was delayed during a payment-service incident. Your order is now confirmed.

Duplicate authorization

An additional authorization hold was created during payment recovery. We have requested cancellation of the extra authorization. Your bank controls when the hold disappears.

Duplicate captured payment

We confirmed an additional completed charge and submitted a refund for it. Your refund reference is [reference].

Refund delayed

Your refund request has been submitted, but processing was delayed during the payment-service incident. We will confirm when the provider records the completed refund.

The customer message should distinguish what is known from what is still being investigated.

The PSP Outage Timeline framework

Phase

Customer symptom

Merchant action

Required data

Main risk

Communication

Exit criterion

First signal

Slow spinner, isolated errors

Alert, preserve evidence, stop unsafe automatic retries

Latency, errors, intent and request IDs

Retry storm

Internal investigation notice

Signal scoped enough to investigate

Impact confirmation

Inconsistent outcomes

Build endpoint, method, region, and state matrix

Black-box and white-box evidence

Wrong failure boundary

Provider escalation with evidence

Working impact statement

Customer containment

Errors or uncertainty

Disable affected paths, preserve carts, show state-specific message

Affected cohort

Duplicate customer retry

Honest checkout notice

No new traffic enters unsafe path

Payment-state protection

Missing or conflicting confirmations

Classify known success, failure, pending, and unknown

Provider ID, events, status

Unknown treated as failed

Support guidance

Every affected payment has owner

Failover decision

Alternative method or route offered

Verify primary state, token portability, and idempotency

In-flight inventory

Duplicate authorization

Internal approval and customer choice

Failover scoped or deliberately withheld

Provider recovery

New requests normalize

Throttle retry and status traffic

Endpoint health and backlog

Second overload

Provider and internal update

New traffic stable

Backlog processing

Delayed confirmations

Process events and jobs idempotently

Queue depth, event lag

Duplicate processing

Support update

Backlog within target

Reconciliation

Customer and merchant records differ

Compare ledgers and provider records

Payment, order, settlement data

Missing or duplicate money

Finance and operations updates

Exceptions assigned or resolved

Customer remediation

Holds, missing orders, delayed refunds

Void, refund, restore, and notify

Canonical payment result

Incorrect remediation

Individual accurate messages

Customer outcome resolved

Post-incident review

No immediate symptom

Document contributing factors and test controls

Timeline and approved evidence

Recurrence

Blameless findings

Owners and deadlines assigned

How to measure a PSP outage

Time to detect

First merchant-impacting event to first actionable alert

Use a defined event such as:

first elevated error;

first synthetic failure;

or first affected customer payment.

Do not start the clock only when a provider acknowledges the incident.

Time to confirm

First actionable alert to approved impact statement

The impact statement should identify at least:

service;

operation;

cohort;

payment state;

and customer effect.

Endpoint error rate

Eligible requests returning a defined technical or provider error

÷ eligible requests to that endpoint

Report authorization, status, capture, and refund endpoints separately.

Timeout rate

Requests exceeding the defined response threshold

÷ eligible requests

Segment connection, read, and processing timeouts where observable.

Unknown-state rate

Payment attempts whose final state cannot be confirmed within the defined interval

÷ initiated payment attempts

This is often more useful than the raw timeout rate because it isolates payments that require financial investigation.

Affected payment volume

Count and value of payment intents entering:

known failure;

pending;

unknown;

delayed success;

or reconciliation-required states

during the incident window.

Customer-abandonment rate during the outage

Checkout sessions leaving after encountering the affected payment stage

÷ checkout sessions exposed to the affected stage

Do not classify a technical failure or unknown payment as voluntary abandonment.

Failover activation rate

Eligible affected payment intents routed through the approved failover path

÷ affected intents eligible for failover

Failover recovery rate

Payment intents completed successfully through failover

÷ payment intents routed through failover

Guard this with:

duplicate-authorizations;

duplicate captures;

fraud;

technical errors;

and completed orders.

Webhook backlog

Track:

oldest undelivered or unprocessed event;

number of queued events;

event-delivery lag;

processing lag;

duplicate-event rate;

and out-of-order-event rate.

Payment-state recovery time

First unknown classification to authoritative payment-state confirmation

Report percentiles rather than only an average.

Reconciliation backlog

Payment or order records awaiting manual or automated reconciliation

Also measure the oldest unresolved item.

Revenue affected

Value of orders that could not proceed normally during the incident.

This is not the same as permanently lost revenue.

Revenue recovered

Value of affected orders later completed through:

status recovery;

customer return;

approved retry;

failover;

or manual remediation.

Use a defined attribution window and avoid counting ordinary later purchases without evidence that they were recovered from the incident.

Mean time to reconcile

Incident start to resolution or formal assignment of all financial exceptions

Technical recovery and financial reconciliation should have separate clocks.

Segment outage metrics

At minimum, segment by:

PSP;

API endpoint;

region;

merchant server location;

payment method;

acquirer or processor;

issuer;

card network;

authorization versus capture;

refund or void;

synchronous versus asynchronous result;

primary versus failover route;

device and browser;

checkout version;

deployment version;

error category;

timeout category;

customer type;

order value;

and currency.

Do not segment so narrowly that small samples produce false conclusions.

Incident severity criteria

Severity 1: broad financial uncertainty

Possible indicators:

widespread payment creation failure;

large unknown-state population;

duplicate-payment risk;

inability to retrieve status;

multiple regions or methods affected;

or significant capture and refund impairment.

Response:

incident command;

executive and provider escalation;

controlled customer containment;

and continuous payment-state reconciliation.

Severity 2: material partial degradation

Possible indicators:

one major endpoint or method affected;

meaningful customer impact;

status retrieval available;

or safe workaround exists.

Response:

cross-functional incident;

scoped containment;

provider escalation;

and periodic stakeholder updates.

Severity 3: limited cohort issue

Possible indicators:

one issuer;

one region;

one integration version;

or small but confirmed method impact.

Response:

technical owner and payment-operations owner;

targeted mitigation;

and cohort monitoring.

Severity 4: warning or suspected degradation

Possible indicators:

elevated latency;

intermittent error signal;

no confirmed customer impact;

or provider advisory.

Response:

investigation and enhanced monitoring.

Severity should be based on merchant impact and payment-state risk, not only the provider’s incident label.

Operational ownership

Incident commander

Maintains the overall incident state.

Assigns roles.

Approves major mitigation and failover decisions.

Controls handoffs and closure criteria.

Payment operations

Classifies payment outcomes.

Coordinates with the PSP.

Reviews routes and methods.

Owns payment-state recovery.

Engineering or SRE

Diagnoses endpoints and dependencies.

Applies containment.

Controls retry, queue, and traffic changes.

Preserves technical evidence.

Product and checkout

Adjusts available methods.

Controls customer-facing messages.

Preserves carts and orders.

Monitors customer progression.

Finance and reconciliation

Identifies financial exceptions.

Confirms capture, refund, and settlement.

Measures financial impact.

Approves remediation.

Customer support

Uses approved state-specific language.

Escalates pending charges and duplicate reports.

Avoids issuing unverified refunds.

Records customer impact.

Fraud and risk

Reviews the impact of routing or authentication changes.

Ensures emergency availability measures do not bypass required controls.

What merchants should prepare before the next PSP outage

Service map

Document:

payment-creation endpoints;

tokenization;

authentication;

authorization routes;

status retrieval;

webhooks;

capture;

void;

refund;

reporting;

and dependencies.

Payment-state model

Define:

known success;

known failure;

pending;

unknown;

recovered;

reconciliation required;

and terminal remediation.

Provider capability matrix

For each provider and payment method, record:

status-retrieval options;

idempotency behavior;

retry guidance;

webhook retry behavior;

capture and refund operations;

regional architecture;

token portability;

failover eligibility;

support escalation;

and reconciliation reports.

Incident thresholds

Set alerts for:

endpoint error rate;

p95 and p99 latency;

timeout rate;

unknown-state rate;

missing events;

capture backlog;

refund backlog;

and support contacts.

Customer messages

Preapprove language for:

known failure;

payment pending;

outcome unknown;

method unavailable;

duplicate authorization;

duplicate charge;

and refund delay.

Recovery queues

Prepare queues for:

status retrieval;

order recovery;

capture;

refund;

duplicate investigation;

and manual reconciliation.

Outage drills

Test:

payment-create timeout;

status endpoint available while authorization fails;

webhook delay and replay;

capture outage;

refund outage;

regional method failure;

primary recovery with backlog;

and failover with unknown in-flight payments.

Google’s SRE guidance emphasizes practicing incident response and testing assumptions because hidden dependencies and flawed recovery procedures often become visible only during realistic exercises. (Google SRE)

These public documents do not establish:

how each endpoint behaves during a partial outage;

whether event ordering is guaranteed;

how quickly status data becomes authoritative;

what automatic routing or failover is available;

or which incident communication channels and service objectives apply to each merchant.

Those points require internal verification before publication.

Four concise FAQs

Can a payment succeed during a PSP outage?

Yes. A partial outage may affect only certain endpoints, methods, routes, or event systems. A request may also be authorized before its response is lost. Treat a timeout or missing webhook as an uncertain observation until the payment’s authoritative status is confirmed.

Should merchants switch providers immediately?

Not when the original payment may already be processing. Immediate failover can create duplicate authorizations. Confirm whether the first request was dispatched and determine its state before sending the same obligation through another provider.

What happens to webhooks during an outage?

They may stop, arrive late, be retried, or arrive in a burst after recovery. Webhook consumers should verify authenticity, deduplicate deliveries, apply valid state transitions, and retrieve provider status when events conflict.

When is a PSP incident actually over?

Not merely when new API requests succeed. The incident remains operationally open until in-flight payments are classified, delayed events are processed, capture and refund backlogs are controlled, financial records are reconciled, and affected customers are remediated.

Technical conclusion

At minute zero, the outage appears to be a checkout problem.

Ten minutes later, it is a payment-state problem.

An hour later, it may be a queue, capture, refund, support, and reconciliation problem even though the provider’s main API is working again.

The durable merchant rule is:

Respond to the service that is failing and the payment state that is known—not to a global label saying that the PSP is up or down.

New traffic can be contained.

Known failures can be retried safely.

Known successes can be recovered.

Pending payments can be monitored.

Unknown payments must be resolved before a new financial attempt is created.

Provider recovery restores the path. Reconciliation establishes the truth.

Original practical asset: PSP Outage Timeline worksheet

Incident identity

Incident ID:

Incident commander:

Payment-operations lead:

Engineering lead:

Communications lead:

Finance/reconciliation lead:

First signal:

Provider acknowledgment:

New-traffic recovery:

Payment-state recovery:

Reconciliation completion:

Impact matrix

Dimension

Observed impact

Evidence

Owner

Current action

Payment creation

Authentication

Authorization

Status retrieval

Webhooks

Capture

Void

Refund

Reporting

Region

Payment method

Provider route

Payment-state inventory

State

Count

Value

Oldest item

Owner

Safe next action

Known success

Recover order or fulfill

Known failure

Permit eligible new attempt

Pending

Wait or retrieve

Unknown

Freeze retry and investigate

Duplicate suspected

Select canonical payment

Capture pending

Capture within safe window

Refund pending

Retrieve or retry idempotently

Reconciliation required

Compare financial records

Failover gate

Confirm before activation:

Affected cohort is precisely defined.

Primary in-flight payment state has been assessed.

Token or payment-method portability is supported.

Fraud and authentication controls remain active.

Stable payment-intent identity spans both routes.

Backup-provider capacity is confirmed.

Duplicate detection is enabled.

Late primary success will be reconciled.

Customer messaging is approved.

Abort criteria are defined.

Recovery exit criteria

New payment traffic stable.

Unknown-state queue within threshold.

Webhook backlog processed.

Capture backlog controlled.

Refund backlog controlled.

Duplicate investigations assigned.

Missing-order recovery completed.

Settlement reconciliation scheduled or completed.

Customer remediation in progress.

Post-incident review owner assigned.

The article follows the brief’s incident-timeline structure and its central operational distinction: a PSP outage is a changing set of service conditions, not one binary state in which every payment has failed.

Concise editorial-brief interpretation

This article should explain a payment-provider outage from the merchant’s point of view, minute by minute.

It should not treat the incident as one switch changing from “up” to “down.” Payment initiation, tokenization, authentication, authorization, status retrieval, capture, refunds, reporting, and webhook delivery can fail or recover at different times.

The article’s central operational question is:

What does the merchant know about each payment, and what action is safe at that level of certainty?

The PSP Outage Timeline therefore tracks the incident through ten phases:

First signal

Impact confirmation

Customer containment

Payment-state protection

Failover decision

Provider recovery

Backlog processing

Reconciliation

Customer remediation

Post-incident review

Unique evidence anchor

A PSP outage may leave three customers with three different outcomes at the same moment:

one payment definitively failed;

one payment succeeded but its confirmation is delayed;

and one payment remains in an unknown state because the request left the merchant but no response returned.

Treating all three as failed can create duplicate charges, incorrect order cancellations, and misleading customer communication.

Editorial position

Merchants should respond to provider outages by service, payment method, region, and payment state, not by one global “PSP up or down” label.

The default response to an uncertain in-flight payment should be to preserve the order and establish authoritative status before retrying or failing over.

Common assumption being challenged

“If the PSP is down, every payment failed.”

A provider incident may affect only:

one endpoint;

one payment method;

one acquiring route;

one region;

one authentication dependency;

asynchronous events;

or a post-authorization operation such as capture or refund.

Some transactions may complete before, during, or after the visible degradation.

Selected format and structural rationale

Format: Incident timeline and scenario walkthrough.

The article follows a hypothetical composite outage from the first elevated timeout through technical recovery, webhook backfill, financial reconciliation, and customer remediation.

The timeline format makes delayed consequences visible. It also prevents the article from becoming a general incident-response manual or a complete failover-architecture guide.

Proposed article architecture

Minute zero: customers press Pay

Why PSP outages are rarely binary

The payment services that can fail independently

The PSP Outage Timeline

What happens to new payment attempts

What happens to in-flight payments

What happens to authentication

What happens to webhooks and status updates

What happens to captures, voids, and refunds

When failover helps—and when it creates duplicates

Why provider recovery is not incident closure

Reconciliation and customer remediation

Outage metrics

Preparation checklist

Four concise FAQs

SEO metadata

What Happens When a PSP Goes Down? Payment Outage Timeline

Recommended H1

What Happens When a PSP Goes Down? A Payment Outage Timeline

Meta description

Learn what happens during a PSP outage, including failed and unknown payments, delayed webhooks, capture disruption, safe failover, recovery, and reconciliation.