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 inFAILEDstatus during the last 24 hours, pooled across every site in the realm.FAILEDalmost 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. 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% |
- 63 failed orders against a normal baseline of ~8 per day is the alert. The
>5trigger 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. - First move is to read 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.
- 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.
- 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 | 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 | 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) | 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 | 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 | 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 | 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 likehttps://<realm>.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, not here. - Order Search filtered to
CREATED/NEW: stuck-but-not-failed orders, counted by Pending Orders (created/new/open). - Custom Log Center / WebDAV logs: payment-cartridge error logs, the right place to read the gateway error string, but not an order count.
| 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 doesFAILED 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 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.