Checkout failures are silent until they are expensive
WooCommerce does not send you a digest of failed orders. Customers rarely report them either: most people abandon the cart and buy from someone else. By the time you notice a revenue dip in your analytics, dozens of orders may have already failed.
When something does break at checkout, it almost never breaks across every gateway at once. A plugin update breaks one payment method. A gateway credentials rotation breaks another. Without grouping failures by gateway and by day, you are staring at a raw list of failed orders with no obvious signal.
What most people do
A better way: diagnose in seconds, change nothing
TrueCommander's detect checkout issues command scans your failed orders, groups them by payment gateway and by day, and surfaces the internal notes that gateways write when a payment is declined. One command, no dashboard to configure, no plugin to install.
Completely read-only. detect checkout issues only reads order data. It does not change order statuses, retry payments, or touch any setting. You get the diagnosis without any risk of touching live orders.
How it works
wc-failed orders within the lookback window and groups the count by payment method and by calendar day. A spike on one gateway on one day is immediately visible.-include_pending=true It also scans wc-pending orders older than -pending_stale_hours. Those are almost always payments where the gateway redirect succeeded but the webhook never confirmed. They look paid to the customer but unpaid to WooCommerce.| Parameter | What it does |
|---|---|
-days | Analyze failed orders from the last N days. Default 7, max 90. |
-limit | Maximum number of failed orders to scan. Default 200, max 1000. Raise this on high-volume stores. |
-include_pending | When true, also scans wc-pending orders to flag any that are stuck. Default false. |
-pending_stale_hours | How old a wc-pending order must be before it is flagged as stuck. Default 2, max 720. Raise this for gateways that legitimately take longer to confirm. |
| Can be used in |
Real example
On a Tuesday you notice the previous day's revenue was lower than usual. Nothing looks broken, no one complained, the site is up.
You run tp detect checkout issues -days=3. The output shows 31 failures on Stripe and only 7 on PayPal. The Stripe failures all cluster on Monday, and the latest order note reads "3DS verification failed." The PayPal failures are spread evenly across all three days, which is normal baseline noise for a store that size.
You trace the Stripe spike to a WooCommerce Stripe plugin update deployed Monday morning. The update changed the 3DS flow in a way that broke returning customers on mobile. You roll back the plugin, run the command again, and the failure rate drops back to baseline within the hour. No support ticket, no digging through server logs, no guessing.
Goes further with TrueCommander
detect checkout issues on a morning schedule so you see yesterday's failure summary before you open anything else. Catch problems the same day they start.detect checkout issues with send api in a macro to post a Slack or email alert the moment a gateway failure count crosses your threshold.filter orders to pull the exact order list and inspect individual records, customers, and amounts.