超商取貨付款的資訊流設計：金流與物流交錯時，訂單狀態該怎麼管理

超商取貨付款是台灣電商獨有的購物體驗——消費者下單後，商品寄到指定超商門市，消費者到店取貨時才付款。聽起來很簡單，但從系統架構的角度來看，它是金流串接中最複雜的場景之一，因為它把兩條原本獨立的資訊流（金流和物流）交織在一起。

在純線上付款的場景中，訂單的生命週期是線性的：下單 → 付款 → 出貨 → 完成。但在超商取貨付款的場景中，付款和取貨是同一個動作，而物流狀態會在付款之前就開始變化。整個流程大致如下：消費者選擇超商門市下單 → 你呼叫綠界物流 API 建立物流訂單 → 你將商品寄送到物流中心 → 物流中心配送到指定門市 → 消費者到店取貨並付款 → 綠界通知你物流狀態更新（已取貨）→ 綠界通知你金流狀態更新（已付款）。

這裡的關鍵問題是：物流狀態通知和金流狀態通知是兩個獨立的 Webhook，由不同的系統發送，到達的順序不一定。物流狀態通知會打到你在建立物流訂單時設定的 ServerReplyURL，而金流狀態通知則打到 ReturnURL。你的系統必須能夠正確處理這兩條通知，無論它們以什麼順序到達。

建議的訂單狀態設計如下。在消費者下單後，訂單進入「待寄出」狀態。商品交給物流後，進入「運送中」。物流通知到達門市後，進入「待取貨」。消費者取貨付款後，你會先後收到兩個通知：物流狀態變為「已取貨」，金流狀態變為「已付款」。建議在資料庫中為同一筆訂單分別維護 logistics_status 和 payment_status 兩個欄位，而非用單一的 order_status 來代表所有狀態。只有當 logistics_status 為「已取貨」且 payment_status 為「已付款」時，才將 order_status 更新為「已完成」。

另一個需要注意的情境是「消費者未取貨」。如果消費者在期限內沒有到店取貨，商品會被退回。這時你會收到物流狀態為「退貨」的通知，但金流端不會有任何通知（因為消費者根本沒有付款）。你的系統需要在收到退貨通知時自動將訂單標記為「已取消」或「退貨處理中」，並釋放被保留的庫存。

關於 ServerReplyURL 的處理邏輯，與 ReturnURL 類似，你需要在收到通知後回應正確的格式。物流狀態通知需要回應 RtnCode=1 和 RtnMsg=OK（注意這與金流的 1|OK 格式不同）。如果你沒有正確回應，綠界會重複發送通知，7-ELEVEN 超商的物流在遇到消費者第二次進店（例如取件失敗後再次取件）時還會再次觸發通知。

最後，超商取貨付款在測試環境中有一個重要限制：測試環境沒有提供模擬物流狀態通知的功能。你只能在正式環境中建立真實的物流訂單並完成出貨，才能收到完整的物流狀態通知。這代表你在開發階段需要額外設計 Mock 資料或 Stub 服務來模擬物流通知的行為，否則無法在上線前完整測試整個超商取貨付款的流程。