Skip to main content
Wallet sign-in is one of the three ID Verification methods. The user signs in with a digital identity they already hold — a national eID or a bank identity — and that provider shares a signed set of attributes with Didit. The result carries the assurance tier cryptographic: an identity provider authenticated the person and signed the attributes it returned. That is all the tier claims. It is not a ranking against the other two tiers — they describe different evidence, not more or less of the same thing — and how long a sign-in takes is the wallet’s own flow, which Didit neither controls nor promises.
Availability is specific to your environment. The tables below describe production availability, and the console uses its environment’s live capability catalog when you save a workflow. MitID, BankID Sweden, iDIN, Finnish Trust Network, Smart-ID and Mobile-ID are available. Estonian ID-card, eParaksts mobile, Personalausweis, OneID and ConnectID remain Coming soon in production. Smart-ID supports Estonia, Latvia, Lithuania and Belgium; Mobile-ID supports Estonia and Lithuania; Finnish Trust Network supports Finland. See the Smart-ID and Mobile-ID integration guide for country coverage, configuration and the verification flow. A wallet marked Coming soon cannot be enabled in that environment.

Choose your integration

Use Digital ID wallet APIs when your application manages the interface and authentication steps. Each wallet has a dedicated start endpoint, with shared result, polling and cancellation endpoints. You do not need to create a workflow. Use the Sessions API for Didit’s hosted wallet journey, workflow rules and configured document fallback. The wallet’s availability, required user approval and verified identity attributes apply to both integration methods.

Prerequisites

Each wallet requires an active identity with the issuer named below and access to its authentication method. The account must be eligible for the requested attributes, and the user must consent to sharing them. A signature verifies the issuer and returned claims; it does not guarantee that every requested attribute is present, current or sufficient for your compliance policy. A wallet without a portrait does not include a selfie comparison. All 25 catalog wallet entries are listed below, including both BankID countries, ConnectID, Estonian ID-card and eParaksts mobile. A configured document fallback runs a separate document check. No launch date is promised. These are identity wallets. Crypto wallet screening checks blockchain addresses for financial risk and is a separate product.

Pricing

✅ Available means enabled in production. ⏳ Coming soon means not yet enabled in production, even if integration testing has started. Available wallets appear first. On request in the price column means the wallet is available but has no published retail rate; it does not mean free verification. These are Didit’s standard prices in USD per completed wallet verification for the identity products listed below. The listed price includes the wallet identity check; no separate national eID transaction fee is added to it. An agreed organization-specific rate takes precedence. Coming soon in the price column means the wallet is planned and its customer price has not been published yet. It does not mean the verification is free. Country flags show the wallet’s catalog coverage; the separate availability column shows whether it can currently be enabled. A published price does not enable a wallet. Availability above comes from the production catalog. A wallet marked Coming soon cannot be selected in a workflow yet; these rates apply when it becomes available.
  • A verified wallet sign-in is charged once per ID Verification node in a workflow, or once per verification request through the standalone wallet API. Repeated callbacks or status checks do not create another charge.
  • Cancelled, expired, refused or incomplete sign-ins do not create a wallet verification charge.
  • The 500 monthly free document checks do not apply to wallet verification.
  • A document fallback is a separate check, billed under document verification pricing. Other completed workflow features are billed separately.
For example, 1,000 completed iDIN full-identification verifications at the standard rate cost $850, before other workflow features. This is full identification; it is not a repeat-login price. The BankID rate above is for Norway High, and the German eID rate is for Personalausweis Profile 2.

What the user does

  1. Picks their country in the ID step and chooses a wallet from the ones you accept.
  2. Signs in with that wallet, the way they sign in to their bank or their government portal.
  3. Approves sharing their identity attributes with you.
  4. Comes back verified.
