顧客下了單，後台訂單卻卡在「保留中」動不了；明明對方說已經轉帳了，狀態還是顯示「待付款」；或是想加一個「已出貨」「製作中」的階段，卻發現下拉選單裡根本沒有這個選項。這些都是 WooCommerce 訂單狀態沒搞懂時最常踩的坑。

WooCommerce 訂單狀態是整個出貨與對帳流程的骨幹，它同時牽動三件事：庫存要不要扣、要不要寄通知信給顧客、以及後台能不能編輯這張訂單。狀態判讀錯了，輕則漏發通知信，重則超賣或重複出貨。

這篇會先把預設的每一個狀態講清楚，包括它代表什麼、庫存怎麼動、由誰觸發；接著畫出一張完整的狀態流轉圖，對應台灣常見的 ATM 轉帳、超商取貨付款、貨到付款情境；最後示範怎麼用外掛或程式碼新增自訂狀態，並把流程自動化，讓訂單少卡關、客服少接電話。

WooCommerce 預設訂單狀態有哪些，各代表什麼

WooCommerce 內建八個訂單狀態，每一個都對應訂單生命週期裡的一個階段。訂單從「待付款」開始，正常情況下以「已完成」結束，中間會依付款方式與商品類型走不同的路徑。

先把每個狀態的定義、庫存行為與後台是否可編輯整理成一張對照表，這是判讀訂單最快的依據。

待付款與失敗的訂單為什麼不扣庫存

待付款代表訂單剛建立、系統還沒拿到任何付款資訊，這時庫存不會扣減，避免一張還沒成立的訂單去佔用其他顧客買得到的數量。失敗則是付款明確被拒或金流連線出錯，同樣不扣庫存，並且會把先前可能保留的數量釋放回去。

要特別注意一個判讀陷阱：失敗的訂單有時不會立刻顯示為「失敗」，而是先停在「待付款」，要等金流商（例如綠界、藍新、PayPal）回傳驗證結果後才更新。看到一張遲遲未動的待付款訂單，先別急著當成顧客還沒付，有可能是金流端的驗證還沒回來。

保留中與處理中的差別在庫存與收款確認

保留中與待付款最關鍵的差異，就在於庫存有沒有被扣。保留中代表顧客已經選定離線付款方式（最典型的是 ATM 或銀行轉帳），系統會先把庫存鎖起來、防止其他人買走，但款項要由商家自行確認入帳後，才能手動把狀態往下推。

處理中則表示收款這件事已經確定。信用卡刷卡成功會直接進入處理中；如果顧客選的是貨到付款或超商取貨付款，下單後也會直接顯示處理中，因為只要把貨寄出去就收得到錢。對顧客來說，看到「處理中」就等於知道商家已經在備貨了。

一個常被忽略的點：虛擬且可下載的商品（例如電子書、線上課程），付款完成後會自動跳到「已完成」，中間不會出現「處理中」，因為沒有實體出貨這個動作。

已完成、已取消與已退費分別在什麼時候用

已完成代表整張訂單履行結束、商品已交付，後續不需要再操作。實體商品通常由商家在出貨後手動標記；虛擬商品則會自動進入此狀態。

已取消用在訂單還沒完成前喊停，可能是顧客反悔，也可能是超過付款期限。取消後，先前在「保留中」扣掉的庫存會自動加回來。已退費則是已經實際退款給顧客後才標記的狀態，庫存不會自動回補，需不需要把商品重新上架由商家在退費介面自行勾選。

這裡有個容易卡住的機制：已經標記為「已付款」的訂單，系統通常不允許直接改成「已取消」，只能走「退費」。如果真的要改成取消，得先把付款狀態清掉（例如手動標記為未付款），系統才會放行。簡單記：未付款的訂單可以直接取消，已付款的訂單只能用退費結案。

WooCommerce 訂單狀態的完整流轉路徑長怎樣

訂單狀態不是隨意切換的，它有一條主幹路徑，再依付款方式分出幾條支線。先看主幹：顧客按下結帳，訂單以「待付款」誕生，付款確認後進「處理中」，出貨後到「已完成」。

下面把這條主流程，以及離線付款會多繞的「保留中」分支畫出來。

其中第二格「保留中」只有離線付款才會經過；信用卡或貨到付款會直接從待付款跳到處理中。理解這條路徑，後台看到任何一張訂單卡在某一格，就能反推它正在等什麼。

ATM 轉帳的訂單會走哪些狀態

ATM 或銀行轉帳是台灣電商最常見、也最容易卡關的情境。顧客結帳選擇 ATM 轉帳後，畫面跳到金流頁面取得轉帳資訊，後台訂單會先變成「保留中」，庫存同步鎖定。

