このページは辞書と一括ツールです。Portal で追跡可能なイベントとして何が存在するか、自社レコードと照合するために
各イベントがどの識別子を持つか、ログはどこまで遡れるか、そして失敗を期間指定で一度にまとめて再送する方法を説明します。
Portal はどのイベントタイプを追跡しますか？
7 つです。これは Event Type フィルターが提供する正確な集合であり、そのフィルターを空にしたときに検索される集合でもあります。
無駄な検索を避けるための 2 つの点：
- チャージバックのイベントはちょうど 1 つです。 チャージバックの作成と案件のステータス変更はすべて
CHARGEBACK_NOTIFICATIONとして届きます。購読できる別のアラートイベントや、別のチャージバック返金イベントは存在しません。 eventType列の値は上記の値そのものです。 Portal で読める値が、自社コードで照合する値です。分かりやすいラベルは表示専用です。
Webhook を自社の注文と照合するにはどうすればよいですか？
すべてのレコードは 1 つの Order ID を持ち、それがどの識別子であるかはイベントによって異なります。対応表は次のとおりです。
チャージバックの行は驚かれることが多いので、はっきり述べておきます。元の決済注文番号でログを検索しても、チャージバック通知は
見つかりません。 そこでの Order ID 列は案件自体の識別子であり、お客様の注文ではありません。レコードを開き、リクエストボディから
originalOrderId を読み取ってください。逆方向にも同じ注意が当てはまります — チャージバックログの Order ID を自社システムの
キーとして使用しないでください。
サブスクリプションについては、アップグレードまたはダウングレードにより新しいサブスクリプション ID が生成されるため、
SUBSCRIPTION_CHANGE_NOTIFICATION は変更前に持っていたサブスクリプション ID とは一致しません。それをキーにしている場合は、
ペイロードから元の ID を読み取ってください。
このうちどれを購読でき、URL はどこから来るのですか？
Portal で設定できるコールバック URL は 2 つのみで、残りはオブジェクトを作成した API 呼び出しに付随します。Webhook ログページで URL を変更できるものはありません — このページは設計上、読み取り専用です。
Portal 側の URL の設定は
Portal セルフサービスセキュリティ設定 で説明しています。イベントがログレコードを
まったく生成しなかった場合、通常の原因は URL が解決されなかったことです。
Webhook イベントログと手動再送 を参照してください。
Webhook ログはどこまで遡れますか？
90 日です。 ページのバナーにそう記載され、日付ピッカーでは 90 日より前の日を選択できず、Retry by Date も同じ期間に 制限されます。それより古いものについては、通知を探すのではなく、照会 API でオブジェクト自体を照会してください。 関連する 2 つの境界：- ログは機能がリリースされた時点から始まります。それ以前の通知はバックフィルされないため、非常に古い取引で結果が空になるのは 想定どおりであり、診断上の意味はありません。
- 一覧はデフォルトで Submission Time の新しい順に並びます。
失敗を期間指定で一度にまとめて再送できますか？
はい — Retry by Date がそのための機能です。エンドポイントが一定期間ダウンしていて、その期間の失敗を 1 件ずつクリックせずに まとめて再配信したい、というまさにそのケースのために存在します。
対象となるのは失敗レコードのみです — 成功したレコードや処理中のレコードは決して含まれないため、エンドポイントがすでに
受け入れたものを誤って再配信することはありません。
1 回のバッチで何件まで再送できますか？
1 リクエストあたり最大 50 件です。 これは Retry by Date と複数選択の再送の両方に適用され、UI 上のヒントではなく 両側で強制されます。 実務上の意味：
バッチは最初の 50 件に黙って切り詰められることはありません — 上限を超えた範囲は即座に拒否されます。これは意図的な設計です。
切り詰められたバッチでは、大部分が再送されていないのに期間全体が再送されたと思い込んでしまいます。大量のバックログは、
スライスに分けて処理してください — まずイベントタイプで分けるとよいでしょう。通常、それが実際のインシデントの境目に沿って
期間を分割してくれます。
一括再送の後、何が返ってきますか？
レコードごとの結果が、単一の成功/失敗ではなく件数として集約されます。
「成功」とは、今回の試行でエンドポイントが配信を受け入れたことを意味します — バッチはリクエストがキューに入ったことではなく、
実際の配信結果を報告します。したがって、すべて失敗で返ってきたバッチは、エンドポイントがまだペイロードを受け入れていないことを
示しています。再送する前に修正してください。
見積もりと送信の間に状態が変わったレコード — たとえばその間に自動再試行で成功したもの — は、もう対象ではないため、
再送されずに失敗数として集計されます。
手動または一括の再送は、自動再試行の回数を消費しますか？
はい — 実際には修正していないエンドポイントに対して期間再送を行う前に、知っておくべきことです。 再送は自動試行と同じ配信経路を通ります。エンドポイントが受け入れなかった場合、その試行は自動試行と同様にレコードの 再試行予算から差し引かれ、次の自動再試行は予算が残っている間のみスケジュールされます。予算を使い切るとレコードは最終的に失敗となり、 Next Retry には— が表示され、以降の自動試行は行われません。
実務上のルール：まずエンドポイントを検証し、その後に再送する。 まだ壊れているエンドポイントに再送すると、本来なら自動で
発火する予定だった試行を無駄に消費します。
Portal は何を「Failed」レコードとみなしますか？
Failed は、最終的に失敗したレコードと、今回は失敗したがまだ自動再試行キューに残っているレコードの両方を含みます。
両者はステータスではなく Next Retry 列で区別されます。
これは Retry by Date に関係します。見積もりは両方の種類の失敗レコードを数えるため、再送する期間には自然に回復したはずの
レコードが含まれることがあります。
成功したレコードに、エンドポイントからのレスポンスが表示されないのはなぜですか？
Portal は配信済みレコードの表示を、サーバーが送った内容を保存するのではなく導出しているためです。成功したレコードには200 の HTTP Response と success のボディが表示されますが、それは「成功」の定義がそうだからです — 配信が成功とみなされるのは、
Webhook 概要 にあるとおり、エンドポイントが HTTP 200 かつ {"message":"success"} の
ボディを返した場合のみです。
実際に取得された詳細は失敗したレコードにのみ存在し、そこにはエンドポイントが返した失敗の概要 — またはトランスポートエラー —
が表示されます。したがって、デバッグ時に情報があるのは失敗したレコードです。成功したレコードの裏に隠れた追加情報はありません。
再送するとログに 2 行目が作成されますか？
いいえ。ビジネスオブジェクトごと、イベントごとに 1 レコードです — 同じ決済注文の決済通知は、その一生を通じて 1 行です。 再送はその行のステータス、レスポンス、試行回数をその場で更新し、行を追加しません。詳細ビューの Notify Count が試行履歴です。 これが、行数で配信量を測れない理由であり、再送されたレコードが後の試行で上書きされると以前の失敗概要を失う理由でもあります。期待するレコードが失敗ではなく完全に欠落している場合は、 Webhook イベントログと手動再送 から始めてください — レコードの欠落はほぼ常に コールバック URL が解決されなかったことを意味し、再送では解決できません。