商城與 POS 對接怎麼做？商品、訂單、庫存的準備清單
梳理平臺授權、SKU、訂單、庫存與支付規則，準備一份門店和網店都能使用的接入清單。
先看結論
商城與 POS 對接，先確認平臺版本和授權，再梳理 SKU、價格、訂單來源、倉庫和庫存更新方向。支付方式、退款與異常處理也應寫進服務方案。AllinWebPOS 可圍繞 OpenCart 對接方案、Shopify 定製接入和門店設備需求安排評估，確定適合業務的實施範圍。
把流程放到門店現場
先約定商品標識與庫存歸屬，再銜接訂單、備貨與發貨，讓線上需求進入清楚的履約流程。
- 運營
確認訂單範圍
明確接入渠道、商品標識與訂單需要傳遞的信息。
- 店員與倉庫
覈對可售數量
按約定的庫存來源，覈對訂單商品與備貨數量。
- 履約人員
揀貨打包
覈對規格、數量和包裝要求，準備交付商品。
- 運營
交接發貨記錄
依渠道方案覈對交付與發貨信息，跟進異常訂單。
先確認版本、權限和商戶條件
記錄商城版本、插件、API 權限、商戶地區和幣種。外部平臺權限可能按賬號、應用和接口分別限制。測試環境和正式環境的授權也可能不同，應明確測試在哪個環境執行，哪些數據允許寫入。
Shopify 的 API 訪問範圍決定應用可讀取或修改哪些店鋪數據；OpenCart 則通過 API 用戶、權限與允許訪問的 IP 管理調用。兩者的準備方式不同，應參照對應平臺的官方文檔，按業務需要安排授權。
按商品、訂單與庫存拆分驗收
商品導入要檢查規格與編碼，訂單導入要檢查優惠、稅費和來源標識，庫存回寫要檢查數量和倉庫。每項驗收都應在外部平臺覈對結果。一個接口返回成功不能代表三條業務鏈路同時完成。
支付從發起一直覈對到賬
檢查發起支付、取消、超時、回調簽名、重複回調、退款和交易覈對。系統內顯示支付成功，必須與服務商交易狀態一致。商家還應明確支付服務商、商戶賬號、支持幣種和退款規則，確保選用的收款方案適合經營地區。
把重試和異常納入驗收
重複訂單、接口限流、授權失效和庫存衝突都應有處理規則。明確哪些異常自動重試，哪些需要人工確認，並給人工覈對提供來源訂單號和處理記錄。完成正常訂單只是驗收的第一部分。
怎樣安排點單、商城與支付方案？
H5 點單、獨立網店和第三方支付解決的是不同業務任務。H5 關注顧客選購與門店服務，商城接入關注商品與訂單之間的連接，支付方案關注收款與退款。將這些需求分別列清楚，更容易安排適合門店的實施計劃。
一條驗收用例應包含什麼？
把檢查項目寫成可執行的業務任務。例如，在商城創建包含兩個 SKU 和優惠的測試訂單，覈對 POS 中的來源編號、商品規格、金額和所屬門店；再處理一次取消或部分退款，確認相關訂單記錄和庫存變化符合門店規則。重複處理同一筆來源訂單時，也要覈對是否出現重複記錄。
將操作步驟、預期結果和核對記錄放在一起，門店與服務團隊就能沿用同一份清單。訂單、庫存、退款和會員分別檢查，再明確後續異常由誰處理。
收款與退款，怎樣覈對記錄？
保存商戶環境、系統訂單號、支付嘗試號、外部交易號和回調處理結果。正常付款之外，還應驗證取消、超時、重複回調和退款。系統內金額與服務商交易金額必須能解釋；收款記錄、商戶結算與餘額變化不能混成同一個狀態。
測試階段可以先覈對系統流程，再使用指定商戶環境檢查交易與退款。正式營業前，將訂單記錄、服務商交易與門店日結放在一起覈對，確保每筆收款都有清楚的對應關係。
接入後，日常經營怎樣維護？
把日常維護安排給明確的負責人：誰處理店鋪授權到期，誰覈對未同步訂單，誰跟進打印異常，誰聯繫支付服務商。平臺升級、商品規格調整或新增門店時，也要檢查原有商品映射和倉庫規則是否仍然適用。
在規劃階段說明這些經營需求，可以讓服務範圍、實施步驟和後續支持更清楚。將你使用的商城、支付方式與設備型號帶給 AllinWebPOS 團隊，我們會與你梳理適合門店的接入方案。
商城與 POS 接入覈對表
| 鏈路 | 應觀察的結果 | 建議覈對的資料 |
|---|---|---|
| 商品映射 | SKU 與規格匹配 | 映射表和雙方商品編號 |
| 訂單導入 | 金額準確且避免重複 | 來源訂單與內部訂單記錄 |
| 庫存更新 | 目標平臺數量符合約定 | 更新前後數量與任務記錄 |
| 支付退款 | 交易和退款狀態相符 | 商戶交易、回調及覈對記錄 |
落地檢查清單
- 記錄平臺版本和實際權限
- 商品、訂單、庫存分別取證
- 支付與外部交易狀態一致
- 重複事件和失敗重試可復現
參考資料
- Shopify 開發文檔：API 訪問權限
瞭解商品、訂單與庫存訪問所需的授權範圍。
- OpenCart 文檔：API 用戶與權限
瞭解 API 賬號、權限和允許訪問的 IP 配置。
