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 — a national eID or a bank identity. The wallet authenticates them, then shares a signed set of attributes with Didit. Nothing is photographed and nothing is typed. Same-device sign-in hands the user to the wallet app and back; cross-device sign-in shows a QR code they scan with their phone. Per-wallet attributes, assurance levels 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.
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. If a switch says fallback_to_document but document capture is disabled for that country, the session is declined instead: there is nowhere to fall back to. A decline records fallback_from on the declined ID Verification, naming the method that failed and why.

​
What each method costs

The 500 free checks a month are scoped to document capture. Non-document methods are priced per country and per wallet and are not part of that allowance; see Pricing for the current published figures.

​
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.
  • An abandoned, cancelled, timed-out or failed wallet sign-in is not billed. Only a completed sign-in is.

​
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.