Webhookとは？仕組みと導入メリットをわかりやすく解説

Webhook（ウェブフック）とは、決済代行会社などの外部サービス側で何らかのイベントが発生したときに、そのサービスから自社の指定したURLへ自動的に通知が送られてくる仕組みのことです。決済の世界でも、入金確認や定期課金の自動更新など、事業者側が何も操作していないときに、その処理がどうなったかを知りたい場面で広く使われています。

この記事では、Webhookの基本的な意味と仕組み、よく似た仕組みとの違い、導入するメリット・デメリットを、これから決済システムの導入を検討する事業者の方向けにわかりやすく解説します。

Webhookとは？基本の意味を解説

Webhookとは、何らかのイベント（システム上で起きた出来事）が発生したときに、外部サービス側のシステムから、あらかじめ指定しておいた自社のURLへ自動的にHTTPの通知が送られてくる仕組みのことです。ここでいう「外部サービス」とはPAY.JPのような決済代行会社のこと、「自社」とは決済機能を導入している事業者側のシステムのことを指します。

Webhookを理解するうえで比較になるのが、事業者側から能動的に問い合わせを行うAPI（決済APIとはで詳しく解説しているとおり、システム同士がデータをやり取りするための共通の窓口）です。このAPIへの問い合わせを一定間隔で繰り返し、状態の変化を確認する方法をポーリングと呼びます。3つの違いを整理すると、次のようになります。

つまりWebhookは、事業者が毎回確認しに行かなくても、変化があったタイミングで決済代行会社側から自動的に教えてもらえる仕組みだといえます。

Webhookの仕組み｜通知が届くまでの流れ

Webhookの仕組みには、主に2つの登場人物が関わります。

• 決済代行会社：決済処理を行い、イベントが発生するたびにWebhookで通知を送る側
• 事業者：通知を受け取るためのURL（エンドポイント、外部からのリクエストを受け取れるように公開した窓口のこと）をあらかじめ用意しておく側

大まかな流れは、次のとおりです。

決済・入金・キャンセルなどのイベントが発生 → 決済代行会社が事業者のエンドポイントへ自動で通知を送信 → 事業者側のシステムが通知を受信し、内容を確認 → 正常に受信したことを応答 → 事業者側で必要な処理（会員ステータスの更新、入金確認など）を実行

このとき、事業者側では2つの点に備えておく必要があります。1つ目は、届いた通知が本物の決済代行会社から送られたものかを確認する仕組みです。多くの決済代行会社は、なりすましによる不正な通知を見分けるための検証の仕組みを用意しています。2つ目は、通知が正常に受け取れなかった場合に備えた再送（リトライ）の仕組みです。事業者側のサーバーが一時的にダウンしていたなどの理由で通知を受け取れなかった場合に備え、決済代行会社側で一定回数・一定間隔で通知を送り直す仕組みが用意されているのが一般的です。

Webhookとポーリングとの違い

たとえば、定期課金の引き落としが成功したかどうか、入金が完了したかどうかを知りたいとき、といった「決済代行会社側の最新の状態を知りたい」という場面を考えてみましょう。この目的自体は、Webhookを使わなくても、事業者側から一定間隔でAPIに問い合わせを繰り返すポーリングという方法でも実現できます。それぞれの特徴を比較すると、次のとおりです。

サブスクリプション（定期課金）の自動更新のように、購入者が何も操作していないタイミングで裏側の処理が実行される場面では、ポーリングで毎回確認するよりもWebhookで結果を受け取る方が効率的です。定期課金の仕組み自体についてはサブスクとは？でも詳しく解説しています。

反対に、月次の請求データをまとめて会計システムへ反映するような、リアルタイム性が求められず確認の頻度も少なくてよい場面では、通知を受け取るエンドポイントをわざわざ用意しなくて済むポーリングの方が向いていることもあります。

Webhookを導入するメリット・デメリット

メリット

