受信と処理完了を区別する
保証は提供元によって異なります。Stripeは重複の可能性と順序を保証しないことを明記しています。HTTP成功応答は、単にメモリーへ届いたことではなく、永続的な受信または予定した処理に対応させます。
| 状況 | 期待する動作 | 役立つ証拠 |
|---|---|---|
| 同じイベントが2回届く | 業務上の効果の重複を防ぐ。 | 処理済みIDと永続結果。 |
| 古いイベントが遅れて届く | 新しい状態を無条件に上書きしない。 | 正本の状態と遷移規則。 |
| 重い処理 | 永続受信後に遅延実行。 | キュー状態とワーカー結果。 |
| 配信が欠ける | 提供元の規則に沿って照合・回復。 | 特定した差分と検証済み修正。 |
検証可能な受信を作る
- 提供元のプロトコルに従ってHTTPS、署名、リプレイ対策を確認します。Stripeは生の本文で署名を検証し、先にJSONを変換すると検証できなくなる場合があります。
- 適切な受領応答の前にイベントまたは処理を永続化します。配信ID、イベントID、業務処理の冪等キーを区別します。
- 重複、順序違い、ワーカー中断、再起動を試験します。古いイベントだけで安全に判断できなければ、正本のオブジェクト状態を取得します。
回復と照合を用意する
試行、期限、未処理イベント、提供元との照合手順を文書化します。速い受領応答が後続の失敗を隠す場合があります。最終的な業務処理も監視し、秘密や個人情報のログを制限します。
一次資料
繰り返し発生するWebhookを安全に処理します。
タイムアウトまたは応答の消失後、通知が繰り返される場合があります。信頼性は、オリジン検証、イベント識別子、および新規メッセージと重複メッセージを区別する処理に依存します。
- プロバイダのメカニズムを使用して、各リクエストを検証します。
- 再試行、重複、および到着順序の変更をテストします。
- 処理後または永続キューイング後に、一貫して確認応答を行います。
一次資料:IETF RFC 9457 — Problem Details for HTTP APIs. 関連する方法:実践ガイドを読む.
