Fail clearly and never guess. Stop new charge attempts, keep the customer's cart, queue only actions that are safe to repeat, reconcile with the provider once it recovers, and say plainly what is happening. Do not approve orders on hope, and do not store card details yourself as a workaround.
What you can and cannot know
When the provider is down, some of your calls will fail fast, some will hang, and some will succeed on their side while you never hear back. That last case is the dangerous one. You will only know the truth by looking up each payment after recovery. See a payment timed out: did it go through.
Providers also design for recovery on their side. One payment provider retries webhook deliveries for up to three days in live mode, so events missed during your own downtime can arrive later. Do not rely on that alone, since retries have limits. See recovering missed webhooks.
Decide your degraded behavior in advance
| Situation | Reasonable behavior | Avoid |
|---|---|---|
| Provider returns errors immediately | Show a clear message, keep the cart, offer to retry later | Retrying in a tight loop |
| Calls hang | Time out, mark the order pending | Letting threads pile up |
| Payment form fails to load | Disable the pay button, explain | Falling back to a homemade card form |
| Subscription renewals due | Queue and retry with idempotency keys | Cancelling accounts on first failure |
| Refunds requested | Queue and process later | Promising instant refunds |
Steps for the first hour
- Confirm it is the provider. Check their status page and your own error rates by endpoint. See outage or attack: how to tell in the first hour.
- Pause new charge attempts or put a circuit breaker in front of the payment client.
- Mark in flight orders as pending, not failed or paid.
- Keep carts and sessions so customers can come back.
- Post a plain status message on the site and support channels. See what to say to customers during an outage.
- Watch for fraud. Outages attract opportunists posing as support. Warn customers that you will not ask for card details by email or chat.
- After recovery, reconcile every pending order against the provider's records before shipping or cancelling.
Do not weaken security to keep selling
It is tempting to accept card numbers in your own form or take orders on trust. Both create bigger problems than an hour of lost sales: exposure of card data, and orders you cannot collect payment for. Hosted payment fields exist so card data stays with the provider. Keep using them or wait.
Prepare before it happens
- Add timeouts and a circuit breaker to the payment client.
- Write the customer message ahead of time.
- Rehearse the reconciliation job in a sandbox.
- Know who can switch checkout to maintenance mode.
- Run a short game day. See game day plan for a security control outage.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing checks raise a signal when something changes.
Where Safeguard fits
Safeguard's asset discovery and compliance evidence automation can help you track which vendors you depend on and keep incident records. A free scan covers your dependencies.
Quick check
Should I accept orders and charge later during an outage?
Only if your process can collect payment reliably and the customer agrees. Otherwise mark orders pending and reconcile after recovery.
Can I collect card numbers myself for the duration?
No. It exposes card data and creates compliance and security problems far larger than the lost sales.
Sources
- Receive events in your webhook endpoint, Stripe documentation
- Error handling, Stripe documentation
Last reviewed: 19 October 2026.
