メインコンテンツへスキップ
すべての認証セッションは、一連のステータスを経て進みます。各ステータスを理解しておくと、ユーザーの進捗の把握、コンプライアンス判定の自動化、コンバージョンの最適化に役立ちます。 この enum は、GET /v3/session/<id>/decision/とすべての Didit Webhook で返される文字列の唯一の正式な定義です。

すべてのステータス値

各ステータスは、Didit APIとWebhookが返す正確な文字列です。コードでは必ず厳密な文字列比較(例: === "In Review")を使用してください。これらの値は大文字と小文字が区別され、スペースを含みます。また、Kyc Expiredの値は先頭のKのみが大文字です(KYCではありません)。

セッションステータス

APIの値: "Not Started"セッションはAPI経由で作成されましたが、ユーザーはまだ認証リンクを開いていません。
  • 対応: ユーザーが開始するのを待つか、時間が経ちすぎた場合はリマインダーを送信します。
  • 遷移先: "In Progress"、"Expired"
APIの値: "In Progress"ユーザーがリンクを開き、検証ステップを進めている最中です(書類の撮影、ライブネスなど)。
  • 対応: 対応は不要です。ユーザーがフローを進めています。
  • 遷移先: "Approved"、"Declined"、"In Review"、"Abandoned"
APIの値: "Approved"すべての検証チェックに合格しました。ユーザーの本人確認が完了しています。
  • 対応: ユーザーにアクセスを許可し、プロフィールを更新して、判定データを保存します。
  • Webhookの内容: すべての機能の結果を含む完全なdecisionオブジェクト。
  • 遷移先: "Kyc Expired"(検証済み書類の有効期限が過ぎたとき。その国と書類タイプのExpiration modeがAllow expiredでない限り、これがデフォルトの動作です)。レビュアーまたはupdate-statusエンドポイントにより、"Declined"または"Resubmitted"に設定することもできます。
APIの値: "Declined"1つ以上の検証チェックが失敗しました。ユーザーは認証に合格しませんでした。
  • 対応: ユーザーに通知します。問題が修正可能な場合は、必要に応じて再提出を依頼します。
  • Webhookの内容: 失敗の理由を説明する警告を含む完全なdecisionオブジェクト。
  • 遷移先: "Resubmitted"(レビュアーが依頼した場合)。レビュアーまたはupdate-statusエンドポイントにより、"Approved"に設定することもできます。
APIの値: "In Review"自動チェックで人による確認が必要な警告が検出されました。コンプライアンス担当のレビュアーが最終判定を下す必要があります。
  • 対応: レビュアーがConsoleでセッションを開き、承認、却下、または再提出の依頼を行います。
  • Webhookの内容: 警告を含む完全なdecisionオブジェクト。
  • 遷移先: "Approved"、"Declined"、"Resubmitted"
APIの値: "Awaiting User"KYB(法人確認)セッションで、主要人物ステップが関係者のリストを提出し、子KYC/KYBセッションを生成したときに使用されます。親セッションは、必須の関係者全員が個別の認証を完了するまで待機します。
  • 対応: 子KYCセッションのステータスを監視します。必須の関係者全員が完了すると(承認済み、却下、または期限切れ)、親セッションは自動的に再集計され、最終ステータスになります。
  • Webhookの内容: 現在の関係者リストと、それぞれの子セッションのステータス。
  • 遷移先: "Approved"、"Declined"、"In Review"(すべての子セッションが終了ステータスになった時点)
  • 遷移元: "In Progress"(主要人物ステップの送信後)
  • 注意: 子KYCセッションが再提出された場合、親セッションは再提出されたセッションが完了するまで"Awaiting User"に戻ります。KYB Registry Checkが"Declined"の場合は、"Awaiting User"より優先されます。
APIの値: "Resubmitted"レビュアーがユーザーに特定の検証ステップのやり直しを依頼しました(例: ぼやけた書類写真の撮り直し)。
  • 対応: ユーザーが再提出のステップを完了するのを待ちます。システムが自動的に再評価します。
  • Webhookの内容: やり直す機能のリストと理由を含むresubmit_infoオブジェクト。
  • 遷移先: "Approved"、"Declined"、"In Review"、または本人がステップをやり直す前にセッションの有効期間が終了した場合は"Abandoned"。
APIの値: "Expired"ユーザーが認証リンクを開く前にセッションがタイムアウトしました。
  • 対応: 新しいセッションを作成し、新しいリンクをユーザーに送信します。
  • 終了ステータスです。これ以上の遷移はありません。
