EC 関連リソースの選び方
EC の API は、自社で店舗を運営するのか、既存プラットフォームと連携するのかで見るべきものが変わる。前者なら決済・在庫・配送を個別に組み合わせることになり、後者ならそのプラットフォームの API 仕様に沿うことになる。
連携先プラットフォームの制約を先に見る
既存の EC プラットフォームと連携する場合、できることはそのプラットフォームが公開している範囲に限られる。注文の取得はできても在庫の一括更新はできない、といった制約が設計を規定する。やりたいことが API で実現できるかを、実装の前に仕様書で確認しておく必要がある。
注文イベントは複数回発生します
ひとつの注文に対して、作成・支払い・出荷・更新と複数の通知が届くのが一般的です。どのイベントを処理の起点にするかを決めないと、同じ注文を重複して処理してしまいます。「支払い完了をもって処理する」のように起点を一つに定め、他は状態更新に留める設計にしてください。
在庫の整合性
複数の販売チャネルを持つと、在庫の同期が最大の課題になる。API 経由の更新には遅延があり、その間に別チャネルで売れると在庫がずれる。完全な整合を取るのは難しいため、実務では安全在庫を設けて超過販売を防ぐ運用と組み合わせるのが現実的だ。
個人情報の取り扱い
注文データには氏名・住所・連絡先が含まれる。自社システムに取り込む場合、保管範囲・アクセス権限・保持期間を定めたうえで扱う必要がある。連携が便利だからといって、必要のない項目まで取り込まない判断も重要になる。