メインコンテンツへスキップ
Diditが750万ドルを調達、本人確認と不正対策のインフラを構築
Didit
ブログ一覧へ
ブログ2026年2月14日

Webhook連携ガイド:リアルタイム本人確認 (JA)

Webhookを連携して、本人確認ステータスの変更に関するリアルタイム通知を受け取る方法を学びましょう。承認、拒否、レビューに関する最新情報でアプリケーションを強化し、シームレスで安全なユーザー体験を実現します。.

By Didit更新日
webhook-integration-guide-real-time-identity-verification.png

リアルタイムアップデートWebhookは、本人確認ステータスの変更に関する即時通知を提供し、迅速な対応とユーザーエクスペリエンスの向上を実現します。

強化されたセキュリティ署名検証方法により、Webhookリクエストの信頼性を確保し、悪意のある攻撃者からアプリケーションを保護します。

柔軟な連携複数の署名ヘッダーがさまざまな連携シナリオに対応し、異なるWebフレームワークおよびミドルウェアとの互換性を確保します。

Diditによるワークフローの簡素化Diditのプラットフォームは、簡単なWebhook設定と包括的なドキュメントを提供し、開発者がリアルタイムの本人確認通知をアプリケーションに迅速に統合できるようにします。

本人確認におけるWebhookの理解

Webhookは、応答性が高く効率的な本人確認ワークフローを構築するための重要なコンポーネントです。 これにより、Diditの本人確認プラットフォームとアプリケーション間のリアルタイム通信が可能になり、確認セッションのステータスに関する最新情報が即座に提供されます。 更新を常にポーリングする代わりに、セッションのステータスが変更されると(たとえば、「未開始」から「進行中」、または「レビュー中」から「承認済み」)、アプリケーションは即時通知を受信します。 これにより、プロセスの自動化、ユーザーエクスペリエンスの向上、および問題への迅速な対応が可能になります。

たとえば、ユーザーが確認のためにIDを送信するシナリオを想像してください。 Webhookがない場合、アプリケーションは確認のステータスを定期的に確認する必要があります。 Webhookを使用すると、確認が承認されるとすぐに、アプリケーションは通知を受信し、ユーザーにサービスへのアクセスをすぐに許可できます。 これにより、遅延が減少し、よりスムーズでシームレスなエクスペリエンスが提供されます。

Diditの本人確認のためのWebhookの設定

Diditでのwebhookの設定は簡単なプロセスです。 まず、Diditプラットフォーム内でチームとアプリケーションを設定する必要があります。 次に、確認設定に移動して、webhook URLを入力します。 このURLは、Diditがリアルタイム通知を送信する場所です。 また、受信リクエストを検証し、それらがDiditからのものであることを確認するために使用するWebhook Secret Keyをコピーすることも重要です。

Webhookエンドポイントのセキュリティを確保するために、Diditは複数の署名検証方法を提供しています。 これらの方法は、秘密鍵を使用してwebhookペイロードのハッシュを作成し、それをwebhookリクエストに含まれる署名と比較できます。 これにより、リクエストが本物であり、改ざんされていないことが保証されます。 Cloudflareを使用している場合は、webhookを受信するためにDiditのIPアドレス(18.203.201.92)をホワイトリストに登録する必要があります。

署名検証方法:Webhookの信頼性の確保

Diditは、さまざまな連携シナリオに対応するために、3つの署名ヘッダーを提供しています。

  • X-Signature:これは、リクエスト本文で送信された正確な生のJSONバイトに署名します。 解析または再エンコードの前に、生のリクエスト本文に直接アクセスする必要があり、ミドルウェアがUnicode文字を異なる方法で再エンコードすると失敗する可能性があります。
  • X-Signature-V2推奨される方法で、エスケープされていないUnicode JSONに署名します。 ミドルウェアがJSONを再エンコードした場合でも機能するため、ほとんどのWebフレームワークと互換性があります。
  • X-Signature-Simple:これは、"{timestamp}:{session_id}:{status}:{webhook_type}"というコアフィールドのみに署名します。 これはJSONエンコードとは完全に独立していますが、決定またはその他のフィールドの整合性は検証しません。

V2はミドルウェアがJSONを再エンコードした場合でも機能するため、最初にX-Signature-V2を試すことをお勧めします。 V2が失敗した場合は、X-Signature-Simpleにフォールバックします。 生のリクエストバイトに直接アクセスできる場合にのみ、X-Signatureを使用してください。

Webhookイベントタイプとデータ構造

Diditは、次のイベントタイプのWebhookを送信します。

  • status.updated:確認ステータスが変更されるたびにトリガーされます。 これには、セッションの開始時に送信される最初のWebhookが含まれます。
  • data.updated:KYCまたは住所証明(POA)データがAPI経由でレビュー担当者によって手動で更新されたときにトリガーされます。 これにより、データの修正または手動レビューとの同期を維持できます。

各Webhookペイロードには、それをトリガーしたイベントを示すwebhook_typeフィールドが含まれています。 セッションステータスがApprovedDeclinedIn Review、またはAbandonedの場合、Webhookには、詳細な確認結果を含むdecisionフィールドも含まれます。 session_idは常に含まれており、vendor_dataworkflow_id、およびmetadataフィールドは、セッションに存在する場合にのみ含まれます。

Webhookの再試行とエラーの処理

Webhookの配信に失敗した場合(つまり、エンドポイントが200以外のHTTPステータスコードを返す場合)、Diditは指数バックオフで最大5回まで配信を再試行します。 5回の試行が失敗すると、Webhookはドロップされます。 Webhookエンドポイントが信頼性が高く、受信リクエストを迅速に処理できることを確認することが重要です。 また、エラーログと監視を実装して、Webhookの配信エラーの原因となる可能性のある問題を特定して解決する必要があります。

問題を回避するには、サーバーがWebhookイベントの予想される負荷を処理できることを確認してください。 さらに、Webhook署名を検証してリクエストの信頼性を確認し、適切なエラー処理を実装して予期しない問題を適切に管理します。 これらのベストプラクティスに従うことで、Diditの本人確認プラットフォームとの信頼性が高く安全なWebhook連携を確保できます。

Diditの支援

Diditは、ユーザーフレンドリーなプラットフォームと包括的なドキュメントを通じて、リアルタイムの本人確認通知の統合を簡素化します。 ID検証パッシブ&アクティブ・ライブネス、およびAMLスクリーニングとモニタリングを含むDiditの本人確認スイートは、モジュール式で既存のシステムに簡単に統合できるように設計されています。

DiditのプラットフォームはAIネイティブであり、本人確認における高度な機能と優れた精度を可能にします。 柔軟なWebhook設定オプションと複数の署名検証方法により、アプリケーションが安全で信頼性の高いリアルタイムアップデートを受信できるようになります。 さらに、Diditの無料のコアKYCティアを使用すると、セットアップ料金なしでWebhookの統合と本人確認を開始できます。

Diditを本人確認プロバイダーとして選択し、開発者優先のアプローチ、インスタントサンドボックスアクセス、およびクリーンなAPIのメリットを享受してください。 Diditの堅牢でスケーラブルなプラットフォームでワークフローを自動化し、ユーザーエクスペリエンスを向上させます。

始める準備はできましたか?

Diditの動作を確認する準備はできましたか? 今すぐ無料のデモを入手してください。

Diditの無料ティアで、無料で本人確認を開始してください。

本人確認と不正対策のインフラ。

KYC、KYB、取引監視、ウォレットスクリーニングを一つのAPIで。5分で統合できます。

AIにこのページの要約を依頼する
リアルタイム本人確認のためのWebhook連携.