Lost revenue from declined / voided payments. The sum of order totals on failed orders.
At a glance
The total order value of orders in the period whose payment did not capture, declines, voided authorisations, and gateway errors. This is the money that would have banked had the payment gone through. It is the value counterpart of Failed Orders Count, and it represents recoverable revenue rather than money you ever held.
| What it counts | The sum of order totals (totalPrice) across orders in the window whose payment outcome is a failure rather than a successful capture. It is the would-have-been revenue, not money received. |
| VAT / tax treatment | Follows the order’s taxesIncluded mode, the same as the gross Total Revenue card. The summed totals are whatever the customer would have been charged, VAT-inclusive for inclusive-tax stores, ex-tax for exclusive-tax stores. |
| Shipping | Included. totalPrice already contains the shipping the customer would have paid. |
| Discounts | Already applied. The value summed is the post-discount total the customer attempted to pay. |
| Refunds | Distinct concept. Refund value is money captured then returned. Failed-orders value is money never captured. The two never overlap. |
| Cancelled / voided orders | A voided authorisation’s order total is included here. A merchant-cancelled order that had already been paid belongs to the cancellation cards, not this one. |
| Currency | Multi-currency arithmetic sum WITHOUT FX conversion. A store with failed GBP and EUR orders gets a single blended figure; filter by currency for a clean per-currency number. |
| Channels / sources | Not filtered. Failed captures on any channel that takes payment contribute their order total. |
| Time window | 30D (default 30D rolling) |
| Alert trigger | Configurable. A sudden rise in failed value, especially concentrated on a few high-value orders, often signals a gateway incident or fraud-filter problem. |
| Roles | owner, operations, finance |
Calculation
Worked example
The same UK electronics store as the count card, Shopify Plus, Shopify Payments plus PayPal Express. The 30-day window covers 14 Mar 26 to 12 Apr 26. There were 91 failed orders in the window.| Failure reason | Failed orders | Failed value | Note |
|---|---|---|---|
| Card declined (insufficient funds) | 38 | £3,420 | Low-value baskets; many retry successfully |
| Card declined (issuer fraud block) | 21 | £2,990 | Spread across normal baskets |
| 3-D Secure not completed | 17 | £2,210 | Mid-value; recoverable with smoother checkout |
| Gateway / processor error | 6 | £4,180 | Two of these were large orders during a processor incident |
| Voided authorisation (fraud-filter cancel) | 9 | £6,300 | High-value orders your own rules cancelled |
| Failed Orders Value (this card) | 91 | £19,100 | Roughly 0.9% of the period’s captured revenue |
- Value and count tell different stories. The 38 insufficient-funds declines are the largest count but the smallest value. The 9 fraud-filter voids are a small count but the largest value (£6,300), because high-value orders trip risk rules more often. Prioritise recovery by value, not by count.
- The £4,180 gateway-error cluster is the recoverable headline. Two large orders failed during a two-day processor incident. Had the gateway been healthy, that money banks. This is the clearest case for a follow-up payment link to those specific customers.
- Not all of this is truly lost. A portion of failed orders self-recover when the customer retries on another card, so the £19,100 is the gross recoverable pool, not a confirmed loss. The realistic recoverable share is the gateway errors, fraud-filter false positives, and a slice of the SCA drop-off. Use it to size the opportunity, then act on the high-value cases first.
Sibling cards merchants should reference together
| Card | Why pair it with Failed Orders Value |
|---|---|
| Failed Orders Count | The count version. Value over count gives the average failed-order size; high averages mean a few big orders dominate. |
| Financial Status Breakdown | The full distribution of payment states by value; failed value is one slice. |
| Revenue by Payment Gateway | Cross-check which gateway carries the failed value against which carries captured revenue. |
| Payment Methods | Failure value concentrated in one method points at that processor. |
| Total Revenue | The captured headline; failed value as a percentage of it sizes the leakage. |
| Revenue at Risk (live incident) | When failed value spikes during a live gateway incident, this is the real-time companion. |
Reconciling against Shopify Admin
Where to look in Shopify Admin: Orders → filter to unpaid or voided payment states, then read the order totals. Shopify has no single report that sums failed-order value directly, so the manual reconstruction is to export the filtered orders and sum their totals. Shopify Payments stores can cross-reference Finances → Payouts transaction exports, where declined and voided attempts appear with their amounts. Other Shopify Admin views and why they differ:- Finances → Summary: reports captured sales and tax, not failed-capture value.
- Abandoned checkouts: shows potential value of carts that never became orders, a different earlier stage.
- Shopify Payments → Disputes: value of chargebacks on captured payments, a later stage.
| Reason | Direction | Why |
|---|---|---|
| State definition | Either | The card groups declined and voided outcomes. Stores using pending heavily (net terms, manual payment) must exclude those by hand when reconciling. |
| Multi-currency | Ours blended | The card sums order currency without FX; Shopify converts to shop currency. |
| Time zone | Boundary days | UTC vs store time zone shifts orders on the boundary days. |
| Self-recovery | Either | A failed attempt that later succeeded may still carry a failed order record; whether its value lingers depends on the checkout flow. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_failed_payments_value | Stripe-routed failed value aligns with the Shopify Payments slice | Stripe sees only its own declines; PayPal and other gateways fail elsewhere. |
paypal.pp_declines_value | PayPal-checkout failed value aligns with the PayPal slice | PayPal and Shopify Payments failures are invisible to each other; sum gateways for the full pool. |
Known limitations / merchant FAQs
Is this money I have actually lost? Not all of it. It is the value that would have banked had the payment captured. A portion self-recovers when customers retry on another card, so treat the figure as the gross recoverable pool, not a confirmed loss. The genuinely recoverable slice is gateway errors, fraud-filter false positives, and part of the SCA drop-off. Why is the value high but the count low (or vice versa)? Failure value and failure count diverge because high-value orders trip fraud rules and 3-D Secure more often than small ones. A handful of large voided orders can dominate the value while contributing little to the count. Divide value by count to see the average failed-order size and decide where to focus. Is this the same as refund value? No. Refund value is money you captured and returned. Failed-orders value is money you never captured. They are mutually exclusive. Does it include tax and shipping? Yes. The summed total is the fulltotalPrice the customer attempted to pay, including shipping and (for inclusive-tax stores) VAT, the complete would-have-been order value.
My multi-currency store shows a blended number, why?
The card sums order values without FX conversion. Filter by currency for a clean per-currency failed-value figure.
How should I act on this card?
Sort failed orders by value, highest first. For gateway errors and fraud-filter voids on high-value orders, send a fresh payment link or call the customer. For SCA drop-off, smooth the checkout (enable Shop Pay). For routine insufficient-funds declines, a gentle automated retry prompt is usually enough. The card turns invisible payment leakage into a prioritised recovery list.