Payment Status Distribution, Salesforce Commerce Cloud

Payment Status Distribution, the share of orders by payment status. The finance team’s read on how cleanly money is being captured. How to read it, why it matters, and how to act on it.

Metrics type: Supporting Metrics • Category: Ecommerce Platform

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%

Three things to notice:

1. 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.
2. 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 siteId and 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.
3. 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.
4. 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 like https://<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 be OPEN and paid, or OPEN and 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.

Why our number may legitimately differ from Business Manager:

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 B2B siteId 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.

---

Tracked live in Vortex IQ Nerve Centre

Payment Status Distribution 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 or book a demo to see this metric running on your own data.