APIの値: "Abandoned"ユーザーは認証を開始しましたが、所定の期間内に完了しませんでした。
  • 対応: リマインダーを送信するか、新しいセッションを作成します。
  • 自動遷移はありません。 ただし、レビュアーまたはPATCH /v3/session/{sessionId}/update-status/により、"Approved"、"Declined"、"Resubmitted"に設定することは可能です。
APIの値: "Kyc Expired"セッション中に検証された書類が、書類自体の有効期限を過ぎました。トリガーはその日付であり、承認からの経過期間ではありません。また、事前に警告は送信されません。
  • 対応: 新しいセッションで再検証するようユーザーに依頼します。status.updatedがこの遷移を配信し、本人確認の結果にはDOCUMENT_EXPIRED警告が含まれます。
  • 制御方法: ID verification → Additional settings by country & document typeにある、その国と書類タイプのExpiration modeで制御します。Reject expired(デフォルト)では書類の有効期限を監視し、Allow expiredではセッションがこのステータスに移行することはありません。
  • 自動遷移はありません。 ただし、レビュアーまたはPATCH /v3/session/{sessionId}/update-status/により、"Approved"、"Declined"、"Resubmitted"に設定することは可能です。

ステータスの遷移

ライフサイクル図


終了ステータスと非終了ステータス


コードでのステータスの処理

ステータスの変化に対応するには、Webhookまたはセッション取得APIを使用します。
ステータスはスペースを含み、大文字と小文字を区別する正確な文字列です。たとえば、"In Review"であり、"in_review"や"IN_REVIEW"ではありません。照合する際は必ず厳密等価演算子(===)を使用してください。

再提出

再提出済みステータスを使うと、コンプライアンスチームは新しいセッションを作成せずに、ユーザーにもう一度機会を与えることができます。
1

レビュアーが再提出を開始する

コンソールでIn ReviewまたはDeclinedのセッションを開き、Request Resubmissionをクリックします。やり直しが必要なステップを選択します。
2

以前のデータがアーカイブされる

システムは選択された機能をリセットし、以前のデータをprevious_attemptとしてマークします。これにより監査証跡全体が保持されます。
3

ユーザーに通知される

メールアドレスがある場合、ユーザーは再開するための直接リンクを含むローカライズされたメールを受け取ります。
4

ユーザーが特定のステップをやり直す

ユーザーはフラグが付いたステップのみを繰り返します。検証全体をやり直す必要はありません。
5

システムが再評価する

完了すると、セッションは自動的に"Approved"、"Declined"、または"In Review"に遷移します。

再提出のWebhookペイロード

reasonsは、再提出された各node_idを、そのステップで最も関連性の高いログの警告コード(判定が報告するものと同じコード)に対応付けます。そのため、独自の文言に対応付けることができます。これは、ホスト型フローの再提出画面と再提出メールがユーザー向けにローカライズするコードでもあります。ただし、スクリーニングや不正のシグナルを明かしてしまう警告(重複、AML、ブロックリスト、組織間チェック、位置情報の整合性など)は例外です。これらの場合、本人には一般的な理由が表示されますが、Webhookのresubmit_info.reasonsには常に実際のコードが含まれます。警告が記録されていないステップにはエントリがありません。

再提出できる機能

承認済み以外のステータスを持つ機能はすべて再提出できます。対象は却下、レビュー中、Not Finished、Not Started、期限切れです。
同じセッションで再提出を複数回リクエストできます。サイクルごとに以前の試行データがアーカイブされるため、ユーザーの検証履歴をすべて把握できます。

ベストプラクティス

レビュー中を監視する

Didit Consoleでアラート(メールまたはSlack)を設定し、セッションが手動レビューを必要とする際に通知を受け取れるようにします。

再提出を優先する

問題が修正可能な場合(写真のぼやけや書類の表裏の誤りなど)は、却下せずに再提出をリクエストしてください。これによりコンバージョン率が向上します。

離脱を追跡する

放棄や期限切れの割合が高い場合は、ユーザー体験上の障壁がある可能性があります。セッションのTTLの調整やユーザーへの案内の改善を検討してください。

冪等なハンドラー

Webhookは再試行される場合があります。session_idを一意のキーとして使用し、各ステータス変更を一度だけ処理するようにしてください。
ペイロードを処理する前に、必ずWebhookの署名を検証してください。Diditは3つの方法を提供しています。X-Signature、X-Signature-V2(推奨)、そしてエンベロープのみを認証しdecisionの本文は一切認証しない非推奨のX-Signature-Simpleです。詳しくはWebhookを参照してください。
最終更新日 2026年11月1日