What happened
The store updated its payment gateway plugin from 8.1 to 8.2. The update had been through the agency’s usual process: tested on a staging copy of the site, checked against the gateway’s test environment, reviewed, and then applied to the live store at 09:12.
The new version sent a request header that the gateway no longer accepted on live accounts, though its test environment still did. From 09:12, every attempted payment failed. Customers saw a declined-card message, assumed the problem was their card, and left.
Nothing on the site looked broken. Pages loaded, checkout rendered and the uptime monitor stayed green. The only signs were a few new warnings in the PHP error log and, from 09:30, no orders at all. The store usually takes about ten orders in that quarter hour.
At 09:30 Operanse added a warning to the daily summary. At 10:00, after thirty minutes without orders and with every payment failing, it sent an email and a text to the store’s ecommerce lead and the agency’s on-call developer.
The morning, replayed. Press play or drag the clock; the event log below fills in as the replay reaches each minute.
The gateway update. Orders thinned to nothing eighteen minutes after a payment gateway update, while every payment rang as failed. Caught at 09:30, messaged at 10:00, back when it was rolled back.
- 09:12Change recorded: Payment gateway plugin 8.1 → 8.2 · by an administrator (wp-admin)
- 09:20PHP errors · Unusual: 2 warnings since 09:12, usually none at this hour
- 09:30Orders · Warning: 0 orders in the last 15 minutes, against about 10 normally · added to the daily digest, no alert sent
- 10:00Orders · Critical: orders well below normal for 30 minutes · alert sent · message sent
About $1,100 has not been taken since 09:30, against this store’s usual for the hour. Carried as an estimate. - 10:26Change recorded: Payment gateway plugin rolled back to 8.1 · by an administrator (wp-admin)
- 10:38Orders · Resolved after 68 minutes: back to normal
What happened next
The alert said four things: orders had been below normal for thirty minutes; every payment since 09:12 had failed; the payment gateway plugin had been updated at 09:12 by an administrator; and an estimated $1,100 in orders had not come in since 09:30, compared with the store’s usual for that hour.
The developer rolled the plugin back to 8.1 at 10:26. Orders resumed within a few minutes and the incident closed at 10:38. The lost sales did not come back, and customer service answered eleven emails about declined cards that day.
The gateway’s status page showed nothing throughout, because the gateway itself was working. The plugin author released a fix the following week.
If this is happening on your store
None of the checks below need a monitoring tool, only access to WordPress admin and your payment provider’s dashboard.
What to check first
- In WooCommerce → Orders, filter by Failed and by Pending payment. A run of failed orders that starts at one moment points to something that changed then; ordinary declines are spread out and have mixed reasons.
- Open a failed order and read its order notes. Most gateways record the response they received there, and the same message on every order is the most useful clue you will get.
- In WooCommerce → Status → Logs, open the log your payment plugin writes, and the fatal-errors log. If you have a PHP error log too, read the PHP error log for the plugin behind the errors.
- In the gateway’s own dashboard, look at the same minutes. Either the attempts reached it and were declined, or nothing arrived at all.
- List what changed just before the first failure: plugin and WooCommerce updates, payment settings, API keys, the caching or CDN setup.
Telling the likely causes apart
- Every attempt declined with the same error, whatever the card. The integration is at fault, not your customers: an update, expired or rotated API keys, or a setting the gateway now rejects. Roll back the most recent payment change first.
- Attempts never reach the gateway. The failure is earlier, on the store: a fatal error in checkout, a script error in the browser, or a cache serving the checkout. Check whether your WooCommerce checkout is being cached.
- The gateway’s status page reports an incident. The provider is at fault. Nothing on the store will fix it; consider switching customers to another payment method until it clears.
- One payment method fails and the others work. The problem is limited to that gateway’s plugin or account.
- Charges succeed in the gateway but orders stay at Pending payment. The gateway’s notifications (webhooks) are not reaching the store, so customers have paid for orders the store does not know about.
Confirming it has recovered
- Place a real low-value order on the live store with a real card, and refund it. A test-mode order proves only the test environment.
- Check that orders are arriving at the rate usual for the hour, and that new failed orders are back to the occasional decline.
- Match the gateway’s list of payments for the outage against the store’s orders, and fix any order left at Pending payment that was in fact paid.
- Failed orders keep the customer’s details. Decide whether to contact them; some will not try again on their own.
How to prevent it
- Place a real order on the live store after any release that touches payments: one low-value item, paid with a company card and refunded straight away. Staging tests the code; only the live store tests the gateway.
- Don’t assume a gateway’s test environment behaves exactly like its live one. Check payment plugin release notes against the gateway’s own deprecation notices.
- Release payment plugins on their own, not bundled with other updates, so a rollback undoes one thing.
- Send critical alerts to both the person who deployed the change and the person responsible for the store.
Related tools and examples
- Read a WordPress PHP error log: paste the log and see fatal errors first, each traced to the plugin that raised it.
- Check whether your checkout is being cached: a cached checkout fails payments in a similar quiet way, with no update involved.
- Estimate what the outage cost: use “Orders stopped” with the hours it lasted and the share of orders that failed. It fits when orders stopped altogether or in part, not when they were only slower.
How Operanse catches it
An uptime monitor checks that pages load, and an error tracker looks for crashes. Neither notices that orders have stopped. Operanse learns how many orders this store usually takes at each hour of each day, so no orders for fifteen minutes at 09:30 on a Tuesday is unusual, where it would not be at 03:00.
Operanse also records changes such as plugin updates and settings saves, with who made them. That is why the alert could point to the 09:12 update instead of only reporting that orders had dropped.
Operanse compares each store’s activity with its own history and groups related anomalies into incidents. Playback, the replay above, is on Monitor and Insight; Insight adds server monitoring and an AI review of the likely cause, with its evidence. How Operanse monitors a WooCommerce store.