> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhook イベントログと手動再送

> Merchant Portal で Webhook の配信状況を確認する方法：何が配信成功とみなされるか、レコードがまったく存在しない理由、各イベントに表示される Order ID、手動再送と自動リトライの関係。

Merchant Portal の **Webhooks** ページには、Waffo が貴社に送信したすべての Webhook が記録され、
失敗したものを貴社自身で再送できます。コールバックの仕様自体は
[Webhook 概要](/docs/ja/developer-docs/webhook/overview)と [Webhook リトライ](/docs/ja/developer-docs/webhook/retry)に、
URL の設定は [Portal セルフサービスセキュリティ設定](/docs/ja/support/portal-security-config-faq)にあります。

## 特定の Webhook が配信されたかどうかはどのように確認できますか？

**Merchant Portal → Webhooks** を開き、イベントタイプ、ステータス（`SUCCESS` / `FAILED`）、Order ID、
または期間でフィルターします。各レコードには次の情報が含まれます。

| フィールド | 内容 |
| - | - |
| Event type | プッシュされたイベントの種類（決済、返金、チャージバック、サブスクリプション）。 |
| Status | `SUCCESS` または `FAILED`。貴社の HTTP レスポンスから判定されます。 |
| Order ID | イベントのビジネス識別子。後述の表を参照。 |
| Notify URL | この試行で実際に使用されたコールバック URL。 |
| Triggered at | 配信レコードが作成された時刻。 |
| Next retry | 次回の自動リトライが予定されている時刻。レコードが失敗しており、*かつ*リトライ回数が残っている場合に**のみ**設定されます。したがって、配信済みのレコードでも、リトライを使い切ったレコードでも空になります。 |
| Request body | Waffo が送信した完全なペイロード（詳細ビューで表示）。 |
| HTTP response | 貴社のエンドポイントが返した失敗の概要（失敗レコードのみ）。 |

ログは本機能のリリース時点から開始されます。それより古い通知は遡って記録されません。

## 通知を発生させた直後なのにリストに表示されません。失われたのですか？

おそらく失われていません。送信中の通知は、リストが**デフォルトでは返さない**処理中状態にあるため、
レコードが表示されるまで数秒かかることがあります。これは、処理中の試行が `FAILED` として表示されないようにするための
意図的な仕様です。

## サーバーは HTTP 200 を返したのに、Waffo では FAILED と表示されるのはなぜですか？

HTTP 200 だけでは不十分です。配信が `SUCCESS` とみなされるのは、貴社のエンドポイントが
**HTTP 200 *かつ* レスポンスボディ `{"message":"success"}`** を返した場合のみです。
それ以外の結果 — 異なるボディや空のボディを伴う HTTP 200、`failed`、`unknown`、タイムアウト、
パースできないレスポンス — はすべて `FAILED` です。

## 失敗した Webhook を自分で再送できますか？

はい。3 つのモードがあります。

| モード | 使用する場面 |
| - | - |
| 単一 | 特定の 1 イベントを再駆動する場合。 |
| 複数選択 | リストから複数の失敗レコードを選択した場合。 |
| 期間指定 | 一定期間エンドポイントがダウンしており、その期間内の失敗をまとめて再送したい場合。 |

1 回のリクエストで再送できるのは**最大 50 レコード**です。期間指定モードでは、まずその期間の失敗レコード数を
見積もり、上限を超える場合は期間を狭めることができます。

## 手動再送は自動リトライのキューに戻りますか？

**はい。これが最も見落とされやすいポイントです。** 手動再送は自動再送と同じ配信経路を通ります。
レコードのリトライ回数に対する 1 回の試行としてカウントされ、失敗した場合は回数が残っている限り次回の自動リトライが
再スケジュールされます。次回リトライ時刻は、回数を使い切った時点でのみクリアされます。

その結果、**まだ壊れているエンドポイントに対して手動再送すると、残りの試行回数を 1 回消費します。**
まずエンドポイントを確認または修正してから再送してください。回数を使い切ると、レコードは次回リトライ時刻なしの
`FAILED` のままとなり、その復旧は貴社側の作業になります。再配信を待つのではなく、
[Order Inquiry](/docs/api-reference/introduction) で
読み戻してください。

## 一部のレコードで Resend がグレーアウトしているのはなぜですか？

レコードを再送できない理由はちょうど 3 つです。**コールバック URL** が保存されていない（送信先がない）、
**初回配信がまだ進行中**である（処理中の試行は再送できない）、またはレコードが**貴社のマーチャント ID に属していない**。

すでに正常に配信されたレコードはこのリストに**含まれません**。配信成功したレコードは意図的に再送*できる*ようになって
います。Waffo が受理済みと記録した配信であっても、貴社側で処理されていない可能性があるためです。

再送には、Portal ロールに Webhook 再送権限も必要です。権限がない場合、アクションと行選択は無効化表示されるのではなく
まったくレンダリングされません。したがって、どこにも再送コントロールが見えない操作者が直面しているのは権限の問題であり、
再送可否の問題ではありません。Portal の Admin にご確認ください。

## Webhooks ページに、ある取引のレコードがまったくありません

結果が空である場合、ほとんどは**通知 URL が解決されなかった**ことを意味し、配信が失敗したことを意味するものではありません。
URL がなければ、Waffo は何も送信せず、ログレコードも書き込みません。そのイベントタイプがどこから URL を取得するかを確認してください。

| イベント | URL の取得元 |
| - | - |
| 決済 | 注文作成時に渡された `notifyUrl`。 |
| 返金 | 返金リクエストの `refundNotifyUrl` が優先されます。空の場合は Portal で設定された Refund Notify URL が使用され、その返金注文に保存されます。 |
| チャージバック | Portal で設定された Chargeback Notify URL のみ。リクエストごとに渡すことはできません。 |
| サブスクリプション | サブスクリプションオブジェクト自体に保持されている `notifyUrl`。 |

したがって、チャージバックのレコードがない場合は通常 Chargeback Notify URL が設定されていなかったことを意味し、
返金のレコードがない場合はリクエストパラメーターも Portal 設定も存在しなかったことを意味します。

## ログにはどの Order ID が表示されますか？元の注文番号でチャージバックが見つからないのはなぜですか？

Order ID 列はイベント自身の識別子であり、イベントごとに異なります。

| イベント | ログ上の Order ID |
| - | - |
| 決済 | `acquiringOrderId` |
| 返金 | `acquiringRefundOrderId` |
| サブスクリプションのステータス / 期間変更 | `subscriptionId` |
| チャージバック | チャージバック案件の異議申し立て参照番号 |

チャージバックのレコードは異議申し立て参照番号で一覧・検索され、元の決済注文では**ありません**。
チャージバック通知を元の注文番号で検索しても何も返りません。その番号はペイロード内の `originalOrderId` として
運ばれるため、レコードの詳細ビューにあるリクエストボディから読み取ってください。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.