顧客話畀咗錢，訂單仍待處理：應否出貨？

先核實付款，再解除出貨暫停

顧客傳來付款截圖，客服應先接收資料並跟進，不能單憑截圖叫倉庫放貨；網店仍顯示待處理，也不代表付款已失敗。建議即時暫停出貨，由有權查閱付款紀錄的同事，按訂單編號找出對應交易。核實後還要沿用公司的庫存、送貨及風險審批要求。這個流程要回答的是「這張訂單現在可否放行」，而不是判斷顧客是否可信。

處理方法可分三路：付款結果未明，繼續等候並約定覆查；款項已核實，但網店未同步，由指定同事處理放行；找不到交易或資料不符，交主管追查。若老闆決定先送貨，應把它記作承擔未收款風險的商業決定，另記批准人及涉及貨款，不能把未確認的付款改成已付款。香港店舖常要趕速遞截單，時間緊迫可以提高處理優先次序，卻不能代替付款證據。

看付款平台的實際狀態

以下以已使用 Stripe 的網店為例，並非建議轉換付款平台。Stripe 文件指出，processing 與 succeeded 並不相同；requires_capture 尚需請款。顧客付款後可能離開頁面，因此文件建議由伺服器接收 webhook 通知。即使 PaymentIntent 保持 succeeded，之後的退款或爭議仍會反映在 Charge。其他平台須按各自的狀態定義判斷。

內部程序可要求覆核人透過公司批准的帳戶查閱交易，逐項對照訂單編號、付款參考、金額及幣別，並記下核實時間與狀態。遇到授權、部分付款或不熟悉的狀態，先維持暫停，再請付款負責人處理，不能只看畫面上的綠色圖示便判斷成功。倉庫需要的是清楚的放行指示，不必取得付款平台的登入資料。

把待核實訂單放進有人跟進的清單

起步時可用限制存取的共用清單，或現有訂單系統的個案頁面。客服與放行負責人要看得到進度，倉庫操作畫面也要顯示暫停出貨，不能只在聊天群組留一句「等一等」。以下欄位是建議的營運設計，不是付款平台的強制要求。每宗個案指定一位覆核人及後備同事，按營業時間與速遞截單安排下次覆查；交更時一併交代，避免承諾所有付款都會在同一時限內完成。

付款狀態與出貨狀態應分開記錄。款項核實後，包裹可能仍要等地址確認；主管批准先送貨，款項也可能尚未確認。兩種情況都要留下原因。清單保留查閱交易所需的參考資料即可，不要抄錄完整信用卡資料。結案前要確認倉庫收到的指示、客服給顧客的說明，以及個案結果三者一致。

用兩個情境演練放行決定

假設顧客選擇門市自取，付款後關閉瀏覽器，到店時後台仍顯示待處理。店員先建立個案，不要立即要求再付一次。覆核同事找到相符的交易，確認付款成功後，記錄證據並核對貨品尚未交收，再按內部權限解除暫停。關閉頁面只是這個示例的背景，真正支持交貨決定的是核實過的付款紀錄。

另一個示例是速遞快將截單，網店仍未收到更新，而覆核人查到付款平台亦未確認成功。這時包裹應留在待處理區，設定覆查時間，並向顧客交代原定寄出安排可能受影響。若平台暫時無法查閱，個案同樣未能定案。其後核實成功，就按放行程序處理；若確認失敗，再說明可用的付款方式，不能為了清空清單便叫顧客重付。

先用現有流程試行

下次營運會議可先指定放行負責人，再由客服與倉庫一起演練上述情境。要求接手同事不用找原經辦人，也能查到暫停原因、核實證據及下一步。另加一個付款後退款或爭議的情境，確認它會交給相應負責人跟進，而不會因為曾經付款成功便被忽略。若問題只是紀錄歸屬不清或進度看不到，先列出這項改動的驗收要求，再決定是否需要更大的系統工程。