等顧客實際完成轉帳、金流商（綠界、藍新）回傳繳費成功通知，狀態才會自動變為「處理中」。商家出貨後再手動標記為「已完成」。要留意的是，WooCommerce 本身不會主動檢查 ATM 繳費是否過期，若顧客最後沒付，金流商通常也不會回傳「取消」通知，這張訂單就會一直停在保留中，需要靠後面會講的自動取消機制來清理。

貨到付款與超商取貨付款為什麼直接變處理中

貨到付款與超商取貨付款下單後，後台訂單會直接顯示「處理中」，跳過保留中這一格。原因是這兩種付款方式的收款發生在出貨之後，系統認定只要把貨送出去就收得到錢，所以一成立就視為可以履行的訂單。

這也代表這類訂單的庫存在成立當下就會扣減。商家收到款項、完成交付後，同樣由人工標記為「已完成」收尾。

信用卡與第三方金流如何自動推進狀態

信用卡與線上第三方金流的最大好處，是狀態能自動往前推、不太需要人工介入。當金流閘道確認刷卡成功，WooCommerce 會觸發一個名為 woocommerce_payment_complete 的事件，預設就把訂單從待付款推進到「處理中」（虛擬商品則直接到已完成）。

如果刷卡需要 3D 驗證或符合 SCA 規範，訂單會先進入「需要驗證」，等顧客完成驗證後才繼續。這條路徑要順暢的前提，是金流外掛的回報網址（callback）設定正確；回報沒接好，最常見的症狀就是錢已經扣了、訂單卻還停在待付款或保留中。

保留中與失敗的訂單卡住了該怎麼處理

訂單長期卡在「保留中」或「失敗」，是 WooCommerce 後台累積待辦的兩大主因。先給結論：保留中多半是離線付款沒入帳或沒人工確認，失敗則是金流端拒絕了交易，兩者的處理方向不同。

卡在保留中的訂單多半是離線付款沒對帳

保留中的訂單通常出現在 ATM 轉帳、後台手動建立訂單、信用卡需人工審核、或電子錢包需額外處理這幾種情況。處理方式分主動與被動兩面。

被動面是設定自動取消：到 WooCommerce → 設定 → 商品 → 庫存，把「保留庫存（分鐘）」填入一個時間（例如 1440 分鐘等於 24 小時），超過時限仍未付款的訂單就會自動取消、釋放庫存。這是清理殭屍訂單最省力的做法。主動面則是付款提醒：在訂單建立後 12 至 24 小時，透過自動化通知寄出付款提醒與付款連結，把還在猶豫的顧客拉回來完成轉帳。

失敗的訂單要先分清楚是金流問題還是技術問題

失敗代表付款明確沒成功，常見原因有三類：信用卡端被拒（3D 驗證未過、額度不足、卡片過期）、金流商風控攔截（多次錯誤輸入、可疑交易），以及伺服器或 API 錯誤（金鑰設定錯、連線逾時）。

處理上先判斷屬於哪一類。若是顧客端的付款問題，可在訂單頁面用「將訂單明細寄送給客戶」功能自動附上付款連結，請對方換張卡或換付款方式重試。若懷疑是技術面，到 WooCommerce → 設定 → 付款 檢查金流外掛是否正常，再到 WooCommerce → 狀態 → 記錄 查看錯誤日誌，必要時聯繫金流服務商。分清楚是金流還是技術問題，才不會把顧客端的小狀況當成系統故障亂查。

怎麼新增 WooCommerce 自訂訂單狀態

當預設的八個狀態描述不了實際營運流程時，就該新增自訂狀態。例如想多一個「製作中」「包裝中」「已出貨」「待取貨」的階段，讓後台和顧客都能更精準地知道訂單走到哪。新增方式分兩條路：裝外掛，或寫程式碼。

用外掛新增自訂狀態適合不想碰程式碼的店家

外掛是最快、零程式碼的做法。市面上像 Custom Order Status、Order Status Manager、Flexi Custom Order Status 這類外掛，都能在 WordPress 後台直接建立新狀態，設定它的別名（slug）、顯示名稱（label）、圖示與顏色，建立後就會出現在訂單編輯頁的下拉選單裡。

外掛的優勢不只是建立狀態本身，多數還會一併處理好周邊細節：把新狀態加進批次操作、報表、以及對應的通知信設定。這些手刻程式碼時很容易漏掉的環節，外掛幫你補齊了，對不熟開發的店家來說省下大量除錯時間。

用程式碼新增自訂狀態要分兩步才會生效

如果想完全自己掌控、不增加外掛負擔，可以用程式碼新增。這裡有一個非常容易卡關的陷阱：很多人只做了第一步，結果在訂單編輯頁怎麼找都找不到新狀態。

WooCommerce 的訂單狀態底層是用 WordPress 的 Post Status 實作的，因為訂單本身就是一種 Post Type。第一步是在 init 勾點用 register_post_status() 註冊狀態：

