> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Smart-ID and Mobile-ID integration

> Configure Smart-ID and Mobile-ID identity verification with Didit, including country coverage, comparison-code authentication, verified attributes and fallback.

Smart-ID and Mobile-ID let users verify their identity by approving a request on their phone.
Both integrations run inside Didit's existing **ID Verification** workflow step and return a wallet verification result with `cryptographic` assurance.
You use the same session creation, hosted verification and webhook integration as your other Didit workflows.

<Note>
  **Integrated and tested in staging; production activation pending.**
  A successful test does not make either wallet available in production.
  Check the availability shown in your environment's console before enabling a wallet.
  The [wallet catalog](/core-technology/id-verification/digital-id-wallets#supported-wallets) reports production availability separately from integration progress.
</Note>

## Countries and prerequisites

The integration covers Smart-ID in Estonia (`EST`), Latvia (`LVA`), Lithuania (`LTU`) and Belgium (`BEL`).
Mobile-ID covers Estonia (`EST`) and Lithuania (`LTU`); Mobile-ID is not offered for Latvia.
These country codes describe the integrated routes, not a promise that every route is activated in your environment.

For Smart-ID, the user needs an active eligible Smart-ID identity, its personal identification code and access to the app.
For Mobile-ID, the user needs an active Mobile-ID identity, its personal identification code and its associated phone number.
Enter the Mobile-ID phone number in international format: `+372` for Estonia or `+370` for Lithuania.
The selected country must match the identity being used.

Neither method returns a portrait.
If your workflow requires a selfie, keep the appropriate [Liveness](/core-technology/liveness/overview) and [Face Match](/core-technology/face-match/overview) steps configured separately.

## What the user sees

1. The user selects their country and chooses **Smart-ID** or **Mobile-ID** from the wallets your workflow accepts.
2. The verification session asks for the personal identification code; Mobile-ID also asks for the associated phone number.
3. The page displays a comparison code while the authentication request reaches the phone.
4. The user checks that the code on the phone matches the code on the verification page, then approves using their PIN on the phone.
5. Didit validates the signed identity result and continues the verification workflow.

The identity form and comparison-code screen use the same layout as the other verification methods.
When white-label customization is enabled, they inherit the session's colors, typography, button styling and customer logo, and remain on the session's domain.
Refreshing the page restores the active comparison code without starting another approval request.

The user never enters their wallet PIN on the verification page.
If the codes differ or the user did not initiate the request, they should cancel it.
The comparison-code flow works with a desktop or phone browser and does not require a QR code.
The page waits for the result automatically and provides a cancellation option.
An approval on the phone must still pass identity and signature checks before Didit treats the wallet verification as successful.

## Configure the workflow

In the console, open your workflow's **ID Verification** node, choose **Countries**, and open the country you want to configure.
Under **Wallets accepted**, select the available wallets and choose the failure behavior.
Save and publish the workflow before creating a new session.
See [ID Verification methods in the console](/console/id-verification-methods#enable-smart-id-or-mobile-id) for the full console path.

<Warning>
  The following is a `methods` configuration fragment, not a complete workflow request.
  Use it only when **both** `smart_id` and `mobile_id` are marked `available` for Estonia in your environment.
  An unavailable wallet rejects the whole workflow save.
</Warning>

```json theme={null}
{
  "EST": {
    "document": { "enabled": true },
    "wallet": {
      "enabled": true,
      "providers": ["smart_id", "mobile_id"],
      "on_failure": "fallback_to_document"
    }
  }
}
```

The `providers` array is an accept-list: users choose between its wallets, and array order does not set a preferred wallet.
For Lithuania, use `LTU` with the same wallet identifiers when both are available.
For Latvia or Belgium, use `LVA` or `BEL` with `smart_id` only, subject to the same availability check.
Omitted countries retain their existing default document-capture behavior.
The full configuration contract is in [Workflow feature configs](/management-api/workflows/feature-configs#ocr-/-id-verification).

## Read the verified result

Read the completed session through the [session decision API](/sessions-api/retrieve-session) or your [webhook integration](/integration/webhooks).
A successful wallet check records `verification_method: "wallet"`, `assurance: "cryptographic"` and `wallet_provider: "smart_id"` or `"mobile_id"`.
The `wallet_verification` object identifies the wallet, issuing country, verification time, level of assurance and signature verdict.
The ID verification result exposes the normalized `full_name` and `date_of_birth` fields.
For these two wallets, `wallet_verification.attributes` carries `given_name`, `family_name`, `birthdate` and `personal_code` from the validated identity.
The issuing country identifies the identity route; it does not establish the person's nationality.
Didit returns the signature verdict, not the underlying signed assertion.
No portrait or wallet PIN is returned.

In the console, the session's **Credential** card shows the wallet and its verified evidence.
A successful wallet check completes the ID Verification step; later checks in your workflow still determine the session's final decision.
See the [ID verification data model](/reference/data-models#id-verification) for field types and the distinction between a check result and the overall session decision.

## Handle cancellation and failure

If a user cancels, times out or cannot complete authentication, Didit applies the country's `wallet.on_failure` setting.
`fallback_to_document` starts document capture when it is enabled for that country.
`decline` declines the ID Verification step.
If document capture is disabled, there is no document fallback available.

Only a completed, verified wallet check incurs the wallet verification charge.
Cancelled, expired and failed wallet attempts do not.
A completed document fallback is a separate check under [document verification pricing](/getting-started/pricing).
Consult the [wallet pricing table](/core-technology/id-verification/digital-id-wallets#pricing) for published rates; a method without a published rate should not be treated as free.

## Test before production

Test each wallet and country you plan to offer in the environment where it is enabled.
Confirm that the correct wallets appear, the comparison code is visible, approval continues the workflow, and the session result contains the expected wallet evidence.
Also check cancellation, expiry and your chosen fallback behavior.

Sandbox simulations and staging tests are different from production authentication.
A simulated approval is useful for checking your integration but does not prove that a real identity can authenticate in production.
Before rollout, confirm production availability in the console and complete an authorized real-device verification for the route you intend to use.

## Other digital identity wallets

Didit's [digital ID wallet catalog](/core-technology/id-verification/digital-id-wallets) includes production availability and upcoming wallets, including the Finnish Trust Network, BankID and the EUDI Wallet.
A listed wallet, published price or completed onboarding form does not itself enable production authentication.
Use the catalog and your environment's console to determine what you can activate today.

See also [Finnish Trust Network for Finland](/core-technology/id-verification/finnish-trust-network).