Your payment processor just went offline. A customer's card was charged, but the transaction never completed on your end. Their money is floating in limbo. You're getting support emails. Your revenue tracking is broken. This happens more often than you'd think—payment processors experience downtime roughly 2-4 times per year on average, often during peak shopping periods. The difference between a smooth recovery and a disaster is knowing exactly what to do in the first 30 minutes.
Check If It's Actually Down (Not Just You)
Before panicking, verify the outage is real. Visit WebsiteDown.com or use your payment processor's status page—most major processors (Stripe, Square, PayPal) maintain real-time status dashboards. Check Twitter for complaints from other merchants. If only you can't connect, the problem might be your API keys, firewall rules, or a regional network issue. Test connectivity from a different network (mobile hotspot). Call your processor's support line—if they're answering, it's likely a widespread outage. This distinction matters because your response changes: a widespread outage requires customer communication; a local issue requires technical troubleshooting.
Capture Transaction Data Before Anything Else
The moment you confirm an outage, screenshot or export every transaction attempt, error message, and timestamp. This becomes your audit trail. Most processors queue failed transactions, but logs get archived quickly. Document: customer names, amounts charged, card last four digits, and exact timestamps. If your system logged the transaction locally but the processor never received it, you have proof. If the processor charged the customer but never confirmed to you, they'll have records too. This documentation prevents disputes later and helps your processor's support team trace ghost transactions. Many payment processors have a non-obvious behavior: they continue processing transactions during their own API outages, but won't send confirmation webhooks back to your system. Your customer got charged; you just don't know it yet.
Communicate With Customers Immediately (Not After)
Send a brief, honest message to affected customers within 15 minutes of confirming the outage. Don't wait for a resolution. Say: "We experienced a payment processing interruption. Your card may have been charged, but your order status is unclear. We're investigating and will follow up within 2 hours with a status update." This prevents duplicate payment attempts—customers won't retry their card if they know you're aware. Include a support email or ticket number so they can track their case. Transparency kills 80% of the anger customers feel during outages. Silence kills your reputation.
Reconcile Orders Once Service Restores
When the processor comes back online, don't assume everything synced correctly. Run a manual reconciliation: compare your local transaction records against the processor's settlement report. Look for: charges without order confirmations, orders without charges, and duplicate charges. Most processors show settlement status within 1-4 hours of recovery, but some take longer. Contact support if you find mismatches—they can void duplicate charges or manually confirm stuck transactions. This step catches the weird edge cases: a transaction that charged twice, or one that never hit the customer's card despite showing as pending on your side. Set a calendar reminder to check reconciliation reports for 3 days after any outage.
Build Redundancy Before the Next Outage
One payment processor is a single point of failure. Integrate a backup processor (different company, different infrastructure) and route to it automatically if your primary fails. Stripe + Square, or Stripe + PayPal combinations are common. This requires upfront work but eliminates total revenue loss during outages. You could also implement a manual payment fallback: capture card details securely (PCI-compliant) and process them manually once service restores. Most outages last 15-90 minutes—your customers can wait if they know you're handling it. Document your outage response procedure and test it quarterly. The processor that goes down today probably won't be the same one next time.