Skip to main content
ID Verification is one feature with three methods. You choose which methods a country may use; the end user gets whichever of them apply to the country they pick, and the session records which method actually produced the result. Document capture is unchanged. Everything you already configure through documents_allowed — accepted types, subtypes, capture rules, thresholds, warnings — keeps working exactly as before, and a workflow that says nothing about methods stays document capture only.

​
How each method works

​
Document capture

What the rest of this section documents: the user photographs the document, Didit reads it, checks it for authenticity and returns the extracted fields. Available in every country Didit supports, at $0.15 per check with the first 500 checks each month free. Start at the ID Verification overview.

​
Non-doc lookup

The user types their national ID number and a few personal details, and Didit checks them against the authoritative source for that country. No photograph of a document is involved. That source is a government register in most countries, but not in all of them: in Canada, France, Indonesia, the Netherlands, Norway, Singapore, the United Kingdom and the United States it is a credit-bureau, financial-services, utility or residential-records file instead. Because provenance and the applicable consent regime differ with it, the exact source is named per country in the table below and on Non-document lookup — never generalised. Where the source returns a portrait — South Africa, Nigeria, Argentina and Panama today, all four government registers — the user is also asked for a selfie. Passive liveness runs on that selfie and it is face-matched to the registry portrait, all inside the lookup and all inside the lookup price. Where the source returns data only there is nothing to face-match against, so no selfie is taken; run Liveness and Face Match as their own workflow steps if you need them. Full per-country request fields, format rules and consent regimes are on Non-document lookup.

​
Wallet

The user signs in with a digital identity they already hold, such as a national eID or bank identity. The wallet authenticates them, then shares signed identity attributes with Didit. Depending on the wallet, the user may enter a personal identification code or phone number; no document photograph is needed for the wallet check. The sign-in experience depends on the wallet: an app handoff, a QR code, or a comparison code confirmed on the user’s phone. Smart-ID and Mobile-ID use a comparison code. Per-wallet attributes, production availability and failure semantics are on Digital ID wallets.

​
Assurance tiers

Every ID Verification result carries an assurance tier derived from the method that produced it. The tier is an honest description of what was actually proven, not a ranking:
Assurance tiers are an admin-facing label. They appear on the session payload, in the console and in exports. End users never see the tier, the price or the name of the source that was queried.

​
Configuring methods per country

Methods live under the methods key on the ID Verification (OCR) feature config, keyed by ISO 3166-1 alpha-3 country code. Omit the key, omit a country, or omit a method inside a country, and that country is document capture only.
Both countries above are available for lookup in the published catalog. The example leaves wallets disabled so it does not depend on a wallet being enabled in your environment. A workflow that enables a wallet marked Coming soon is rejected, including the other configuration in that save. Once the catalog marks a wallet available in a country, the wallet block for that country looks like this:
Check the catalog before you send it. Prerequisite: the wallet reads Available for that country, listed on Digital ID wallets. Two rules the API enforces on save:
  • Availability is server-driven. A method or a wallet that the capability catalog does not mark available for that country is rejected. Read the catalog first — through the console’s Countries tab, or with the didit_workflow_get_id_verification_methods_catalog MCP tool.
  • Wallets are an accept-list, never a ranking. providers says which wallets a country may offer. The order you send has no meaning and is normalised away; the end user picks.
The full field-by-field reference, including defaults and validation, is in Workflow feature configs.

​
Fallback: what happens when a non-document method does not land

Four switches decide what happens next. Each one is either fallback_to_document (send the user to document capture) or decline (end the session with a declined ID Verification). All four default to fallback_to_document. id_lookup.max_attempts (1 to 5, default 1) is how many answered lookups the user gets before the switch fires. A number that fails the client-side format check never reaches the register, so it does not consume an attempt — the user is simply asked to correct it. A wallet or lookup can only fall back to document capture when document capture is enabled for that country. With document capture off, a failed sign-in or a lookup that does not match declines the session, even if the switch says fallback_to_document. There is nowhere to fall back to. A decline records fallback_from on the declined ID Verification, naming the method that failed and why. The current staging implementation also carries that evidence onto the document verification created after a fallback. Confirm production rollout before depending on that additional evidence.

​
Offer document capture only as the fallback

By default, a country that offers a wallet or an ID lookup together with document capture shows them side by side on the first screen. Set document.fallback_only to true to keep document capture enabled for the country without offering it up front. Users start with the country’s wallet or ID lookup. With a single wallet, the user lands straight on that wallet. Only users whose wallet sign-in fails, is cancelled or times out, or whose lookup does not match, are taken to document capture. Which of those outcomes lead to document capture is still decided by the switches above, so at least one of them must be fallback_to_document.
fallback_only is optional and defaults to false. It is rejected unless document.enabled is true and at least one wallet or ID lookup in that country falls back to document capture. Enable the document types the fallback should offer in documents_allowed, for example passport and ID card for Finland.

​
What each method costs

The 500 free ID Verification checks a month are scoped to document capture. Non-document lookups are not part of that allowance. A lookup uses the public Database Validation retail rates for the services it runs; several services can contribute to one attempt. Nigeria selects either NIN or BVN. The country table shows the full configured attempt price, with each answered retry billed separately.

​
Billing rules

  • A register that answered bills the lookup. Match, partial match and no match all count — the query was run and the answer is the product.
  • A register that never answered is not billed. A provider error costs nothing.
  • A number that fails the client-side format check is never billed and never counted against max_attempts, because it never reached the register.
  • Document capture bills on top when the user falls back. A lookup that answered and then fell back to a document is two charges, because two checks ran.

​
Coverage

Document capture is available in every country Didit supports and is not repeated below: $0.15 per check, first 500 a month free. This table lists only the countries where a non-document method exists. A country that is not listed, or a cell that reads Not planned, is document capture only.
Coverage is generated from the capability catalog the backend serves, so this table is the same source the console and the API validate against. Coming soon means the entry is visible in the console and cannot be switched on yet; it is not a live capability and carries no committed date.

​
What lands on the session

Every ID Verification result carries the method that produced it, its assurance tier, and — when a non-document method ran — a per-method evidence block. Document sessions read exactly as they did before, with the new keys null. Field-by-field types and examples for all three methods are in the ID verification data model, and the same keys arrive on the status.updated webhook.