At a glance
Distribution of orders across Adobe Commerce / Magentostatevalues:new,pending_payment,processing,complete,closed,canceled,holded,payment_review. Critically,stateis the system lifecycle (8 fixed values) whilestatusis a configurable user-facing label. This card usesstatebecause it is comparable across merchants;statusvaries wildly by configuration.
| What it counts | COUNT(orders) GROUP BY state over the rolling 30-day window. Both percentage of total and absolute count exposed. |
| API field | state from the orders index. Adobe Commerce REST: GET /rest/V1/orders returns both state (system) and status (custom label). |
| The 8 Magento states explained | new (just created, payment not initiated), pending_payment (offline payment expected, e.g. bank transfer or net-30 PO), processing (paid, fulfilment in progress), complete (fulfilled and invoiced), closed (refunded in full or fully canceled-after-capture), canceled (cancelled before capture), holded (manually held by Admin, often for fraud review), payment_review (gateway flagged, awaiting decision, e.g. PayPal Pending status). |
| State vs status, why this matters | status can be customised via Stores > Configuration > Sales > Order Status. A merchant can rename processing to “PO Received” or split complete into “Shipped” and “Delivered”. Card data uses state so different merchants are comparable; the merchant’s own admin shows status labels. Bridging requires the status_state_assignments mapping. |
pending_payment is the one to watch | A small steady share is normal (offline payment merchants). A growing share is the gateway-callback failure signature, payment was taken but the success callback to Adobe failed, leaving the order in limbo. See Revenue Drop Alert. |
holded is the manual-fraud-review queue | A growing share suggests fraud rules are firing more (legitimate); a stable share is operational. CS reviews and either promotes to processing or moves to canceled. |
payment_review | Gateway-flagged. PayPal “Pending” status, Stripe risk-review, Authorize.Net review-status. Time-sensitive: most gateways auto-cancel after 24-72 hours if not reviewed. |
| VAT / tax / shipping / discounts / currency | n/a, this is a count-by-state card, not a value card. |
| Cancelled | canceled is one of the 8 states; counted in its own bucket. |
| Multi-store scope | All Store Views by default. |
| Time window | 30D rolling. Real-time view available for incident detection. |
| Alert trigger | None on this card; pair with Cancellation Rate and Revenue Drop Alert for alerting. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Adobe Commerce 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 B2B-leaning industrial-supplies merchant on Adobe Commerce 2.4.7. Snapshot 13 May 26, 30-day rolling. 2,840 orders. State distribution:| State | Count | % | Healthy band | Diagnosis |
|---|---|---|---|---|
new | 4 | 0.1% | <1% | Normal; orders just created, payment about to start |
pending_payment | 184 | 6.5% | 3-8% (B2B) | Within band; mostly net-30 PO accounts awaiting AP approval |
processing | 612 | 21.6% | 15-30% | Healthy; in-fulfilment pipeline |
complete | 1,894 | 66.7% | 60-75% | Healthy steady-state |
closed | 41 | 1.4% | 1-3% | Mostly fully-refunded orders |
canceled | 78 | 2.7% | 1-4% | Within band |
holded | 22 | 0.8% | <1% | Slightly elevated; check fraud-review queue |
payment_review | 5 | 0.2% | <0.3% | Normal |
| Total | 2,840 | 100% |
pending_paymentat 6.5% is on the high side but within B2B norms. B2B accounts often place POs that wait days for AP department approval before payment hits. DTC stores typically run <2% in this state; if a DTC store hit 6.5%, it would be a gateway-callback alarm.holdedat 0.8% is slightly elevated. The fraud-rules-review queue has 22 orders parked. CS should drain this within 48 hours; the cost of a stuckholdedis reputational (legitimate buyer waiting) and operational (fraud window closes after 7 days for most gateways). Drill into the Cancellation Rate trend, ifholdedstays elevated and cancellation goes up, fraud rules are firing too aggressively.processingat 21.6%. Calculate average residence time: if processing has 612 orders and orders complete daily at ~63/day, residence time = 612/63 = 9.7 days from paid to complete. For a B2B merchant with 5-7 day fulfilment SLA this is borderline; for a DTC apparel merchant this would be a fulfilment crisis. Drill into Line Item Fulfillment for SKU-level slowdowns.completeat 66.7%,closedat 1.4%. Total “successfully concluded” orders are ~68%. Magento doesn’t auto-flip orders toclosedon partial refund, so refunded-once orders mostly stay atcomplete; only fully-refunded orders move toclosed. Don’t readclosedas the refund signal; use Refund Rate.- Cross-reference with status (the user-facing labels). This merchant has customised
processingto display as “PO Received” andcompleteto display as “Shipped & Invoiced”. If their staff says “we have 1,894 shipped orders this month”, they are readingcomplete. The card’sstateview and the staff’sstatusview agree because the merchant defines them consistently. - The 4
neworders are <5 minutes old. Normal latency between order submission and payment-state transition. Ifnewbuilds up over 30+ minutes, the payment gateway routing has stalled.
Sibling cards merchants should reference together
| Card | Why pair it with Order State Distribution |
|---|---|
| Total Orders | The denominator for percentages here. |
| Cancellation Rate | The canceled slice as a trended rate. |
| Refund Count | closed is loosely related but not identical (partial refunds stay complete). |
| Fulfillment Rate | processing to complete transition rate. |
| Line Item Fulfillment | The line-level view of processing. |
| Revenue Drop Alert | A spike in pending_payment is the gateway-callback failure signature; this card is the diagnostic view. |
| Orders Over Time | State distribution over time; useful for spotting transitions. |
shopify.financial_status | Shopify peer (Shopify uses financial_status and fulfillment_status separately, no merged state). |
bigcommerce.order_status_breakdown | BigCommerce peer with a different state machine. |
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin:Sales > Orders with the Status column displayed. The grid shows theFor a quick sanity check, group the Sales > Orders grid by Status and count rows by state-equivalent. The Admin Dashboard tile Last Orders is too short for sanity-checking distributions; ignore it for this purpose. Why our number may legitimately differ from the Admin grid:status(custom label) not thestate. To compare to this card’s state distribution, you need thestatus_state_assignmentsmapping: Stores > Configuration > Sales > Order Status > Order Status lists every status with its underlying state. A merchant with 5 custom statuses onprocessingwill see them as 5 grid filters but they all roll up to one bar in this card.
| Reason | Direction of divergence |
|---|---|
Status vs state. Admin grid shows status (custom labels, can be 1-many to state). This card uses state. A status of “Shipped” mapped to complete and a status of “Delivered” also mapped to complete aggregate together here but show as two filters in Admin. | Card aggregates higher per state |
| Time-zone. Sales > Orders grid uses Admin user’s locale; card uses UTC. Day-edge orders shift. | ±1 day |
| Multi-store scope. Both default to “All Store Views”; matched. Scope-restricted Admin users see fewer orders. | Vortex IQ ≥ scoped Admin |
Custom statuses without state mapping. If a merchant created a custom status without assigning a state (rare but possible via direct DB insert), the order has status='custom_label' but state IS NULL. Card excludes NULL states; Admin shows the row. | Card under-counts vs Admin |
payment_review race condition. The state transitions from payment_review to processing or canceled within seconds of gateway response. Snapshot timing matters. | Minor, transient |
| Sync lag. 5-15 min. | Standard |
| Card | Expected relationship | What divergence tells you |
|---|---|---|
stripe.stripe_charge_status | Stripe succeeded charges should approximately match processing + complete + closed for Stripe-paid orders | If pending_payment is high but Stripe shows successful captures, the gateway-callback to Adobe is failing. |
paypal.pp_transaction_status | PayPal Completed transactions should match captured-state Adobe orders for PayPal-paid orders | Divergence flags PayPal IPN/webhook issues. |
Known limitations / merchant FAQs
What is the difference betweenstate and status and which one is “right”?
state is the system-level lifecycle (8 fixed values, fixed by Magento core code, not configurable). status is a configurable user-facing label, mapped many-to-one onto a state. Neither is more “right”; they answer different questions. Use state for cross-merchant comparisons and system-health diagnostics; use status for operational workflows. The card uses state; your Admin shows status.
Why isn’t a fully-refunded order in closed?
Adobe Commerce flips an order to closed only when the full grand_total has been refunded. Partial refunds leave the order at its prior state (usually complete). So closed understates “refunded orders” if you have any partial refunds. Use Refund Count for refund volume.
pending_payment is 8% on my DTC store, is that bad?
For DTC, yes. Online card payments should auto-transition through pending_payment in seconds. A persistent 8% means the gateway success-callback path is broken, or you have a high mix of offline payment methods (bank transfer, cash on delivery). Check Stores > Configuration > Sales > Payment Methods for the mix and cross-check with Revenue Drop Alert.
holded orders, how do I unblock them?
Go to Sales > Orders, filter Status = On Hold, open each, click “Unhold” if the Admin user has the ACL. Many merchants leave fraud-review orders here too long; gateway authorisation expires after 7 days, after which the merchant cannot capture even if they decide it’s legitimate. Set up a daily ops review.
Why does processing keep growing without complete keeping up?
Fulfilment is the bottleneck. Calculate residence time: processing count ÷ daily complete rate = days in processing. If this exceeds your fulfilment SLA, the warehouse is behind. Drill into Line Item Fulfillment for SKU-level diagnostic.
My multi-store has different states distributed differently per store, why?
Different Store Views often have different payment methods (US store offers bank transfer, UK does not), different fraud rules, different audiences. Filter the card per Store View to compare.
Can a state regress, e.g. complete back to processing?
Generally no. Adobe Commerce has a directed state machine: new → pending_payment → processing → complete/closed. The exception is holded, an admin can hold then unhold an order. Refund creates a Credit Memo (separate document) without flipping the order back.
Why is payment_review so volatile minute-to-minute?
Because it’s a transient state. Gateway returns “review” status; Adobe writes payment_review; gateway resolves within seconds-to-minutes; Adobe transitions out. Snapshot timing matters. Use the 30-day average rather than instantaneous count.
Does my Magento Open Source store have all 8 states?
Yes. The state machine is core Magento code, included in Open Source. The B2B-specific extensions (Companies, Quotes) add B2B-flavoured statuses but the underlying state set is unchanged.
The percentages don’t add to exactly 100%, why?
Rounding. The card displays one-decimal percentages; the underlying counts are exact. If the total appears as 99.9% or 100.1%, that’s the rounding fold.