【ITニュース解説】Polling vs Webhooks for Crypto Payment Status: A Minimal Node.js Example

暗号資産を使った決済システムを構築する際に、顧客からの支払いが完了したかどうかを確実に、かつ迅速に知る方法は、システム開発において非常に重要な課題となる。ブロックチェーン上での取引は、最終的な承認までに一定の時間がかかるため、顧客が支払いを行ってから、その支払いが確定したことをシステムが把握するまでには、時間差が生じる。この時間差を埋めるために、主に二つの異なる仕組みが利用される。一つは「Webhooks（ウェブフック）」、もう一つは「Polling（ポーリング）」である。これらの仕組みを理解し、適切に組み合わせることが、信頼性の高い決済システムを構築する上で不可欠となる。

Webhooksは、外部のサービス（この場合は暗号資産決済ゲートウェイ）から、私たちのシステムに対して「イベントが発生しましたよ」と通知してくれる仕組みだ。例えば、顧客が暗号資産で支払いを行い、それがゲートウェイ側で承認された瞬間に、ゲートウェイが私たちのシステムの特定のURL（エンドポイントと呼ばれる）にメッセージを送信してくる。これにより、支払いが確認されたことを最も早く知ることができる。これは、顧客が注文を完了した直後に商品を発送したり、サービスを提供したりするなど、迅速な対応が求められる場合に非常に有効だ。しかし、Webhooksには弱点もある。インターネット経由でメッセージが送信されるため、ネットワークの混雑や一時的な障害、あるいは私たちのシステムがデプロイ中などで一時的にアクセスできない場合など、何らかの理由でメッセージが届かなかったり、遅延したり、正しい順序で届かなかったりする可能性がある。最悪の場合、支払いが完了しているにもかかわらず、システムがその事実を知らないままとなり、顧客が支払ったにもかかわらず、注文が未払いのまま放置されてしまうという問題が発生しかねない。このようなリスクを考慮すると、Webhooksだけでは完全な信頼性を保証できないことがわかる。

そこで登場するのがPollingだ。Pollingは、私たちのシステムが定期的に決済ゲートウェイに対して「あの支払いの状況はどうなっていますか？」と問い合わせる仕組みを指す。これは、例えば未払いの状態になっている注文がデータベースに存在する場合、それらの注文について数分おきにゲートウェイに問い合わせて、現在の支払い状況を確認するといった方法で利用される。Webhooksのように即座に通知が来るわけではないため、支払い確認までの時間は遅くなる傾向にある。しかし、自分から積極的に情報を取得しに行くため、Webhooksが何らかの理由でメッセージを送信できなかったとしても、後から確実に支払い状況を把握できるという大きなメリットがある。言い換えれば、Webhooksが通知を「プッシュ」するのに対し、Pollingはシステムが情報を「プル」するイメージだ。ただし、Pollingにも欠点はある。ゲートウェイに問い合わせるたびに、API呼び出し回数が増え、それに応じてコストが発生したり、ゲートウェイ側に負荷をかけたりする可能性がある。また、問い合わせの頻度が高すぎると無駄が多くなり、低すぎると支払い確認までの時間が長くなりすぎるため、適切な頻度を設定する必要がある。これらの理由から、Pollingはシステムのメインの支払い確認経路としてではなく、Webhooksが取りこぼした情報や、Webhooksが利用できない場合の「安全網（セーフティネット）」として位置づけるのが一般的だ。

つまり、信頼性の高い暗号資産決済システムを構築するには、Webhooksの「速さ」とPollingの「信頼性」の両方を組み合わせることが最も効果的だ。まず、Webhooksを使って支払いの完了をいち早く検知し、ほとんどのケースで迅速に処理を進める。そして、万が一Webhooksが機能しなかった場合に備えて、Pollingを裏側で定期的に実行し、取りこぼしがないかを確認する。この二段構えの体制によって、システムは速さと確実性を両立できる。

具体的な実装を考える上で、いくつかの重要な点がある。まずWebhooksでメッセージを受け取る際には、そのメッセージが本当に決済ゲートウェイから送られてきたものなのかを確認する「署名検証」という処理が必須だ。これは、メッセージに電子的な署名が付与されており、その署名を検証することで、メッセージが途中で改ざんされていないことや、なりすましではないことを確認するセキュリティ対策である。この検証が失敗した場合、そのメッセージは不正なものとして破棄し、401エラー（未認証）を返す必要がある。また、Webhooksのメッセージを受け取った際には、できるだけ早く「200 OK」などの成功応答をゲートウェイに返すことが重要だ。これは、ゲートウェイ側が「メッセージは無事に届いた」と認識し、再送信などの不要な処理をしないようにするためだ。時間のかかるデータベース更新や注文の履行といった処理は、応答を返した後で、バックグラウンドの非同期処理として実行するのが良い設計である。

次にPollingの実装では、全ての未払い注文を対象にするのではなく、「5分以上保留中の注文」など、特定の条件を満たす注文のみを対象に問い合わせを行うことで、API呼び出し回数を減らし、効率を高めることができる。さらに、非常に古い未払い注文については、問い合わせの頻度を下げる「バックオフ」という仕組みを取り入れることで、無駄なAPI呼び出しをさらに削減できる。

WebhooksとPollingのどちらの経路で支払いが確認されたとしても、最終的に注文の状態を「支払い済み」に更新し、その後の「注文の履行」（商品の発送など）を行う処理は共通でなければならない。ここで重要なのが「冪等性（べきとうせい）」という考え方だ。これは、同じ処理が複数回実行されても、結果が常に同じになるように設計することを意味する。例えば、markPaidIfConfirmedという関数（支払いを確定する関数）は、「もし注文がまだ保留中であれば、支払い済みに更新する」という条件付きの更新処理を行うことで、すでに支払い済みになっている注文に対して再度「支払い済み」にしようとしても、何も変更が起きないようにする。これにより、WebhooksとPollingの両方から同じ注文に対して支払い完了の通知が来たとしても、注文の履行処理が二重に実行されるような事態を防げる。

さらに、システム運用においては、ログをしっかりと記録することが重要だ。どの経路（WebhooksまたはPolling）で支払いが確定されたかを記録することで、もしPolling経由で支払い確定される件数が異常に多い場合、それはWebhooksの受信エンドポイントに問題がある可能性を示唆している。例えば、ファイアウォールがブロックしている、デプロイ時に一時的にシステムが停止しているなど、Webhooksがうまく機能していない原因を特定する手がかりとなる。

最後に、決済ゲートウェイを選定し、統合する際には、そのゲートウェイがWebhooksとPollingの両方についてどのような機能を提供しているか、また、Webhooksの再試行ポリシー（メッセージが届かなかった場合に何回、どのくらいの間隔で再送信してくれるか）などを事前に確認しておくことが、安定したシステムを構築する上で非常に大切だ。これらの仕組みを理解し、適切に組み合わせることで、顧客にとっても、サービス提供者にとっても信頼できる暗号資産決済システムが実現できるだろう。