ECの注文を出荷管理や販売管理のシステムへ渡すとき、同じ注文が二件として登録されると、出荷や売上の確認に影響します。最初に決めたいのは、どの値を「同じ注文」とみなす識別子にするかです。購入者に見える注文番号と、EC側が内部で持つ注文ID、通知一通ごとのIDは役割が違います。
ECの注文IDと、外部側の登録番号を対応付ける
外部システムへ渡す項目を一覧にし、EC側で注文そのものを識別する値、購入者へ示す注文番号、外部側で採番される番号を分けます。同じECを複数店舗で使うなら、店舗の識別も合わせて考えます。受注、決済、出荷がそれぞれ番号を持つ場合、別の番号を「新しい注文」の根拠にしないよう対応関係を記録します。
Shopifyの外部注文管理システム連携資料は、内部の注文ID、管理画面に表示する注文名、番号などを区別し、外部システムの文字数や形式の制約も早期に確かめるよう示しています。これはShopifyの仕様例です。利用するECと連携先で、どの識別子が安定して使えるかを確認します。
再送された通知で新しい注文を作らない
通信が途切れたり処理が遅れたりすると、同じ内容の通知が再送されることがあります。ShopifyのWebhook検証資料も、同じ通知を複数回受け取る場合を想定し、重複を避ける処理を案内しています。連携では、通知を受け取った回数だけ注文を追加するのではなく、注文の識別子で既存の登録を探し、あれば更新・照合に回す方法を決めます。通知そのものの重複を記録する値も、注文IDとは別に扱います。
「送信側では成功したが、応答だけ届かなかった」場合も考えます。外部側に登録済みかを確かめず再送すると二重登録になり得ます。連携先が重複防止用のキーや更新APIを備えるか、登録結果を読み返せるか、失敗時に誰が保留を解消するかを設計段階で確認します。
取消し・返金・出荷変更を同じ注文の履歴として扱う
注文後の決済確定、キャンセル、返金、出荷変更が別の通知で届いても、必ずしも新規受注ではありません。元の注文との対応を保ち、外部側のどの状態を変えるかを決めます。部分出荷や複数の返金があるなら、注文一件と明細・処理の単位も分けて確かめます。実際の取消しや出荷指示へ反映する範囲は、業務担当と連携先の仕様で判断します。
本番接続前には、通常の一件、同じ通知の再送、応答だけ失敗した再送、取消し・変更を、個人情報を伏せたテスト注文で確かめます。EC側と外部側の番号、登録結果、修正履歴を突き合わせられる記録が必要です。Bämの通販・ECサイト制作案内へ相談する際は、利用するEC、外部システムの項目仕様、注文から出荷までの状態、匿名化した処理例を揃えると、二重登録を避ける確認範囲を明確にできます。
参考資料
資料確認日：2026年9月27日。Shopifyの資料はプラットフォーム固有の例です。対象ECと外部システムの連携仕様、識別子、テストデータは未提示です。
