先に結論通知IDと対象IDを分け、署名を確認し、処理済み・保留・失敗を追跡します。
同じ通知が複数回来る前提にする
送信側は応答が確認できないと再送する場合があります。通知IDやイベントIDを保存し、同じIDを再度受けても二重登録・二重請求しないようにします。
対象IDだけでは、同じ注文の別イベントを誤って捨てることがあります。通知の種類、版、発生時刻も含めて識別します。
署名と送信元を検証する
受信本文を処理する前に署名、時刻、有効期限を確認し、秘密情報は安全な保管先から読みます。ログへ署名キーや個人情報をそのまま残しません。
IP制限だけへ依存せず、相手の公式仕様に従います。検証失敗を成功応答で隠さず、攻撃と設定ミスを調査できる件数を残します。
順序逆転と遅延を扱う
作成より更新通知が先に届く、取消後に古い更新が届く場合を試します。発生時刻や版を確認し、古い状態で上書きしません。
必要な元データがまだない通知は保留し、後から再処理できるようにします。無限再試行せず、回数と期限を超えたものは確認一覧へ出します。
再処理できる履歴を残す
受信日時、通知ID、種類、対象、結果、試行回数、エラー理由を保存します。本文全体の長期保管は個人情報と規約を確認します。
再処理ボタンは権限を限定し、実行前に対象件数と影響を示します。金額や在庫が動くイベントは責任者確認と照合後に再実行します。
相談前にそろえるもの
- 通知ID・イベント種類
- 署名・時刻検証
- 順序逆転・遅延
- 有限再試行・保留
- 履歴・再処理権限
全部そろっていなくても構いません。分かる範囲を確認し、業務ルールや金額に関わる部分は担当者と一緒に決めます。