電商訂單顯示成立，不代表庫存、會計、物流與客戶系統都已收到正確資料。本文帶企業主用交易編號、狀態定義、重試防重、異常告警與每日對帳五項證據驗收串接，避免超賣、漏出貨、重複開票與責任不清。
客人在網站完成付款，後台也出現訂單，倉庫卻沒有扣到庫存；客服在客戶管理系統找不到這位買家；月底會計才發現退款沒有同步。每一套系統單獨看都能運作，資料交接處卻可能失敗。這類問題平時只像幾筆人工補登，訂單一多，就會變成超賣、漏出貨、重複開票、退款延遲與客訴。
系統串接很像接力賽。第一位選手把接力棒伸出去，不代表下一位已接穩，更不代表全隊抵達終點。網站顯示「訂單成立」，往往只證明其中一站完成。企業真正需要驗收的是，每一棒由誰交、誰接、用什麼編號核對，以及掉棒後如何補回。
一筆訂單，其實跨過多個完成狀態
電商、金流、庫存、物流、發票與客戶管理系統通常各自保存狀態。它們可能透過 API（應用程式介面，讓兩套系統按約定格式交換資料的入口）即時查詢，也可能用 Webhook（事件通知，在付款或退款發生時主動告知另一套系統）傳遞變更。
因此，收到請求、接受處理、實際寫入與完成商業動作是不同階段。金流回覆付款成功，不一定代表庫存已扣除；物流取得資料，也不代表已產生可出貨單。若合約只寫「完成串接」，沒有列出每個階段的成功條件，出現落差時就很難判斷問題在哪一端，也無法知道哪些訂單需要人工處理。
用五項證據判斷串接是否真的可靠
- 同一筆交易能不能一路追查？ 網站訂單編號、付款編號、發票與物流單號是否能互相對照，客服能否從任一編號找到完整路徑，而不是請三家廠商各查一次。
- 每一站的成功定義是否清楚？ 畫面上的成功，是已收到資料、排入處理，還是下游確實完成。異常、取消、退款與部分出貨也要有明確狀態，不只測最順利的訂單。
- 失敗後會不會安全重試？ 網路短暫中斷可以重送，但同一筆付款或扣庫存不能因此執行兩次。冪等性（idempotency，重複處理同一請求仍只產生一次商業效果）就是用來控制這個風險。
- 誰會知道資料卡住？ 是否有失敗紀錄、告警門檻、負責窗口與可重送方式。只把錯誤留在工程紀錄裡，業務與客服看不到，等於沒有營運告警。
- 不同系統是否定期對帳？ 每日或每個營業週期能否列出缺單、金額不符、重複資料與狀態不一致，並留下誰修正、何時完成的紀錄。
Stripe 的官方 Webhook 文件提醒，事件可能重複送達，也不保證依產生順序抵達。這不代表所有平台行為都相同，而是說明串接不能把「只收到一次、順序永遠正確」當成未驗證的前提。Microsoft 的可靠性指引也指出，重試前要判斷操作能否安全重複，否則可能產生重複扣款等副作用。
便宜方案可能省下的是監測與修復能力
最簡單的直接串接成本較低，適合交易量小、流程單純且可接受人工補登的情境；但下游暫時無法回應時，網站可能等待過久或直接失敗。改用非同步處理，先保存訂單再由背景傳送，可以減少客人卡在結帳畫面，卻需要額外處理排隊、重試、重複事件、告警與人工重送。
批次匯入也不是一定比較差。若會計系統只需要每日入帳，固定批次加上對帳報表可能比昂貴的即時串接更合適。真正的取捨是企業能容忍多久不同步、人工修正多少筆、哪一種錯誤不能發生，以及出錯後多久必須被發現。報價應把這些服務水準與不包含項目寫清楚，不能只比較「即時」或「自動」兩個名稱。
今天先做一張跨系統交易對照表
先選近期包含一般付款、折扣、取消、退款與失敗重試的代表性訂單，建立「網站訂單編號、付款狀態、庫存結果、發票狀態、物流狀態、客戶紀錄、最後核對時間、異常負責人」對照表。逐筆從畫面與可匯出的紀錄核對，不要只請廠商截一張成功畫面。
接著要求測試案例至少涵蓋正常完成、下游暫停、回應逾時、同一事件重送、順序不同與人工補送。每個案例要寫預期結果、可見證據、停止條件與復原方式。企業不必自己讀程式碼，但應能看懂哪一筆卡在哪裡、是否會自動恢復，以及誰會收到通知。
自行處理的邊界與專業協助時機
企業主可以自行整理系統清單、帳號窗口、訂單狀態、可接受的同步時間、最不能出錯的流程，以及現有對帳方式。若目前交易量不大，也可先用每日匯出與人工核對建立基準，再決定自動化投資，不必一開始就導入複雜架構。
若串接涉及付款、退款、庫存承諾、電子發票、會員個資，或錯誤會跨越多家供應商，就值得由專業團隊盤點資料欄位、狀態轉換、識別編號、重試防重、告警、權限與修復流程。接洽前可準備各系統窗口、代表性訂單、錯誤時間、畫面與匯出紀錄、既有規格及合約範圍。邊境部署可以協助把這些資料整理成可驗收的串接流程與對帳清單，先找出最容易掉棒的一段，再決定修補或重新設計的範圍。