Skip to main content
The ID Verification step in a workflow has a Countries tab. That is where you decide, country by country, which of the three methods a person may use and what happens when a non-document method does not land. Everything on the tab writes the methods key on the ID Verification node — the console and the Management API are two views of the same object.

​
Countries and allowed ID methods

Open a workflow, select the ID Verification node, then Countries. Each country row shows the methods it accepts. Pick a country to open its editor. A country where you turn every method off is rejected on save with No method enabled — nobody can verify here, because that configuration cannot verify anybody.

​
Availability is server-driven

The tab reads the same capability catalog the API validates against, so it can only ever offer you what the platform actually supports:
  • A method the catalog does not offer in that country is not shown as a choice.
  • A source or wallet the catalog marks Coming soon is listed so you can see the roadmap, but it cannot be switched on.
  • Wallet sign-in is switched on per environment. While it is off, every wallet reads Coming soon whatever the catalog says.

​
Enable Smart-ID or Mobile-ID

Smart-ID and Mobile-ID are available in their supported countries. See the wallet catalog for country coverage. Use the availability shown in your current environment before changing a workflow.
  1. Open Workflows, select the workflow and its ID Verification node, then open Countries.
  2. Open the country editor and find Wallets accepted.
  3. Select Smart-ID or Mobile-ID only if it is available; leave document capture enabled if you want a fallback.
  4. Choose what should happen when a wallet sign-in fails, then save and publish the workflow.
  5. Start a new verification session using that workflow and inspect the completed session’s Credential card.
The Smart-ID and Mobile-ID integration guide lists the supported country codes and the comparison-code flow the user sees. A successful staging or sandbox test does not enable the wallet in production.

​
Expected request and response

See details on a lookup source or a wallet opens the expected request and response: what the end user is asked for, in plain language, and what the source returns. Each lookup source is named exactly — a government register in most countries, a credit-bureau or residential-records file in some — because that is what determines provenance and the consent regime. The end user never sees the response fields, the source name or the price.

​
Bulk switches

Global settings turns a method on in every country that supports it, so you do not have to walk 36 countries by hand. The per-country editor still wins: switch a method on globally, then turn it off for the one country where you do not want it.

​
Prices on the tab

Document capture shows its price: $0.15, with the first 500 checks each month free. A non-doc lookup shows its price per country, and any price the pricing catalog has not published yet is labelled a placeholder on the tab rather than presented as a quote. A wallet row shows the wallet, its coverage and its availability. The tab also spells out the billing consequence of each lookup fallback switch, so the cost of a configuration is visible before you save it:
  • A registry that answered bills the lookup — a match and a no match both count — and the document capture then bills on top when the user falls back.
  • A lookup that never returned is not billed, so an outage costs you the document price only.
  • Turn a fallback off and those users are declined; nothing further is billed.

​
Reading a session

The ID Verification block on a session detail carries a chip for the method that produced it and a second chip for its assurance tier: Document / Documentary, Non-doc lookup / Data match, or the wallet’s name with Cryptographic.
A session that fell back from a non-document method to document capture reads as a Document / Documentary session. The API does not yet record the method that was tried first on a successful fallback — fallback_from is populated only when the country’s switch was decline and the session was declined — so the console has nothing to draw a “tried this, then that” trail from. To see which non-document method was attempted, use the checks list on the session.
Below the chips, each method shows its own evidence:
  • Document — unchanged: the front, back and selfie images, quality scores, extracted fields and warnings.
  • Non-doc lookup — a Registry comparison listing every compared field with what the user provided, what the source held, and a Match, Partial or No match result, plus the source name, the time it was checked and the attempt count. A source that did not answer appears as its own row with an error rather than a field verdict. Where the source returned a portrait, that portrait and the user’s selfie are shown side by side with the face score.
  • Wallet — the Credential card: the wallet, its issuing authority, the credential type, the level of assurance it asserted, when it was verified, whether the signature checked out, and the attributes the wallet shared.
Where a source or a wallet shares no portrait, the panel says so instead of leaving an empty frame: there is nothing to face-match, and Liveness and Face Match run as their own steps if the workflow has them.