Skip to main content
Metrics type: Key Metrics • Category: Ecommerce Platform
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.

​
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.
Versus prior 7D where the rate was 1.4% (8 / 572). The card flags +5.43 ppt rise and trips both the >3% threshold and the +50% vsP threshold. Four things to notice:
  1. 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.
  2. 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 = failed status. Managed-Woo hosts rarely show this pattern. The SREs at Bluehost confirmed a noisy-neighbour issue on 8-9 Apr 26.
  3. failed is a Woo-specific edge case. Other platforms call this “abandoned at payment” or “declined”. WC explicitly stores failed as a separate status that the gateway sets when authorisation fails. If your gateway plugin does not set failed correctly (some legacy plugins leave the order in pending instead), this card under-reports. Check the gateway plugin docs.
  4. Plugin-induced data shape variance is real. Stripe Gateway sets failed. PayPal Standard rarely does (it leaves the order in pending). Authorize.Net plugin behaves like Stripe. Square WC plugin sets failed only 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

​
Reconciling against the vendor’s own dashboard

Where to look in WooCommerce Admin: WP Admin → WooCommerce → Orders filtered to status failed. 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 failed from both numerator and denominator. Will not show this rate.
  • Stats overview widget: shows total revenue only.
Why our number may legitimately differ from gateway logs: Cross-connector reconciliation against Stripe:

​
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 in failed 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 failed on declined cards and 3DS timeouts.
  • WC PayPal Standard / Payments: inconsistent; many failures stay in pending.
  • WC Square: sets failed on declines, leaves timeouts in pending.
  • Authorize.Net for WC: yes, sets failed.
  • Klarna / Afterpay plugins: set failed on rejection, leave underwriting-review in on-hold.
  • BACS / Cheque / Direct Bank Transfer: never sets failed; uses on-hold.
Multi-currency configuration, does it affect failure rate? Currency-agnostic ratio. But: 3DS challenge logic varies by issuer country, EU cards have ~5x higher 3DS friction than US cards. A multi-currency store with EU customer mix structurally runs higher failure than a US-only store. Per-currency failure-rate cards are on the roadmap. Why does WooCommerce and Stripe disagree on failure rate? Stripe sees every authorisation attempt including client-side Stripe Elements errors that never make it to WC (so no WC order row is created). Stripe rate >= WC rate, typically 0.5 to 2 ppt higher. If Stripe shows 8% and WC shows 1%, your Stripe Elements integration is dropping events before WC sees them, contact your developer. Today is jumpy, why? Failure rate is a small-sample ratio. A single host outage during checkout produces a cluster of failures that spike the daily rate. Use 7D rolling. Sync-lag from self-hosted server slowness, debug: If failure rate appears to spike then drop without explanation, check whether the WP host had a brief slowdown. Some failed orders re-process and flip to processing after the host recovers; the rate self-heals. My WP Admin shows different counts, debug playbook:
  1. Match date range, ensure timezone alignment.
  2. Verify the Vortex IQ indexer last-poll time. If recent, the data is fresh.
  3. Check whether your gateway plugin sets failed consistently (see plugin list above).
  4. 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.

​
Tracked live in Vortex IQ Nerve Centre

Failed Order Rate is one of hundreds of KPI pulses Vortex IQ tracks across WooCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.