Same-device sign-in hands the user to the wallet app and returns them to the verification flow when they are done. Cross-device sign-in shows a QR code on the desktop screen that they scan with the phone holding the wallet. Both are offered where the wallet supports them; the user picks. When Smart-ID or Mobile-ID is enabled for your workflow, the user enters their personal identification code on the verification page. Mobile-ID also asks for the phone number associated with the identity. The page displays a comparison code, and the user approves on their phone only when that code matches. The user enters their PIN on their phone; Didit never asks for it. This flow works from a desktop or phone without a QR code. Availability is determined by the live capability catalog; a wallet marked Coming soon cannot be enabled yet. A started sign-in stays valid for a limited window (10 minutes by default). After that the user has to start it again.

Wallets are an accept-list

wallet.providers is the list of wallets a country may offer. It is not a ranking: the order you send carries no meaning, is normalised into catalog order on save, and the end user chooses from whatever you accepted. Enable one wallet or every wallet in a country — the choice is theirs. The API rejects a workflow that enables a wallet the catalog does not offer in that country, or one that is still Coming soon.
Every wallet’s attribute list below includes a signed assertion. Didit verifies that signature and reports the verdict as wallet_verification.signature_valid on the session; the assertion itself is not handed back, so there is no reference to fetch or store. The On the session column says which of the two you get for each attribute.

Supported wallets

The available wallets are MitID, BankID Sweden, iDIN, Finnish Trust Network, Smart-ID and Mobile-ID. iDIN is available for full identification in the Netherlands. Smart-ID and Mobile-ID are available in the countries listed in the catalog below. Country coverage and requested inputs for Smart-ID and Mobile-ID reflect the implemented integration; production availability remains controlled separately. Use the integration guide for the implemented Smart-ID and Mobile-ID routes.
Availability is served by the capability catalog, not hand-maintained here. Coming soon means the wallet is visible in the console and cannot be switched on yet; it carries no committed date.

Estonian ID-card and eParaksts mobile

Both methods are integrated into the wallet catalog but remain Coming soon in production. They cannot be enabled in production workflows until the production catalog marks them Available. The API identifiers are idcard_ee for Estonia (EST) and eparaksts_mobile for Latvia (LVA). Both are priced at $0.55 per completed verification when available; a published rate does not enable production access.
  • Estonian ID-card: the user continues in the browser on the computer connected to their smart-card reader and authenticates with their card and PIN through the card software.
  • eParaksts mobile: the user continues to the identity sign-in service and approves with their active eParaksts mobile account. Desktop users can scan the QR code to continue on their phone; phone users continue directly.
Both use the shared Didit wallet selection, handoff and return flow. The user enters their authentication PIN only in the identity service or card software, never into a Didit form. After authentication, Didit verifies the signed identity attributes and continues the configured workflow. Cancellation or failure follows the workflow’s configured document fallback or decline action.
White label applies to the Didit verification screens. The external authentication screens for these two methods retain their service branding. Custom logos, service names and white-label styling do not carry over to those external screens.

Use these wallets through the API

Both methods also support standalone API verification without a workflow_id. Production availability is the same for the standalone API and workflows; check GET /v3/id-verification/wallets/ before offering either method to users. Keep your x-api-key on your backend and register your application’s return host in its allowed_return_hosts setting. Send an HTTPS return_url on that host when starting a verification. The start response returns a request_id and a wallet_verification.next_action.url for the user’s browser. Redirect the user to that URL so they can authenticate with their card or app. After they return, retrieve GET /v3/id-verification/wallets/verifications/{request_id}/ from your backend to check the verified result, or process the signed status.updated webhook. Do not treat the browser redirect alone as proof of successful verification. The same price and completed-verification billing rules apply to both integration options.

Other upcoming wallets

ConnectID (Australia) is integrated for sandbox testing and appears in the wallet catalog as connectid. The person selects a participating test bank using the ConnectID selector, signs in with that bank and reviews the sharing request. The initial identity bundle requests given name, family name and date of birth, with a transaction reference for the verification. It does not request an address, phone number, email address, account balance or transaction history. The sharing notice identifies Didit and the business receiving the verified identity. Bank credentials remain with the bank. Production access remains Coming soon; sandbox testing does not enable live identity verification. An approved production use case, customer onboarding, required terms and certification must be completed before activation. Other wallets marked Coming soon in the tables also remain unavailable in production. No launch date is promised.

Level of assurance

