購物網站架設的展示通常停在「商品加入購物車、付款成功、看到訂單編號」，但真正容易出錯的是成交之後。顧客取消未出貨商品、客服退回部分款項、倉庫已經撿貨、物流已取件，這些事情可能發生在同一張訂單，卻不能用一個「已取消」欄位全部帶過。
規格若把取消、退款、退貨、庫存回補與通知視為同一個按鈕，後台很容易出現款項已退但貨還在路上、訂單停止處理但退款尚未完成，或商品尚未入庫卻提前恢復可售等矛盾。選擇開店平台、混合串接或客製電商之前，應先把這些狀態與責任寫成可驗收流程。
一張訂單至少有五條狀態線
訂單狀態回答「這筆交易是否仍要處理」；付款狀態回答「款項是否授權、請款、部分退款或全額退款」；出貨狀態回答「商品是否撿貨、交運或送達」；退貨狀態記錄申請、核准、收件與檢查；庫存狀態則決定商品何時能再次販售。五者彼此相關，但不是同一件事。
Shopify 的 Canceling orders 文件明確區分取消訂單與後續退款：已付款但未出貨的訂單可在取消時退款，也可選擇稍後退款；若訂單已部分出貨，處理方式又不同。文件也提醒，第三方履約中的訂單可能必須先到履約服務取消。這些限制不必照搬成每個專案的介面，卻證明「取消」不能被規格成沒有前置條件的單一步驟。
需求書可以先畫狀態表：每個動作允許從哪些狀態開始、成功後改動哪幾條狀態線、失敗時保留什麼、誰可以重試，以及顧客會收到哪一種通知。這張表比列出「訂單管理、退款管理」兩個功能名稱更能讓不同提案被公平比較。
退款不是刪除訂單，也不等於收到退貨
Refunding orders 說明，退款可以是全額或部分，也可能不先建立退貨；但款項一旦從後台發起退款，不能直接取消或反轉。文件另指出，若商品會寄回，先建立退貨並記錄原因，才能保留後續按退貨原因分析的資料。這給規格一個重要原則：不可逆的款項動作應有確認、權限與紀錄，而退貨原因不能只藏在客服備註。
後台至少要分開保存退款金額、退款方式、外部交易識別、操作人、操作時間與結果；退貨則保存品項、數量、原因、收件與檢查結果。若金流端仍在處理，畫面應顯示「退款處理中」或明確錯誤，而不是先標成已完成。重新送出前也要能辨認同一筆退款請求，避免人員因畫面逾時重按而造成重複操作。
庫存回補也要獨立決策。未出貨取消可能可以直接釋放保留量；已寄出的商品則通常要等實際收回並檢查，才能判定可售、瑕疵或報廢。系統不該因為退款完成，就自動假設每一件商品都已回到可售庫存。
權限要按風險拆，不是有後台就全部能做
客服可以受理取消，不代表可以直接發出任何金額的退款；倉庫可以確認收貨，也不應能改寫付款結果。規格可分成申請、核准與執行三個角色，並針對部分退款、運費退款、已出貨取消及人工庫存調整設定不同權限。
每次狀態變更要留下原值、新值、原因、操作者與外部回應。若客服先建立申請、財務隔日核准，系統仍要讓兩人看到同一份品項與金額快照，不能因商品價格或訂單內容後來改變而失去核對依據。通知也應記錄是否送出，而不只是按下寄信按鈕。
用展示案例跑完整售後情境
MORIÉ 森澄研保養品電商展示案例包含商品分類、商品頁、收藏、購物車與模擬結帳。這是展示作品，不代表真實商店的營運成果；它適合拿來補做售後驗收：同一張訂單買了不同品項，其中一項在出貨前取消、另一項出貨後申請退貨，最後只有通過檢查的商品回補庫存。
驗收時可由客服建立取消申請，確認未取消品項仍可出貨；再由具權限者執行部分退款，檢查金額、付款狀態與通知。對已出貨品項建立退貨，模擬收到商品後分別標記可售與不可售，確認庫存結果不同。最後查看訂單時間軸，應能重建每一步，而不是只剩最終狀態。
也要測試失敗路徑：金流逾時、物流取消失敗、通知寄送失敗、兩位人員同時處理，以及重複按下退款。各項失敗應顯示待處理工作，不得用成功訊息掩蓋外部服務尚未完成的事實。
把售後驗收寫進購物網站報價
報價可將狀態設計、金流串接、物流串接、客服介面、權限、通知與操作紀錄分項，並列出使用平台現成功能與需要客製的邊界。上線前以未付款、已付款未出貨、部分出貨、已退款與退貨中的訂單逐一測試，保存畫面、交易識別與庫存前後差異。
購物網站的完成定義不該是「可以收錢」，而是訂單改變後仍能說清楚貨在哪裡、錢到哪裡、庫存是否可售，以及下一步由誰處理。先拆開取消、退款與退貨，才能在不猜測平台行為的情況下，得到可操作、可追蹤也可交接的售後流程。
