Database validation - activating services and what you pay for

Database validation checks the extracted identity data against a government or authoritative registry. Here's why a service says "Requires onboarding", why it returns 403 or nothing at all, and which queries are billed.

Written by Didit Support · Updated 15 September 2026

Reading the document tells you what is printed on it. Database validation tells you whether an authoritative source agrees: a civil registry, a tax authority, a credit bureau, a driver-licence database. Each country exposes one or more services, each with its own price, inputs and consent rules. See supported countries and services and per-service pricing.

#It runs silently, after the document step

There is no database validation screen. The step takes the data extracted from the ID (or the data you passed when creating the session), sends it to the registry, and stores the answer in the session's report. Two consequences follow from that:

• If the ID step extracted the wrong number or name, the registry is queried with the wrong value and the check fails or comes back inconclusive. Fix the extraction first. See fixing a name or field that was read wrong.
• You cannot "resubmit" a database validation to the user the way you resubmit an ID or a selfie, because there is nothing for them to redo. Asking for a resubmission of DATABASE_VALIDATION returns an error saying the feature is not part of the session's resubmittable steps. To run it again, call the standalone database validation API with the corrected data. That call is billed per query like any other.

#Why it isn't running

Work through these in order. They account for nearly every "database validation did nothing" report.

1. Has your organization ever topped up?

   Database validation (and phone verification) only activates after a first top-up. Welcome credits, including the $10 new-account credit, don't count. Until then the step is skipped, a session can come back approved with the check silently not performed, and a direct call to POST /v3/database-validation/ answers 403. See top-ups, invoices and payment methods.

2. Is the service marked Requires onboarding?

   In the workflow's Database Validation step, some services show "Requires onboarding. Contact Didit support to enable it." The service is visible but disabled for your organization until Didit activates it. This is not a bug and there is no self-serve switch: open a support ticket naming the service and the country, and the team starts the onboarding.

3. Is the country configured at all?

   An API call for a country you never selected in the workflow, or a standalone call for a service you haven't enabled, answers with "No database validation services configured" for that country. Add the service to the step, or pass the exact service_id from the country's page.

4. Is the balance positive?

   Database validation is never in the free tier. A zero or negative balance returns insufficient_credits, the same way any paid feature does. See fixing a "not enough credits" error.

#Services that need a provider onboarding

A handful of government sources require Didit to onboard your organization with the provider, not just flip a switch. Today that applies to:

• Australia (DVS: driver licence, passport, visa, Medicare and the other DVS services)
• New Zealand (DIA: passport, citizenship, birth and death records, driver licence)
• Canada (credit-bureau and FINTRAC-style matching services)

For these, support sends you the provider's forms to complete, the provider issues credentials for your account, and enablement typically takes up to two weeks. Australia and New Zealand have historically also required a minimum service agreement (a one-time prepaid amount, currently $5,000 USD, that lands in your balance as credits that never expire). That requirement applies to those two countries' registry access only, not to any other Didit feature, and it is being revised as Didit completes its own accreditation with the Australian scheme, so ask support for the current terms before planning around it.

#What is billed

You pay per service, per query the registry answers, at the price on that service's page. Read it as "the registry was asked and replied", not "the answer was the one you wanted":

One session can trigger several charged queries if it runs several services, and a query is charged once per service, not per country. Full breakdown: database validation pricing and outcome codes.

#What comes back

Each service returns a standard outcome code plus the registry's own data where the source allows it: which fields matched, a match score where the registry scores rather than answers yes or no, and for biometric services (Argentina RENAPER, Nigeria BVN, Panama) a face comparison against the registry's portrait. What Didit stores from that answer is governed by the step's Returned data settings. See choosing which data a verification returns and the database validation report.

#Testing before you go live

Sandbox applications never reach a real registry and never spend credits: a sandbox scenario such as decline_database_no_match forces the outcome you want to rehearse. What sandbox cannot tell you is whether a specific service is provisioned for your live organization - that needs the first top-up and a live call. See testing in sandbox.