add_action( 'init', function() {
    register_post_status( 'wc-deliver', array(
        'label' => '配送中',
    ) );
} );

但光做這步，WordPress 並不知道這個狀態是要用在「訂單」上，所以下拉選單不會出現它。關鍵的第二步，是透過 wc_order_statuses 這個 filter，把狀態掛到訂單的狀態清單裡：

add_filter( 'wc_order_statuses', function( $order_statuses ) {
    $order_statuses['wc-deliver'] = '配送中';
    return $order_statuses;
} );

兩步都做完，新狀態才會真正出現在訂單編輯頁。要提醒的是，自訂狀態的 slug 慣例以 wc- 開頭，且這套寫法只負責「讓狀態能選」；如果還想要這個狀態觸發通知信、出現在報表或批次操作裡，得另外掛對應的勾點處理，這也是外掛幫你省掉的部分。

自訂狀態不是開越多越好

自訂狀態很好用，但開太多反而會讓後台和員工混亂。一個務實的原則是先從 2 至 4 個自訂狀態起步，而且每一個都要對應一個真實存在的營運動作。

判斷要不要新增的標準很簡單：這個狀態會不會改變某人接下來的行動？「待出貨」「已出貨」會（倉庫要動、顧客要等），那就值得開；如果只是讓後台多一個看起來分得很細、卻沒人會據以行動的標籤，那就是徒增複雜度。狀態的價值在於驅動行動，不在於分類得多漂亮。

訂單狀態流程自動化能省下哪些人工

自動化的核心，是讓狀態在符合條件時自己往前走，把人工從「逐張改狀態」中解放出來。WooCommerce 本身提供了狀態轉換的事件機制，搭配自動化外掛還能依更多條件觸發。

哪些狀態轉換可以交給系統自動完成

最基礎的自動化其實內建就有。金流確認收款時觸發的 woocommerce_payment_complete，會自動把訂單推進到處理中；前面提到的「保留庫存（分鐘）」會自動取消逾時未付款的訂單；訂單狀態變動時（例如從處理中變已完成），系統也會依設定自動寄出對應的通知信。把這幾項設好，日常已經能少做不少手動操作。

WooCommerce 在每次狀態切換時都會觸發狀態轉換事件，開發上可以掛在這些事件上做延伸動作，例如狀態變「已完成」時自動同步出貨資訊到外部系統。這是進階自動化的基礎。

進階自動化可以依付款方式與條件觸發

要做到更細的條件式自動化，通常會借助 AutomateWoo、Flexi Custom Order Status 這類自動化外掛。它們能依付款方式、商品或分類、購物車金額、數量、顧客角色、地區，甚至日期時間來設定規則，自動切換狀態或執行動作。

舉幾個實務情境：對「保留中」逾期的訂單，自動分批寄出 12、24、48 小時的付款提醒；對特定商品分類的訂單，下單後自動切到自訂的「製作中」狀態通知工廠備料；對失敗訂單自動附上重新付款連結並記錄到 CRM 後續追蹤。規則設定好後，這些原本要客服一張張盯的流程就能交給系統跑。

自動化要配合通知信才完整

狀態自動化若沒接上通知，顧客還是會一頭霧水。WooCommerce 預設就把多個狀態綁了通知信：訂單進「處理中」會寄處理中通知、進「已完成」會寄完成通知、失敗與退費也各有對應信件。

新增自訂狀態時，記得評估它需不需要對應的通知信。例如自訂「已出貨」狀態，最好搭配一封附上物流單號的通知信，顧客才知道貨在路上。除了系統信，訂單備註也是溝通工具：在訂單裡新增「給客戶的備註」，顧客會收到郵件並能在會員中心查看，適合用來補充出貨延遲、補件提醒這類臨時訊息。讓狀態變動與通知連動，才是自動化真正減少客服詢問的關鍵。

把訂單狀態管理變成穩定運轉的流程

讀懂 WooCommerce 訂單狀態，本質上是讀懂三件事的連動：狀態決定庫存扣不扣、決定寄不寄通知、也決定後台能不能編輯。把預設八個狀態的庫存行為與觸發時機記熟，後台任何一張卡住的訂單，你都能反推它在等什麼，而不是盲目地切來切去。

接下來可以分三步把流程穩定下來。先到庫存設定填好「保留庫存（分鐘）」，讓逾時未付款的訂單自動清理，後台就不會堆滿殭屍訂單。再依實際營運流程，用外掛或程式碼補上 2 至 4 個真正會驅動行動的自訂狀態，並為每個需要的狀態配好通知信。最後把能交給系統的轉換交出去，讓金流回報、逾時取消、狀態通知都自動跑，人工只處理真正需要判斷的例外。狀態管理順了，出貨、對帳、客服自然跟著順。