> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Failed Orders (24h), Salesforce Commerce Cloud > Failed Orders (24h), orders stuck in FAILED status in the last day. A live tripwire for payment-gateway and fraud-screening breakage. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Orders stuck in FAILED status in the last day. A live tripwire for payment-gateway and fraud-screening breakage. ## At a glance > A live count of Salesforce Commerce Cloud (SFCC, formerly Demandware) orders that landed in `FAILED` status during the last 24 hours, pooled across every site in the realm. `FAILED` almost always means a payment-gateway error or a fraud-screening rejection broke the order before it could be confirmed. A non-trivial number here is lost, recoverable revenue: each failed order is a shopper who tried to buy and could not. | | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(orders WHERE status = FAILED)` placed in the trailing 24-hour window, across every `siteId` and locale in the realm. SFCC sets `status = FAILED` when an order cannot complete, most commonly a declined or errored payment authorisation or a fraud-screening hard-reject. | | **Why it matters** | This is a tripwire, not a trend. A baseline of a handful per day is normal noise (genuine declines, fraud blocks). A sudden jump means something broke: an expired PSP credential, a gateway outage at CyberSource / Adyen / PayPal, a misconfigured 3-D Secure flow, or a fraud-rule deploy that is rejecting good customers. Every failed order above baseline is recoverable revenue if caught fast. | | **Reading the value** | A single KPI number. Lower is better. Read it against the realm's own normal baseline, not an absolute target. Spikes matter far more than the level. | | **Failed vs cancelled** | `FAILED` is a hard, usually system-driven failure at checkout (payment / fraud). `CANCELLED` is a deliberate void of an order, by a shopper, a CS agent, or a clean-up job. See [Cancellation Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/cancellation-rate). The two are adjacent: a gateway outage shows here first, then as cancellations when jobs void the stuck orders. | | **Common causes** | Expired or rotated PSP API credentials in a LINK cartridge; a payment-gateway outage; a 3-D Secure / SCA misconfiguration; an over-tightened fraud rule; a deploy regression in the checkout controller or a payment cartridge. | | **Currency** | n/a, this is an order count. Failures are pooled across every currency and locale on the realm. | | **Channels / sources** | **Multi-site by design.** A credential or gateway problem usually hits every site that shares a PSP configuration at once, so a realm-wide spike with a single shared PSP is the classic signature. Per-site filtering localises the blast radius. | | **Unit** | Number | | **Time window** | `24H` (trailing 24 hours, real-time) | | **Alert trigger** | `>5`, driven by `sentiment_key: scc_failed_orders_24h` | | **Sentiment key** | `scc_failed_orders_24h` | | **Roles** | owner, operations, engineering | ## Calculation Calculated automatically from your Salesforce Commerce Cloud 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 Fortune-500 fashion retailer running on Salesforce Commerce Cloud B2C, four DTC sites and one B2B portal, all DTC sites sharing a single CyberSource PSP via a LINK cartridge. The window is the trailing 24 hours ending 12 Apr 26 09:00 UTC. Statuses read via SCAPI / OCAPI and confirmed in Business Manager Order Search. | `siteId` | Site / locale | PSP | Orders (24h) | Orders `FAILED` | Failed rate | | -------------- | ---------------- | --------------- | ------------ | --------------- | ----------- | | `RefArch-US` | US DTC, en\_US | CyberSource | 6,140 | 38 | 0.6% | | `RefArch-UK` | UK DTC, en\_GB | CyberSource | 2,080 | 14 | 0.7% | | `RefArch-DE` | DE DTC, de\_DE | CyberSource | 1,390 | 9 | 0.6% | | `RefArch-JP` | JP DTC, ja\_JP | Adyen | 950 | 2 | 0.2% | | `RefArch-B2B` | B2B trade portal | Invoice / terms | 47 | 0 | 0.0% | | **Realm-wide** | | | **10,607** | **63** | **0.6%** | Three things to notice: 1. **63 failed orders against a normal baseline of \~8 per day is the alert.** The `>5` trigger fires, but the level alone is not the diagnosis: the shape across sites is. Every CyberSource site is elevated (US, UK, DE all near 0.6 to 0.7%) while the Adyen site (JP) and the invoice-based B2B portal are clean. **The shared PSP is the common factor**, this is the textbook signature of a CyberSource credential or gateway problem, not a site-specific bug. 2. **First move is to read [Payment Status Distribution](/nerve-centre/kpi-cards/salesforce-commerce-cloud/payment-status-distribution).** If the not-paid / authorisation-error share jumped on the CyberSource sites at the same timestamp, the failure is at the authorisation step. Check, in order: the PSP credential expiry in the LINK cartridge, the CyberSource status page for an outage, and the last checkout / payment-cartridge deploy. SFCC deploys via Code Replication often take effect at 02:00 UTC, so a spike that started overnight points at the latest release. 3. **Failed orders are recoverable.** Unlike a refund, a failed order is a shopper who wanted to buy. Once the root cause is fixed, an abandoned-cart or payment-retry flow can recover a meaningful share within 24 to 48 hours, but only if the failure is caught fast. That is exactly why this is a 24-hour real-time hero card rather than a 30-day trend. 4. **The B2B portal shows zero because it does not run card payment.** Invoice / terms-based B2B checkout does not hit a card gateway, so it is structurally immune to PSP failures. A B2B failed order would point at a different problem entirely (an approval-workflow or account-pricing error), worth investigating on its own terms. ## Sibling cards merchants should reference together | Card | Why pair it with Failed Orders (24h) | | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Payment Status Distribution](/nerve-centre/kpi-cards/salesforce-commerce-cloud/payment-status-distribution) | The diagnostic partner. A failed-order spike driven by payment shows as a jump in the not-paid / authorisation-error share. Read them together to confirm the root cause is payment. | | [Cancellation Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/cancellation-rate) | The adjacent failure mode. A gateway outage shows here first, then converts to cancellations when scheduled jobs void the stuck orders. | | [Pending Orders (created/new/open)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/pending-orders-creatednewopen) | A gateway problem can also leave orders stranded in `CREATED` rather than `FAILED`. If failures are flat but pending is climbing, the failure mode is "stuck" not "rejected". | | [Order Processing Backlog](/nerve-centre/kpi-cards/salesforce-commerce-cloud/order-processing-backlog) | The realm-wide alert that fires when the unfulfilled pool blows out. A failed-order spike often precedes a backlog alert by a few hours. | | [Total Orders](/nerve-centre/kpi-cards/salesforce-commerce-cloud/total-orders) | The base rate. 63 failures means something different on a 10k-order day than on a 500-order day. Read the failed count against order volume. | | [Conversion Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/conversion-rate) | A payment or fraud failure depresses conversion at the final checkout step. A conversion dip with a failed-order spike confirms the leak is at payment, not earlier in the funnel. | ## Reconciling against Salesforce Commerce Cloud **Where to look in Business Manager:** SFCC's admin tool is **Business Manager**, reached at a per-realm URL like `https://.business.demandware.net`. To verify this card, go to **Merchant Tools, Ordering, Order Search**, filter **Status = Failed** and set the date range to the last 24 hours for a single site, then repeat per site or use a multi-site read if your role allows it. For payment-level detail, open an individual failed order and inspect its **Payment** tab to see the authorisation response from the PSP. Other Business Manager views that *look* like the same number but aren't: * **Order Search filtered to `CANCELLED`**: deliberate voids, counted by [Cancellation Rate](/nerve-centre/kpi-cards/salesforce-commerce-cloud/cancellation-rate), not here. * **Order Search filtered to `CREATED` / `NEW`**: stuck-but-not-failed orders, counted by [Pending Orders (created/new/open)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/pending-orders-creatednewopen). * **Custom Log Center / WebDAV logs**: payment-cartridge error logs, the right place to read the gateway error string, but not an order count. **Why our number may legitimately differ from Business Manager:** | Reason | Direction of divergence | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | | **Window boundary**. This card is a strict trailing 24 hours; Business Manager Order Search uses a calendar date range. The two windows rarely line up exactly. | Either, at the boundary | | **Time-zone**. Business Manager runs in the site's configured time zone; Vortex IQ runs on UTC by default. | Boundary failures shift sites | | **Site filter scope**. Business Manager defaults to the currently-selected site; Vortex IQ pools every site unless filtered. | Vortex IQ higher than a per-site view | | **Real-time lag**. SCAPI / OCAPI is near-real-time; if a job re-processes or re-statuses an order, the count can move slightly between reads. | Small, transient | | **Custom failure statuses**. Some realms add custom statuses for specific failure modes; if a failure is filed under a custom status, Business Manager reports it separately. | Vortex IQ may read lower until mapped | | **Order export lag**. SFCC's Reports & Dashboards warehouse runs 5 to 30 minutes behind; if you reconcile against a report rather than Order Search, expect lag. | Report lower than this card for current data | ## Known limitations / merchant FAQs **What does `FAILED` actually mean on an SFCC order?** SFCC sets `status = FAILED` when an order cannot be completed, overwhelmingly because a payment authorisation was declined or errored, or a fraud-screening rule hard-rejected it. It is distinct from `CANCELLED` (a deliberate void) and from `CREATED` / `NEW` (a stuck-but-not-failed order). Open any failed order's Payment tab in Business Manager to read the actual PSP response string. **A few failed orders a day is normal, right?** Yes. A baseline of genuine declines (insufficient funds, expired cards) and fraud blocks is healthy and expected. This card is a tripwire for the *spike*, not the level. Set the alert relative to your realm's normal baseline; the `>5` default is a starting point, raise it if your healthy baseline is higher. **My failed orders just spiked. What do I check first?** In order. (1) **PSP credentials**, an expired or rotated API key in a CyberSource / Adyen / PayPal LINK cartridge is the single most common cause. (2) **Gateway outage**, check the PSP's status page. (3) **Recent deploy**, SFCC Code Replication often lands at 02:00 UTC; if the spike started overnight, look at the latest checkout or payment-cartridge release. (4) **Fraud-rule change**, an over-tightened rule rejects good customers. [Payment Status Distribution](/nerve-centre/kpi-cards/salesforce-commerce-cloud/payment-status-distribution) tells you fast whether the failure is at the authorisation step. **How is this different from Cancellation Rate?** `FAILED` is a hard, usually system-driven failure at checkout; `CANCELLED` is a deliberate void. They are adjacent failure modes: a gateway outage shows up here first, then as a wave of cancellations a few hours later when scheduled jobs void the stuck orders. Watch both, and treat a failed-order spike as the leading indicator. **Are failed orders recoverable revenue?** Often, yes. Unlike a refund, a failed order is a shopper who tried to buy and could not. Once the root cause is fixed, abandoned-cart and payment-retry flows can recover a meaningful share within 24 to 48 hours. The window is short, which is why this is a real-time hero card. **Does this include B2B orders?** Yes, by data model, but B2B portals that run on invoice / terms-based checkout never hit a card gateway and so are structurally immune to PSP failures. A B2B failed order points at a different problem (an approval-workflow or account-pricing error) and is worth investigating separately. **Why does the count differ slightly from Business Manager?** Three usual reasons. (1) **Window**, this card is a strict trailing 24 hours while Business Manager Order Search uses a calendar range. (2) **Time-zone**, Business Manager uses site-local time, the card uses UTC. (3) **Site-scope**, Business Manager defaults to one site, the card pools the realm. Confirm all three before treating a gap as an error. *** ### Tracked live in Vortex IQ Nerve Centre *Failed Orders (24h)* is one of hundreds of KPI pulses Vortex IQ tracks across Salesforce Commerce Cloud 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.