データベース検証 - サービスの有効化と課金対象
データベース検証は、抽出した本人情報を政府または公的な登録簿と照合します。サービスに「オンボーディングが必要です」と表示される理由、403や空の応答が返る理由、どのクエリが課金されるかを説明します。
データベース検証は公的な登録簿に対してバックグラウンドで実行され、本人がそれを目にすることはありません。 組織の初回チャージの後にはじめて有効になり、一部のサービスはDiditが有効化するまで **「オンボーディングが必要です」**と表示され、登録簿が実際に応答したクエリはすべて課金されます。 不一致であっても課金対象です。
書類を読み取ると、そこに何が印字されているかが分かります。データベース検証は、公的な情報源がそれに同意するかどうかを教えてくれます。戸籍・住民登録簿、税務当局、信用情報機関、運転免許データベースなどです。各国は1つ以上のサービスを提供しており、それぞれに料金、入力項目、同意の規則があります。対応国とサービスとサービスごとの料金を参照してください。
#書類ステップの後に、静かに実行される
データベース検証の画面はありません。このステップは、身分証から抽出したデータ（またはセッション作成時に渡したデータ）を登録簿に送り、その回答をセッションのレポートに保存します。ここから2つのことが導かれます。
- 身分証ステップが誤った番号や名前を抽出した場合、登録簿は誤った値で照会され、検証は失敗するか判定不能で返ってきます。まず抽出結果を修正してください。誤って読み取られた名前や項目を修正するを参照してください。
- 身分証やセルフィーのようにデータベース検証をユーザーに「再提出」させることはできません。本人がやり直せるものが何もないからです。
DATABASE_VALIDATIONの再提出を要求すると、その機能はこのセッションで再提出可能なステップに含まれないというエラーが返ります。もう一度実行するには、修正済みのデータでスタンドアロンのデータベース検証APIを呼び出してください。この呼び出しは他と同様にクエリごとに課金されます。
#実行されない理由
この順番で確認してください。「データベース検証が何もしなかった」という報告のほぼすべてを説明できます。
- 組織は一度でもチャージしましたか？
データベース検証（および電話番号検証）は初回チャージの後にはじめて有効になります。新規アカウントの10ドルを含むウェルカムクレジットはカウントされません。それまでステップはスキップされ、検証が静かに実行されないまま承認で返ってくることもあり、
POST /v3/database-validation/を直接呼ぶと403が返ります。チャージ、請求書、支払い方法を参照してください。 - サービスに「オンボーディングが必要です」と表示されていますか？
ワークフローのデータベース検証ステップで、一部のサービスに**「オンボーディングが必要です。有効化するには Didit サポートにお問い合わせください。」**と表示されます。サービスは表示されていますが、Diditが有効化するまで組織では無効です。これはバグではなく、セルフサービスのスイッチもありません。サービスと国を明記してサポートチケットを開いてください。チームがオンボーディングを開始します。
- そもそもその国は設定されていますか？
ワークフローで選択していない国へのAPI呼び出しや、有効化していないサービスへのスタンドアロン呼び出しは、その国について「No database validation services configured」と応答します。ステップにサービスを追加するか、国のページにある正確な
service_idを渡してください。 - 残高はプラスですか？
データベース検証は無料枠に含まれません。残高がゼロまたはマイナスの場合、他の有料機能と同様に
insufficient_creditsが返ります。「クレジット不足」エラーの解決を参照してください。
#プロバイダーとのオンボーディングが必要なサービス
一部の政府系情報源では、スイッチを切り替えるだけでなく、Diditがあなたの組織をプロバイダーに登録する必要があります。現在これに該当するのは次の通りです。
- オーストラリア（DVS：運転免許証、パスポート、ビザ、Medicare、その他のDVSサービス）
- ニュージーランド（DIA：パスポート、市民権、出生・死亡記録、運転免許証）
- カナダ（信用情報機関およびFINTRAC型の照合サービス）
これらの場合、サポートがプロバイダーの書式を送り、プロバイダーがアカウント用の認証情報を発行し、有効化には通常最大2週間かかります。オーストラリアとニュージーランドでは従来、最低限のサービス契約（一回限りの前払い金、現在5,000米ドルで、失効しないクレジットとして残高に入ります）も必要でした。この要件はこの2カ国の登録簿アクセスのみに適用され、Diditの他の機能には関係ありません。Diditがオーストラリアの制度で自社の認定を完了するのに伴い見直し中ですので、これを前提に計画を立てる前に現在の条件をサポートにご確認ください。
一部のサービスでは、クエリ送信前にエンドユーザーの明示的な同意も必要です （例：ニュージーランドDIAのパスポート照会）。ワークフローのステップにそれらのサービスが 表示され、検証を実行する前にあなたのフロー内で同意を取得する必要があります。
#課金対象
サービスごと、登録簿が応答したクエリごとに、そのサービスのページに記載された料金を支払います。「登録簿に問い合わせ、回答があった」と読んでください。「期待した回答だった」ではありません。
| 結果 | 課金? |
|---|---|
| 一致、部分一致、不一致 | はい |
| 判定不能、生体画像が使用不可 | はい |
| 書類形式が無効、入力が無効（登録簿が拒否） | はい |
REGISTRY_UNAVAILABLE、REGISTRY_ERROR（登録簿が応答しなかった） | いいえ |
| 登録簿に届く前に拒否されたリクエスト（スタンドアロンAPIの400、または項目の欠落・不正によりワークフローのステップがスキップ） | いいえ |
複数のサービスを実行すれば1つのセッションで複数の課金クエリが発生することがあり、クエリは国ごとではなくサービスごとに1回課金されます。詳細はデータベース検証の料金と結果コードを参照してください。
空の結果は不一致ではありません。サービスがNO_MATCHの結果ではなく何も返さない場合、
よくある原因は初回チャージの規則、オンボーディング待ちのサービス、登録簿の障害です。
連携をデバッグする前にこれらを除外してください。APIエラーとその意味を参照してください。
#返ってくるもの
各サービスは標準の結果コードに加え、情報源が許す範囲で登録簿自身のデータを返します。どの項目が一致したか、登録簿が可否ではなくスコアで回答する場合の一致スコア、生体系サービス（アルゼンチンRENAPER、ナイジェリアBVN、パナマ）では登録簿の顔写真との照合結果です。その回答からDiditが何を保存するかは、ステップの返されたデータ設定で決まります。検証が返すデータを選ぶとデータベース検証レポートを参照してください。
#本番前のテスト
サンドボックスのアプリケーションは実際の登録簿に到達せず、クレジットも消費しません。decline_database_no_matchのようなサンドボックスシナリオで、リハーサルしたい結果を強制できます。サンドボックスで分からないのは、特定のサービスが本番組織で提供済みかどうかです。それには初回チャージと実際の呼び出しが必要です。サンドボックスでのテストを参照してください。