Share of orders by payment status. The finance team’s read on how cleanly money is being captured.
At a glance
A donut breakdown of Salesforce Commerce Cloud (SFCC, formerly Demandware) orders by their payment status, paid, authorised, part-paid, not-paid, over the period, pooled across every site in the realm. SFCC tracks payment on each order through payment instruments and a payment status, and this card rolls those into a share view. It is the finance team’s read on how cleanly money is moving from checkout to captured funds, and a fast way to spot a PSP or capture problem.
| What it counts | The share of orders in each payment status over the window: typically paid (captured), authorised (held but not yet captured), part-paid (partial capture or multi-instrument), and not-paid. Pooled across every siteId and locale. SFCC derives these from each order’s payment instruments and the responses from the payment service provider (PSP). |
| Why it matters | The mix is a health read. A healthy realm is dominated by paid / captured. A growing authorised-but-not-captured share can mean a stuck capture job or a deliberate auth-then-capture-on-ship flow; a growing not-paid share is an early payment-friction or PSP signal. Finance uses this to confirm money is being captured, not just authorised. |
| Reading the value | A donut by share. There is no single “good” number, the shape is what matters, and a shift in shape period over period is the signal. Read it alongside Failed Orders (24h) when the not-paid slice grows. |
| Where the statuses come from | SFCC orders carry one or more payment instruments (card, PayPal, gift card, store credit) processed through PSP LINK cartridges (CyberSource, Adyen, PayPal, Worldpay). The order’s payment status reflects the aggregate of those instruments: fully captured, authorised, partially settled, or unpaid. |
| Authorise vs capture | Many SFCC implementations authorise at checkout and capture at ship. During that gap an order sits authorised, not paid, which is normal, not a fault. A persistently large authorised slice that never converts to paid is the real warning. |
| Currency | n/a, this is a share of order counts. The breakdown pools orders across every currency and locale on the realm. |
| Channels / sources | Multi-site, multi-PSP by design. Different sites can run different PSPs, and B2B portals often use invoice / terms rather than card capture, which shows as a distinct not-paid-but-healthy pattern. Per-site filtering separates a card-capture problem from a B2B invoice flow. |
| Unit | Number (rendered as share of orders) |
| Time window | 30D (trailing 30 days) |
| Alert trigger | none configured |
| Sentiment key | scc_payment_status_breakdown |
| Roles | owner, finance |
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 on CyberSource / Adyen plus one B2B portal on invoice terms. The 30-day window covers 14 Mar 26 to 12 Apr 26. Payment statuses derived from order payment instruments and PSP responses, confirmed in Business Manager.| Payment status | Orders | Share | Typical meaning |
|---|---|---|---|
| Paid (captured) | 268,900 | 84.4% | Funds captured, money in the bank |
| Authorised (not yet captured) | 31,200 | 9.8% | Held at checkout, captures on ship (auth-then-capture flow) |
| Part-paid | 9,600 | 3.0% | Multi-instrument (e.g. gift card + card) or partial capture |
| Not paid | 8,720 | 2.7% | Awaiting payment, B2B invoice terms, or genuine friction |
| Realm-wide | 318,420 | 100% |
- The 9.8% authorised slice is not a problem, it is the fulfilment flow. This realm authorises at checkout and captures at ship, so any order placed but not yet shipped sits authorised. The size of the slice tracks the size of the unfulfilled pool, see Pending Orders (created/new/open). The warning sign is not the slice existing, it is the slice growing without the pending pool growing, which would mean captures are failing to fire on ship.
- Most of the 2.7% not-paid is the B2B portal, by design. B2B trade orders on invoice / terms are legitimately unpaid at order time and settle later through finance, not a card gateway. Filter out the B2B
siteIdand the DTC not-paid share drops well under 1%. A DTC not-paid share that climbs is the real signal, that is friction at the card step, and the first place to look is Failed Orders (24h) and the PSP credentials. - Part-paid (3.0%) is mostly multi-instrument checkout. Gift-card-plus-card and store-credit-plus-card orders settle across two instruments and show as part-paid until both clear. This is normal for a brand with an active gift-card programme. A sudden jump would point at a capture problem on one instrument type, worth a look at the relevant cartridge.
- No alert is configured on this card, and that is deliberate. The mix is contextual: the “right” shape depends on whether the realm captures at checkout or at ship, how much B2B invoice volume it carries, and how big its gift-card programme is. Finance reads the shape and its period-over-period drift rather than waiting for a threshold. Pair it with Total Orders to read slices as absolute counts when sizing a capture problem.
Sibling cards merchants should reference together
| Card | Why pair it with Payment Status Distribution |
|---|---|
| Failed Orders (24h) | The acute version of the same signal. A growing not-paid slice and a failed-order spike are two views of the same PSP or capture problem; read them together to confirm. |
| Pending Orders (created/new/open) | The authorised slice tracks the unfulfilled pool in an auth-then-capture flow. If authorised grows while pending stays flat, captures are failing on ship. |
| Cancellation Rate | Orders stuck not-paid often end up cancelled by a clean-up job. A rising not-paid share frequently precedes a cancellation rise. |
| Total Orders | The denominator. Read each payment-status share as an absolute order count when sizing the financial impact of a capture gap. |
| Total Revenue | Revenue is booked at order time but cash is captured at payment. This card tells you how much booked revenue has actually become captured funds. |
| Refund Rate | The post-capture money-out layer. Payment status is money-in; refund rate is money-back. Together they frame the full cash picture for finance. |
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 and use the payment-status filters, or open individual orders and inspect the Payment tab, which shows each payment instrument, its authorisation, and its capture state from the PSP. For a settlement view, reconcile against the PSP’s own back office (the CyberSource Business Center, Adyen Customer Area, or PayPal dashboard).
Other Business Manager views that look like the same number but aren’t:
- Reports & Dashboards, Sales: revenue booked, not a payment-status breakdown. Revenue books at order time regardless of capture state.
- Order status (
OPEN,COMPLETED, etc.): the fulfilment lifecycle, a different axis from payment status. An order can beOPENand paid, orOPENand authorised. - PSP back-office settlement reports: the processor’s own capture / settlement view, the right tool to reconcile captured cash but on the PSP’s timing, not SFCC’s.
| Reason | Direction of divergence |
|---|---|
| Status taxonomy. SFCC’s raw payment-status values vary by version and by how each PSP cartridge maps responses; this card groups them into paid / authorised / part-paid / not-paid. A Business Manager raw-status read uses finer-grained values. | Grouping difference, not a true gap |
| Capture timing. The paid vs authorised split depends on when capture fires (checkout vs ship). A read taken mid-fulfilment-cycle shows a larger authorised slice than one taken after captures complete. | Either, by timing |
| Site filter scope. Business Manager defaults to the currently-selected site; Vortex IQ pools every site unless filtered. B2B invoice volume skews the not-paid slice. | Direction depends on per-site mix |
| Multi-instrument orders. An order paid part-gift-card-part-card is one SFCC order but two instruments; how it is bucketed (part-paid vs paid) depends on instrument settlement state. | Small, on the part-paid slice |
| Time-zone. Business Manager uses the site’s configured time zone; Vortex IQ runs on UTC by default. | Boundary days shift |
| Export lag. SFCC’s Reports & Dashboards warehouse runs 5 to 30 minutes behind; SCAPI / OCAPI is near-real-time. | Report lags this card |
Known limitations / merchant FAQs
What payment statuses does SFCC track and how are they grouped here? SFCC derives an order’s payment status from its payment instruments and the PSP responses. The raw values vary by API version and by how each PSP cartridge maps its responses, so this card groups them into four readable buckets: paid (captured), authorised (held but not captured), part-paid (partial or multi-instrument), and not-paid. Open an order’s Payment tab in Business Manager to see the raw per-instrument detail. Is a large authorised slice a problem? Usually not. Many SFCC merchants authorise at checkout and capture at ship, so every placed-but-unshipped order sits authorised. The slice tracks the size of your unfulfilled pool, see Pending Orders (created/new/open). The warning sign is the authorised slice growing while pending stays flat, which means captures are not firing on ship. Why is my not-paid share higher than I expected? The most common reason is B2B. Trade orders on invoice / terms are legitimately unpaid at order time and settle later through finance, not a card gateway, so a realm with a B2B portal carries a structural not-paid slice. Filter out the B2BsiteId to see the DTC-only not-paid share, which should be small. A climbing DTC not-paid share is genuine payment friction, check Failed Orders (24h) and your PSP credentials.
Why is there no alert on this card?
Because the “right” mix is contextual: it depends on whether you capture at checkout or at ship, how much B2B invoice volume you carry, and how active your gift-card programme is. A fixed threshold would fire constantly on a healthy realm. Finance reads the shape and its period-over-period drift instead. You can add a per-card alert on the not-paid slice if your flow makes that meaningful.
How does this relate to revenue?
Revenue books at order time; cash is captured at payment. Total Revenue tells you what was sold; this card tells you how much of that has actually become captured funds versus still sitting authorised or unpaid. The gap between the two is the auth-then-capture float plus any genuine payment friction.
My PSP back office shows different captured totals. Who is right?
They measure different things on different clocks. SFCC’s payment status reflects the order’s view of its instruments; the PSP back office reflects settled funds on the processor’s settlement timing, which lags capture. Reconcile SFCC against the PSP for captured cash, but expect a timing gap, not an exact match, especially within the last 24 to 48 hours.
Does a multi-instrument order (gift card plus card) distort the breakdown?
A little. Such an order is one SFCC order settled across two instruments, and until both clear it reads as part-paid. A brand with an active gift-card or store-credit programme carries a structural part-paid slice. A sudden jump in part-paid points at a capture problem on one instrument type, worth checking the relevant cartridge.