• 状況の変化をリアルタイムに近い形で把握できる：決済の成功・失敗や入金といった結果を、事業者側から確認しに行かなくても検知できる
• 確認作業を自動化できる：会員ステータスの更新や入金確認といった作業を、通知をきっかけに自動化できる
• 非同期で発生するイベントにも対応できる：3Dセキュア認証（購入者にパスワードなどの追加入力を求める、クレジットカードの本人確認の仕組み）のように途中で購入者の追加操作が挟まる場合や、返金・不正検知のように後から発生する処理にも対応できる

デメリット・注意点

• 通知を受け取る仕組み（エンドポイント）を用意する開発・運用体制が必要：Webhookを利用するには、通知を受け取って処理するプログラムを自社サーバー側に実装する必要がある
• 通知の欠落・重複に備えた設計が必要：自社サーバーが一時的にダウンしていた場合に通知を取りこぼす可能性や、再送によって同じ通知が複数回届く可能性を考慮した設計が求められる
• 決済代行会社ごとに仕様が異なる：検証方法や再送の回数・間隔は決済代行会社によって異なるため、利用する決済代行会社の仕様を確認しておく必要がある

決済まわりでWebhookが使われる代表的な場面

決済の領域でWebhookが活用される代表的な場面には、次のようなものがあります。

• 定期課金（サブスクリプション）の自動更新結果の検知：毎月・毎年の自動引き落としが成功したか失敗したかを検知し、会員ステータスの更新や利用制限に反映する
• 入金確認・会計システムとの連携：入金が完了したタイミングで通知を受け取り、自社の会計・請求書発行システムへ自動的に反映する
• 不正利用の疑いがある取引の検知：不正が疑われる取引が発生した際に通知を受け取り、対応フローを開始する
• 3Dセキュア認証など、購入者の追加操作を伴う決済結果の検知：認証の完了を待ってから決済結果が確定する処理の結果を検知する

PAY.JPのWebhookで実現できること

PAY.JPにも、Webhookの仕組みが用意されています。PAY.JP APIドキュメント（Webhook）によると、支払いの成功、定期課金の引き落とし・期間更新、定期課金のキャンセル、不正懸念の取引が登録されたときなど、さまざまなイベントが発生するたびに、あらかじめ登録しておいたURLへHTTP（POST）で通知が送られる仕組みです。

前述のとおり、Webhookでは「届いた通知が本物かどうかの検証」と「届かなかった場合の再送」の仕組みが重要になります。PAY.JPでは、次のような仕様になっています。

• 検証方法：X-Payjp-Webhook-Tokenというヘッダーに、アカウントごとに割り当てられた固定のトークンIDが含まれており、これがあらかじめ控えておいた値と一致するかどうかで送信元を確認する仕組み
• 再送（リトライ）の仕様：通知の配信に失敗した場合（200番台以外のステータスコード＝通信の結果を表す数字が返ってきた場合・10秒のタイムアウト・接続エラー時）、3分間隔で最大3回（合計9分程度）まで再送する仕様

管理画面から設定できる通知イベントの詳細はイベント通知の詳細が知りたいでも確認できます。決済サービスによって検証方法・再送の仕様は異なり、たとえばStripeでは署名を計算して改ざんの有無まで確認する方式が採用されています。この違いを含めた実装レベルの詳細はStripe Webhookとは？で解説していますので、開発担当の方はあわせてご確認ください。

これから決済機能の導入を検討する方は、【はじめにお読みください】導入をご検討中の事業主様へもご覧ください。

まとめ

• Webhookとは、外部サービス側でイベントが発生したときに、自社の指定したURLへ自動的に通知が送られてくる仕組み
• 事業者側から能動的に問い合わせるAPI・ポーリングとは逆に、決済代行会社側から受動的に知らされる点が特徴
• 通知を受け取るための仕組み（エンドポイント）を用意する必要がある一方、確認作業を自動化でき、非同期で発生するイベントにも対応できる
• 定期課金の自動更新結果や入金確認、不正利用の検知など、決済の領域で幅広く活用されている
• PAY.JPのWebhookは固定トークンによる検証方式と3分間隔・最大3回の再送を備えており、詳細はPAY.JP APIドキュメントで確認できる