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.
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.
Three things to notice:
- 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
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.
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.