Where a wallet provides an eIDAS level of assurance (low, substantial or high), Didit records the level actually asserted on the result. A wallet without a specified eIDAS level, such as ConnectID, is shown as Not specified; its integration does not imply an eIDAS assurance claim. If a wallet returns a weaker level than the one requested, the sign-in fails rather than quietly downgrading. Check wallet_verification.level_of_assurance on the session when your compliance rules depend on it.

Per-wallet reference

MitID

mitid · Available Information entered in Didit: Name · Date of birth · CPR alias (pseudonymised)

BankID

bankid_se · Available Information entered in Didit: Name · Personal number

iDIN

idin · Available Information entered in Didit: Name · Date of birth · Address

Finnish Trust Network

ftn · Available Information entered in Didit: Name · Personal identity code

Smart-ID

smart_id · Available Information entered in Didit: Personal identification code

Mobile-ID

mobile_id · Available Information entered in Didit: Personal identification code · Mobile-ID phone number

BankID

bankid_no · Coming soon Information entered in Didit: Name · Date of birth · National identity number

Vipps

vipps · Coming soon Information entered in Didit: Name · Date of birth · National identity number

Buypass ID

buypass · Coming soon Information entered in Didit: Name · Date of birth · National identity number

itsme

itsme · Coming soon Information entered in Didit: Name · Date of birth · National register number

Personalausweis

personalausweis · Coming soon Information entered in Didit: Name · Date of birth · Nationality · Address

Freja eID

frejaid · Coming soon Information entered in Didit: Name · Date of birth · Personal number

UAE PASS

uae_pass · Coming soon Information entered in Didit: Name · Emirates ID number · Nationality · Portrait

gov.br

govbr · Coming soon Information entered in Didit: Name · CPF

OneID

oneid · Coming soon Information entered in Didit: Name · Date of birth

GOV.UK Wallet

govuk_wallet · Coming soon Information entered in Didit: Name · Date of birth · Portrait

Estonian ID-card

idcard_ee · Coming soon Information entered in Didit: Name · Date of birth · Personal identification code

eParaksts mobile

eparaksts_mobile · Coming soon Information entered in Didit: Name · Date of birth · Personal identification code

Bank iD

bankid_cz · Coming soon Information entered in Didit: Name · Date of birth

MojeID

mojeid · Coming soon Information entered in Didit: Name · Date of birth

Diia

diia · Coming soon Information entered in Didit: Name · Date of birth · Portrait

FranceConnect

franceconnect · Coming soon Information entered in Didit: Name · Date of birth

Auðkenni

audkenni · Coming soon Information entered in Didit: Name · Kennitala

ConnectID

connectid · Coming soon Information entered in Didit: No identity details entered in Didit

EUDI Wallet

eudi · Coming soon Information entered in Didit: PID - person identification data

Failure and fallback

Anything other than verified follows the country’s wallet.on_failure switch: fallback_to_document sends the user to document capture, decline ends the session with a declined ID Verification. fallback_to_document with document capture disabled for that country declines instead, because there is nowhere to fall back to. To show document capture only after a failed wallet sign-in, see Offer document capture only as the fallback. Only a completed sign-in is billed. Abandoned, cancelled, timed-out and failed sign-ins cost nothing.

What lands on the session

attributes holds the validated wallet claims, whose names vary by wallet. Use full_name and date_of_birth on the ID verification result for the normalized identity fields. The per-wallet table distinguishes those normalized fields from wallet-specific attributes. portrait is present only for the wallets that share one. signature_valid is the result of validating the signed assertion the wallet returned. It is true on a completed sign-in: an assertion that does not validate fails the sign-in and follows wallet.on_failure instead of producing an approved result. Full field types are in the ID verification data model.

Configuring wallets

This is a configuration fragment to use only when your environment’s catalog marks every selected wallet available in the selected country. Sending a wallet that is unavailable rejects the whole workflow save, including any other methods in the same request. For Smart-ID and Mobile-ID examples, see the integration guide.
Enable at least one wallet when wallet.enabled is true, or the save is rejected. The full reference is in Workflow feature configs.