Orders with status=failed / total. Spikes = payment gateway misconfig, fraud rule too aggressive, or 3DS challenge breakage. Check gateway logs first.
At a glance
The percentage of order attempts in the period that ended in failed status. The leading indicator for payment-gateway issues, fraud-rule misconfiguration, or 3DS friction.
| What it counts | COUNT(orders WHERE status = 'failed') / COUNT(orders WHERE status IN ('completed', 'processing', 'failed', 'cancelled')) x 100. Each failed-payment attempt is one order row in WC. |
| REST API endpoint | GET /wp-json/wc/v3/orders?status=failed, plus the broader status set for the denominator. |
| VAT / tax treatment | Currency- and tax-agnostic count ratio. |
| Status filter | Numerator is failed only. Denominator is “real attempts” = completed + processing + failed + cancelled. pending (cart skeletons) and on-hold (waiting for offline payment) are excluded so that the rate measures payment-gateway success specifically. |
| Shipping / discounts | Not applicable (count metric). |
| Refunds | Not applicable; failed orders never charged. |
| Cancelled orders | Counted in the denominator but not the numerator. Cancellations are merchant / customer choice; failures are technical. |
| Currency | Currency-agnostic ratio. |
| Channels / sources | Not filtered. Web-checkout and REST-API-created orders both count. POS plugin orders rarely fail because the in-person card-present flow has different gateway settings. |
| Self-hosted vs managed-Woo | Same definition. Self-hosted Woo with custom payment gateway plugins shows higher noise (less battle-tested code paths). Managed-Woo on the WC Stripe Gateway typically runs < 1% failure. |
| Time window | T/7D vsP |
| Alert trigger | >3% rate, or +50% vsP |
| Roles | owner, operations |
Calculation
Calculated automatically from your WooCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK fashion brand on self-hosted Woo (Bluehost shared hosting), running WC Stripe Gateway with 3DS Strong Customer Authentication enforced. Period: 5 Apr 26 to 11 Apr 26 (7D), versus prior 7D.| Status | Count | Note |
|---|---|---|
completed | 412 | Paid + fulfilled |
processing | 92 | Paid, awaiting fulfilment |
failed | 38 | Gateway returned an error or 3DS timed out |
cancelled | 14 | Customer-initiated, abandoned |
| Denominator | 556 |
- The cause is almost certainly external, not Woo. A jump of this size in 7 days is rarely a Woo-side bug. Common culprits: (a) a 3DS configuration drift, the merchant’s bank rolled out new SCA challenge logic that started failing legitimate cards; (b) a fraud-rule plugin (e.g. Stripe Radar) tuned too aggressively after a fraud event; (c) a payment-gateway plugin update with a regression. Check Stripe Dashboard → Logs first.
- Self-hosted server slowness contributes. This brand’s Bluehost shared host had elevated response times (P95 > 8s) for 3 days during the spike. WC’s checkout flow is synchronous, slow server = checkout timeout =
failedstatus. Managed-Woo hosts rarely show this pattern. The SREs at Bluehost confirmed a noisy-neighbour issue on 8-9 Apr 26. failedis a Woo-specific edge case. Other platforms call this “abandoned at payment” or “declined”. WC explicitly storesfailedas a separate status that the gateway sets when authorisation fails. If your gateway plugin does not setfailedcorrectly (some legacy plugins leave the order inpendinginstead), this card under-reports. Check the gateway plugin docs.- Plugin-induced data shape variance is real. Stripe Gateway sets
failed. PayPal Standard rarely does (it leaves the order inpending). Authorize.Net plugin behaves like Stripe. Square WC plugin setsfailedonly on declined-card events, not on timeouts. So the absolute rate depends on which gateway sets which status when. Use the Payment Methods card to check the gateway mix.
Sibling cards merchants should reference together
| Card | Why pair it with Failed Order Rate |
|---|---|
| WC Alert: Failed Order Spike | The trigger card. Pairs with this one for the alert chain. |
| WC Total Orders | The denominator size. A 6% rate on 50 orders is 3 failures (noise); on 5,000 orders it is a real outage. |
| WC On-Hold Orders | Companion failure mode. On-hold are payment-pending, not failed. Different fixes. |
| WC Payment Methods | Tells you which gateway is failing. Stripe-Gateway-specific spikes look very different from PayPal Standard misconfigurations. |
| WC Conversion Rate | Orders per session. A failed-order spike often shows up as a conversion-rate dip first. |
| BC Failed Orders Count | Cross-platform peer for agencies. |
| Stripe Decline Rate | The Stripe-side view of the same events. Useful for root-causing. |
Reconciling against the vendor’s own dashboard
Where to look in WooCommerce Admin: WP Admin → WooCommerce → Orders filtered to statusfailed. WC does not expose a built-in failure-rate report; the standard reports (/wp-admin/admin.php?page=wc-reports) skip failed entirely. The reliable counts come from the gateway side, Stripe Dashboard → Payments → Failed.
Other WP Admin views that look like the same number but are not:
- WP Admin → Reports → Sales by date: excludes
failedfrom both numerator and denominator. Will not show this rate. - Stats overview widget: shows total revenue only.
| Reason | Direction of divergence |
|---|---|
| Time-zone. WC stores order timestamps in WP-site timezone; Vortex IQ on UTC. | Boundary-day effects |
Self-hosted server uptime. Slow / unreachable WP server = customer-initiated retry = duplicate failed rows. | Ours higher during outages |
Plugin-version compatibility. Some gateways do not set failed and leave the order in pending. | Ours under-reports |
Gateway plugin idempotency bugs. A retry that succeeds the second time can leave behind a failed skeleton from the first attempt. | Ours slightly higher |
Currency plugin behaviour. Currency switches mid-checkout can produce bogus failed rows. | Rare; investigate per-merchant |
| Card | Expected relationship | Causes of divergence |
|---|---|---|
stripe.stripe_decline_rate | Stripe rate >= WC rate for Stripe-only stores | Stripe sees every authorisation attempt including ones the WC plugin does not record (e.g. when checkout aborts client-side after Stripe Elements returns an error). Stripe rate typically sits 0.5-2 ppt above this card. |
Known limitations / merchant FAQs
Self-hosted vs managed-Woo, why does it matter for failure rate? Self-hosted Woo on shared hosting introduces a structural failure path: a slow server can cause the customer’s payment to be authorised by the gateway but the WC callback to time out, leaving the order infailed even though the card was charged. Managed-Woo hosts (Woo.com Cloud, WP Engine) rarely show this. If your failure rate exceeds 3% and your gateway logs show successful authorisations for the same orders, host capacity is the cause.
Status-filter selection, why exclude pending and on-hold from the denominator?
pending is cart skeletons (no payment attempted). on-hold is BACS / bank transfer (no card transaction). Neither involves a gateway call, so neither belongs in the failure-rate denominator. The metric is “of attempts that called a payment processor, what share failed”.
Refund-object accounting, does it affect this card?
No, refunds happen post-success; this card is pre-success. The two metrics are orthogonal.
Plugin-induced data shape variance, what gateways set failed correctly?
- WC Stripe Gateway: yes, sets
failedon declined cards and 3DS timeouts. - WC PayPal Standard / Payments: inconsistent; many failures stay in
pending. - WC Square: sets
failedon declines, leaves timeouts inpending. - Authorize.Net for WC: yes, sets
failed. - Klarna / Afterpay plugins: set
failedon rejection, leave underwriting-review inon-hold. - BACS / Cheque / Direct Bank Transfer: never sets
failed; useson-hold.
failed orders re-process and flip to processing after the host recovers; the rate self-heals.
My WP Admin shows different counts, debug playbook:
- Match date range, ensure timezone alignment.
- Verify the Vortex IQ indexer last-poll time. If recent, the data is fresh.
- Check whether your gateway plugin sets
failedconsistently (see plugin list above). - Cross-check Stripe Dashboard. If Stripe shows N successful auths but WC shows N + 5 failed orders, you likely have a host-timeout issue producing duplicate failed shells.