特定の Webhook が配信されたかどうかはどのように確認できますか？
Merchant Portal → Webhooks を開き、イベントタイプ、ステータス（SUCCESS / FAILED）、Order ID、
または期間でフィルターします。各レコードには次の情報が含まれます。
ログは本機能のリリース時点から開始されます。それより古い通知は遡って記録されません。
通知を発生させた直後なのにリストに表示されません。失われたのですか？
おそらく失われていません。送信中の通知は、リストがデフォルトでは返さない処理中状態にあるため、 レコードが表示されるまで数秒かかることがあります。これは、処理中の試行がFAILED として表示されないようにするための
意図的な仕様です。
サーバーは HTTP 200 を返したのに、Waffo では FAILED と表示されるのはなぜですか？
HTTP 200 だけでは不十分です。配信がSUCCESS とみなされるのは、貴社のエンドポイントが
HTTP 200 かつ レスポンスボディ {"message":"success"} を返した場合のみです。
それ以外の結果 — 異なるボディや空のボディを伴う HTTP 200、failed、unknown、タイムアウト、
パースできないレスポンス — はすべて FAILED です。
失敗した Webhook を自分で再送できますか？
はい。3 つのモードがあります。
1 回のリクエストで再送できるのは最大 50 レコードです。期間指定モードでは、まずその期間の失敗レコード数を
見積もり、上限を超える場合は期間を狭めることができます。
手動再送は自動リトライのキューに戻りますか？
はい。これが最も見落とされやすいポイントです。 手動再送は自動再送と同じ配信経路を通ります。 レコードのリトライ回数に対する 1 回の試行としてカウントされ、失敗した場合は回数が残っている限り次回の自動リトライが 再スケジュールされます。次回リトライ時刻は、回数を使い切った時点でのみクリアされます。 その結果、まだ壊れているエンドポイントに対して手動再送すると、残りの試行回数を 1 回消費します。 まずエンドポイントを確認または修正してから再送してください。回数を使い切ると、レコードは次回リトライ時刻なしのFAILED のままとなり、その復旧は貴社側の作業になります。再配信を待つのではなく、
Order Inquiry で
読み戻してください。
一部のレコードで Resend がグレーアウトしているのはなぜですか？
レコードを再送できない理由はちょうど 3 つです。コールバック URL が保存されていない（送信先がない）、 初回配信がまだ進行中である（処理中の試行は再送できない）、またはレコードが貴社のマーチャント ID に属していない。 すでに正常に配信されたレコードはこのリストに含まれません。配信成功したレコードは意図的に再送できるようになって います。Waffo が受理済みと記録した配信であっても、貴社側で処理されていない可能性があるためです。 再送には、Portal ロールに Webhook 再送権限も必要です。権限がない場合、アクションと行選択は無効化表示されるのではなく まったくレンダリングされません。したがって、どこにも再送コントロールが見えない操作者が直面しているのは権限の問題であり、 再送可否の問題ではありません。Portal の Admin にご確認ください。Webhooks ページに、ある取引のレコードがまったくありません
結果が空である場合、ほとんどは通知 URL が解決されなかったことを意味し、配信が失敗したことを意味するものではありません。 URL がなければ、Waffo は何も送信せず、ログレコードも書き込みません。そのイベントタイプがどこから URL を取得するかを確認してください。
したがって、チャージバックのレコードがない場合は通常 Chargeback Notify URL が設定されていなかったことを意味し、
返金のレコードがない場合はリクエストパラメーターも Portal 設定も存在しなかったことを意味します。
ログにはどの Order ID が表示されますか？元の注文番号でチャージバックが見つからないのはなぜですか？
Order ID 列はイベント自身の識別子であり、イベントごとに異なります。
チャージバックのレコードは異議申し立て参照番号で一覧・検索され、元の決済注文ではありません。
チャージバック通知を元の注文番号で検索しても何も返りません。その番号はペイロード内の
originalOrderId として
運ばれるため、レコードの詳細ビューにあるリクエストボディから読み取ってください。