Vérifie les personnes avec une identité électronique (eID) qu'elles utilisent déjà. Accepte Smart-ID, Mobile-ID, Finnish Trust Network et MitID via un seul workflow, avec fallback documentaire si nécessaire.
Approuvé par plus de 2 000 organisations dans le monde entier.
En ligne
En ligne
BientôtBientôtBientôt
BientôtBientôt
En ligne
BientôtBientôt
Bientôt
Bientôt
BientôtBientôt
En ligneEn ligne
BientôtBientôt
Bientôt
Bientôt
Bientôt
Bientôt
+26BientôtLes statuts distinguent la disponibilité en production des tests d'intégration. La couverture par pays décrit la route de portefeuille configurée, et non une vérification d'identité en direct complétée dans chaque pays. Aucune date de lancement n'est promise.
Statut d'intégration
Smart-ID, Mobile-ID, Finnish Trust Network et MitID sont disponibles. Choisis les portefeuilles acceptés par pays et permets aux utilisateurs de s'authentifier avec une identité éligible qu'ils possèdent déjà. Les autres intégrations listées sont « bientôt disponibles ».
Dans la console, sélectionne les portefeuilles disponibles pour chaque pays dans ton environnement. Choisis si une connexion annulée ou échouée revient à la capture de documents ou est refusée.
Directement depuis le catalogue de méthodes
Au catalogue
Pays couverts
eIDAS élevé
En ligneEn ligneBientôtBientôtBientôtAucun contrôle d'ordre
Cocher suffit pour la configuration. L'utilisateur choisit parmi ce que tu acceptes, et l'ordre à l'écran n'a aucune importance. Chaque wallet conserve son état de catalogue jusqu'à sa mise en ligne.
Flux Smart-ID et Mobile-ID
MitID · Danish Agency for Digital Government
Surfaces d'administration uniquement
Les utilisateurs finaux ne voient jamais d'étiquette d'assurance, de nom de source ou de prix. Vos réviseurs voient les trois.
Pays avec au moins un portefeuille
Pays
Couvert par le portefeuille EUDI
La couverture suit le catalogue pays par pays. Un drapeau ici signifie qu'un portefeuille est listé pour ce pays, pas qu'il est en ligne.
$ curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: <your-api-key>" \
-H "Content-Type: application/json" \
-d '{
"workflow_id": "wf_wallets",
"vendor_data": "user_42"
}'{ "url": "https://verify.didit.me/..." }// Your endpoint receives a signed payload
const crypto = require("node:crypto"); // ESM: import crypto from "node:crypto"
// X-Signature-V2 = HMAC over the canonical JSON, never the raw bytes. Match the sender byte for
// byte: keys sorted by code point, integers digit for digit, floats in Python's repr.
class Num { constructor(src) { this.src = src; } } // a number as written on the wire, not a double
const num = (s) => { if (/^-?\d+$/.test(s)) return BigInt(s).toString(); const n = +s; // ints stay exact
if (Number.isInteger(n)) return BigInt(n).toString(); const [m, e] = n.toExponential().split("e"); // 27.0 -> 27
return +e >= -4 ? String(n) : `${m}e-${String(-e).padStart(2, "0")}`; }; // 1e-05, not 0.00001
const byCodePoint = (a, b) => Buffer.compare(Buffer.from(a), Buffer.from(b)); // UTF-8 order = Python's
const canon = (v) => Array.isArray(v) ? `[${v.map(canon)}]` : v instanceof Num ? num(v.src)
: v && typeof v === "object" ? `{${Object.keys(v).sort(byCodePoint).map((k) => `${JSON.stringify(k)}:${canon(v[k])}`)}}`
: JSON.stringify(v);
// Read the body as text: express.json() would round 1000000000000000129 to a double first.
// Register this route ABOVE any global app.use(express.json()): the first parser to run
// consumes the stream, and a body it already parsed has lost the digits the signature covers.
app.post("/webhooks/didit", express.text({ type: "application/json" }), (req, res) => {
const exact = JSON.parse(req.body, (k, v, c) => typeof v === "number" ? new Num(c.source) : v); // Node 21+
const body = JSON.parse(req.body);
const mac = crypto.createHmac("sha256", SECRET).update(canon(exact), "utf8").digest("hex");
const sig = Buffer.from(String(req.headers["x-signature-v2"] ?? ""));
// Freshness comes from the signed body timestamp; the header alone is unsigned and replayable.
const ts = body.timestamp, fresh = String(ts) === req.headers["x-timestamp"]
&& Math.abs(Date.now() / 1000 - ts) <= 300;
if (!fresh || sig.length !== mac.length
|| !crypto.timingSafeEqual(sig, Buffer.from(mac))) return res.sendStatus(401);
const { status, decision } = body;
// One entry per ID Verification node; pick yours by node_id when you run several.
const [idv] = decision?.id_verifications ?? [];
// idv.verification_method: "document" | "id_lookup" | "wallet"
res.sendStatus(200);
});{ "verification_method": "wallet", "assurance": "cryptographic" }# Didit digital ID wallets — integrate in 5 minutes
You are adding digital ID wallet sign-in to my_stack. The user signs in with a
government or bank digital identity and the wallet returns signed attributes.
Every URL, header, and enum value below is canonical — do not paraphrase or
"improve" them.
## 1. Provision an account
- Sign up: https://business.didit.me (no credit card required).
- Grab the API key for your application from the console.
## 2. Read the methods catalog first
Wallet availability is server-driven per country. Never hard-code a wallet list.
The catalog is not a public REST endpoint. Read it one of two ways:
- Business Console (signed in): your application -> ID Verification ->
Countries tab. https://docs.didit.me/console/id-verification-methods
- Didit MCP server tool didit_workflow_get_id_verification_methods_catalog,
authenticated with the same x-api-key; pass country (ISO 3166-1 alpha-3)
to narrow it to one country. https://docs.didit.me/integration/mcp/tools
- Public mirror of the coverage table (no auth, read-only):
https://docs.didit.me/core-technology/id-verification/verification-methods#coverage
The catalog gives you, per wallet id: the display name, the countries it
covers, the issuing authority, the level of assurance, the availability state,
and the attributes it returns. MitID, Smart-ID, Mobile-ID and Finnish Trust
Network are available. Read the Finnish Trust Network integration guide:
https://docs.didit.me/core-technology/id-verification/finnish-trust-network
iDIN and other wallets remain coming soon until the catalog in
your environment marks them available. Re-read it; do not hard-code a date.
## 3. Create a workflow with the ID Verification (OCR) feature
POST https://verification.didit.me/v3/workflows/
-H "x-api-key: <your-api-key>"
-H "Content-Type: application/json"
The ID Verification feature's enum value is OCR (UPPERCASE — strict enum;
there is no ID_VERIFICATION alias and the API rejects it). Wallets are its
wallet method, accepted per country under config.methods on that same
feature entry, in the same request. Keys are ISO 3166-1 alpha-3.
{
"workflow_label": "Wallet onboarding",
"features": [
{
"feature": "OCR",
"config": {
"methods": {
"DNK": {
"document": { "enabled": true },
"wallet": {
"enabled": true,
"providers": ["mitid"],
"on_failure": "fallback_to_document"
}
},
"FIN": {
"document": { "enabled": true },
"wallet": {
"enabled": true,
"providers": ["ftn"],
"on_failure": "fallback_to_document"
}
}
}
}
}
]
}
Response: the workflow uuid — use it as workflow_id in step 4.
Rules that the API enforces:
- providers is an accept-list, not a ranking. Order carries no meaning and
the end user picks
- on_failure is either fallback_to_document or decline. It covers all three
cases: no wallet, cancelled, sign-in failed
- a wallet id the catalog does not mark available for that country is
rejected, and the rejection fails the whole save — including any lookup
configuration next to it. For unavailable wallets, keep wallet.enabled
false (or omit the wallet block) so the save succeeds
- unknown wallet ids already saved on a workflow are preserved untouched, so
a config written by a newer console version is never silently dropped
- a country with no method enabled is rejected at publish time
## 4. Create a session
POST https://verification.didit.me/v3/session/
-H "x-api-key: <your-api-key>"
-H "Content-Type: application/json"
-d '{ "workflow_id": "<id from step 3>", "vendor_data": "<your user id>" }'
Response: 201 with url (the hosted verification link), session_token and
session_id. Redirect the user to url, or open it in the SDK. The field is
named url — there is no session_url and no verification_url. Didit
shows the accepted wallets for the user's country with their brand marks,
hands off to the wallet, and waits for the signed assertion to come back.
## 5. Webhooks
Register a destination (console -> API & Webhooks, or
POST https://verification.didit.me/v3/webhook/destinations/ with
webhook_version "v3" and subscribed_events ["status.updated"]) and store the
secret_shared_key it returns. Verify every delivery:
Header: X-Signature-V2 (NOT X-Signature, NOT X-Signature-Simple)
Algorithm: HMAC-SHA256, hex digest, over the CANONICAL JSON of the payload
— the sender's Python json.dumps(sort_keys=True,
separators=(",", ":"), ensure_ascii=False) after whole-valued
floats become ints. Reproduce those bytes EXACTLY; do NOT
"parse, sort keys, JSON.stringify", which fails in four ways:
numbers come from the wire TEXT, never from parsed doubles
(read the body with express.text, not express.json(),
registered ABOVE any global app.use(express.json()), and
re-emit integers through BigInt(source) — JSON.parse rounds
1000000000000000129); floats use Python's repr (1e-05, not
0.00001; 27.0 becomes 27); keys sort by Unicode CODE POINT as
strings ("10" before "2", U+FF21 before U+1F642, which
JavaScript's default .sort() reverses); and the bytes come
straight from the sorted entries, never from a rebuilt object.
Do NOT hash the raw request bytes — that is the v1
X-Signature algorithm and fails for V2 whenever whitespace or
key order differs from the canonical form.
Freshness: the signed body field timestamp is the dispatch time (Unix
seconds, refreshed on every retry). Reject when
abs(now - timestamp) > 300 seconds, and reject when the
X-Timestamp header does not equal it. The header is not
covered by the signature, so it must never be the only replay
check: a captured delivery replays with just that header
refreshed.
Compare: constant-time (crypto.timingSafeEqual)
Reference handler (Express) — use it as written:
// Your endpoint receives a signed payload
const crypto = require("node:crypto"); // ESM: import crypto from "node:crypto"
// X-Signature-V2 = HMAC over the canonical JSON, never the raw bytes. Match the sender byte for
// byte: keys sorted by code point, integers digit for digit, floats in Python's repr.
class Num { constructor(src) { this.src = src; } } // a number as written on the wire, not a double
const num = (s) => { if (/^-?\d+$/.test(s)) return BigInt(s).toString(); const n = +s; // ints stay exact
if (Number.isInteger(n)) return BigInt(n).toString(); const [m, e] = n.toExponential().split("e"); // 27.0 -> 27
return +e >= -4 ? String(n) : `${m}e-${String(-e).padStart(2, "0")}`; }; // 1e-05, not 0.00001
const byCodePoint = (a, b) => Buffer.compare(Buffer.from(a), Buffer.from(b)); // UTF-8 order = Python's
const canon = (v) => Array.isArray(v) ? `[${v.map(canon)}]` : v instanceof Num ? num(v.src)
: v && typeof v === "object" ? `{${Object.keys(v).sort(byCodePoint).map((k) => `${JSON.stringify(k)}:${canon(v[k])}`)}}`
: JSON.stringify(v);
// Read the body as text: express.json() would round 1000000000000000129 to a double first.
// Register this route ABOVE any global app.use(express.json()): the first parser to run
// consumes the stream, and a body it already parsed has lost the digits the signature covers.
app.post("/webhooks/didit", express.text({ type: "application/json" }), (req, res) => {
const exact = JSON.parse(req.body, (k, v, c) => typeof v === "number" ? new Num(c.source) : v); // Node 21+
const body = JSON.parse(req.body);
const mac = crypto.createHmac("sha256", SECRET).update(canon(exact), "utf8").digest("hex");
const sig = Buffer.from(String(req.headers["x-signature-v2"] ?? ""));
// Freshness comes from the signed body timestamp; the header alone is unsigned and replayable.
const ts = body.timestamp, fresh = String(ts) === req.headers["x-timestamp"]
&& Math.abs(Date.now() / 1000 - ts) <= 300;
if (!fresh || sig.length !== mac.length
|| !crypto.timingSafeEqual(sig, Buffer.from(mac))) return res.sendStatus(401);
const { status, decision } = body;
// One entry per ID Verification node; pick yours by node_id when you run several.
const [idv] = decision?.id_verifications ?? [];
// idv.verification_method: "document" | "id_lookup" | "wallet"
res.sendStatus(200);
});
Body fields you will use: session_id, status, webhook_type, workflow_id,
vendor_data, decision.
Status values: Approved, Declined, In Review, In Progress, Not Started,
Abandoned.
## 6. Reading the result
The decision is the V3 shape: every feature result is a plural array with one
entry per workflow node. ID Verification results live in
decision.id_verifications[] — there is no singular decision.kyc (that is the
V2 shape) and no decision.id_verification. Select your entry by node_id (the
id of your ID Verification node in the workflow graph); with a single ID step,
take index 0. Each entry carries, next to the document fields:
verification_method "document" | "id_lookup" | "wallet"
assurance "documentary" | "data_match" | "cryptographic"
wallet_provider the catalog wallet id the user signed in with; null
on document and id_lookup entries
wallet_verification provider, provider_name, issuing_authority,
issuing_country, credential_type, level_of_assurance
(low | substantial | high), verified_at,
signature_valid, attributes (what the wallet shared),
portrait when the wallet shares one; null otherwise
fallback_from { method, reason, action } when the session fell
back to document capture or was declined; else null
A wallet entry that succeeds is assurance cryptographic — the highest of the
three. Check wallet_verification.signature_valid before you trust attributes.
Field-by-field reference: https://docs.didit.me/reference/data-models#id-verification
## 7. Billing
- published customer prices in USD per completed wallet verification:
- MitID personal: $0.25; production availability: Available
- BankID Sweden: $0.20; production availability: Available
- Finnish Trust Network: $0.25; production availability: Available
- Smart-ID: $0.20; production availability: Available
- Mobile-ID: $0.20; production availability: Available
- BankID Norway High: $0.35; production availability: Coming soon
- Vipps Plus: $0.25; production availability: Coming soon
- Buypass ID: Coming soon; production availability: Coming soon
- itsme: Coming soon; production availability: Coming soon
- iDIN full identification: $0.85; production availability: Coming soon
- Personalausweis Profile 2: $0.45; production availability: Coming soon
- Freja eID: $0.25; production availability: Coming soon
- UAE PASS: Coming soon; production availability: Coming soon
- gov.br: Coming soon; production availability: Coming soon
- OneID: $2.50; production availability: Coming soon
- GOV.UK Wallet: Coming soon; production availability: Coming soon
- Bank iD: Coming soon; production availability: Coming soon
- MojeID: Coming soon; production availability: Coming soon
- Diia: Coming soon; production availability: Coming soon
- FranceConnect: Coming soon; production availability: Coming soon
- Auðkenni: Coming soon; production availability: Coming soon
- ConnectID: Coming soon; production availability: Coming soon
- EUDI Wallet: Coming soon; production availability: Coming soon
- Estonian ID-card: Coming soon; production availability: Coming soon
- eParaksts: Coming soon; production availability: Coming soon
- an announced price does not enable a wallet; check the live workflow catalog
- wallet checks are outside the document free tier; other checks are billed separately
- full pricing: https://docs.didit.me/core-technology/id-verification/digital-id-wallets#pricing
- document capture bills its own price when the user falls back
## 8. Hard rules — do not change
- base URL for v3 endpoints: verification.didit.me
- auth header: x-api-key (lowercase, hyphenated)
- webhook headers: X-Signature-V2 plus X-Timestamp; canonical JSON, never
raw bytes; freshness from the signed body timestamp
- feature enum: OCR (uppercase) — the ID Verification feature; per-country
methods go under its config.methods
- method keys: document, id_lookup, wallet (lowercase, snake_case)
- wallet ids come from the catalog verbatim, lowercase, snake_case
- country keys: ISO 3166-1 alpha-3, uppercase
- result path: decision.id_verifications[] (array), never decision.kyc
## 9. Verify your integration
- run one session per accepted wallet in sandbox
- assert the id_verifications[] entry for your node has verification_method
wallet and wallet_verification.signature_valid true
- cancel a wallet sign-in and assert your on_failure setting actually fires
- assert your webhook accepts a correctly signed payload with reordered
keys, whitespace and integer-like metadata keys ("10" before "2"), and
rejects a wrong X-Signature-V2, a payload whose signed timestamp is older
than 300 seconds, and that same stale payload with only the X-Timestamp
header refreshed
Docs: https://docs.didit.me/integration/integration-prompt
Les prix ci-dessous sont en USD par vérification de portefeuille complétée. Ils couvrent le produit d'identité nommé ; les autres vérifications de workflow et le fallback documentaire sont facturés séparément. Les 500 vérifications documentaires mensuelles gratuites ne couvrent pas les portefeuilles. Un prix annoncé ne signifie pas qu'un portefeuille est actif : la disponibilité est indiquée séparément. Les portefeuilles disponibles sans tarif publié affichent « Sur demande » ; les portefeuilles prévus sans tarif publié affichent « Bientôt disponible ». Les portefeuilles d'identité vérifient les personnes ; le screening des portefeuilles crypto est un produit distinct.
« Disponible » signifie activé en production. « Bientôt disponible » signifie pas encore activé en production, même si les tests d'intégration ont commencé. Les portefeuilles disponibles apparaissent en premier.
ConnectID (Australie) est intégré pour les tests en sandbox ; l'accès en production est à venir. La carte d'identité estonienne (Estonie) et eParaksts (Lettonie) sont des intégrations prévues. Ces wallets n'ont pas de prix publiés ni de dates de lancement en production.
Lire la documentation détaillée| Portefeuille d'identité | USD / vérification complétée | Pays / région | Disponibilité en production |
|---|---|---|---|
| MitID personal | 0,25 $US |
| Disponible |
| BankID Sweden | 0,20 $US |
| Disponible |
| Finnish Trust Network | 0,25 $US |
| Disponible |
| Smart-ID | 0,20 $US |
| Disponible |
| Mobile-ID | 0,20 $US |
| Disponible |
| BankID Norway High | 0,35 $US |
| Bientôt disponible |
| Vipps Plus | 0,25 $US |
| Bientôt disponible |
| Buypass ID | Bientôt disponible |
| Bientôt disponible |
| itsme | Bientôt disponible |
| Bientôt disponible |
| iDIN full identification | 0,85 $US |
| Bientôt disponible |
| Personalausweis Profile 2 | 0,45 $US |
| Bientôt disponible |
| Freja eID | 0,25 $US |
| Bientôt disponible |
| UAE PASS | Bientôt disponible |
| Bientôt disponible |
| gov.br | Bientôt disponible |
| Bientôt disponible |
| OneID | 2,50 $US |
| Bientôt disponible |
| GOV.UK Wallet | Bientôt disponible |
| Bientôt disponible |
| Bank iD | Bientôt disponible |
| Bientôt disponible |
| MojeID | Bientôt disponible |
| Bientôt disponible |
| Diia | Bientôt disponible |
| Bientôt disponible |
| FranceConnect | Bientôt disponible |
| Bientôt disponible |
| Auðkenni | Bientôt disponible |
| Bientôt disponible |
| ConnectID | Bientôt disponible |
| Bientôt disponible |
| EUDI Wallet | Bientôt disponible |
| Bientôt disponible |
| Estonian ID-card | Bientôt disponible |
| Bientôt disponible |
| eParaksts | Bientôt disponible |
| Bientôt disponible |
Pour le développement, les tests et tes premiers utilisateurs.
Plus de 25 modules, tarifs publics. Remises automatiques sur volume.
Pour les gros volumes et les programmes réglementés.
Les remises sur volume s'appliquent automatiquement à mesure que votre utilisation augmente — pas de négociation, pas d'appel commercial.
Didit est une infrastructure pour l'identité et la fraude, la plateforme que nous aurions aimé avoir quand nous développions nos propres produits : ouverte, flexible et pensée pour les développeurs, pour qu'elle s'intègre vraiment à ta stack au lieu d'être une boîte noire autour de laquelle tu dois t'adapter.
Une seule API couvre la vérification des personnes (KYC, know your customer), la vérification des entreprises (KYB, know your business), le screening des portefeuilles crypto (KYT, know your transaction), et le monitoring des transactions en temps réel, sur une stack conçue pour être :
En coulisses : plus de 14 000 types de documents dans plus de 48 langues, plus de 1 000 sources de données et plus de 200 signaux de fraude sur chaque session. L'infrastructure Didit apprend dynamiquement de chaque session et s'améliore chaque jour.
L'utilisateur s'authentifie avec une identité électronique (eID) existante, et Didit vérifie la preuve d'identité signée avant d'écrire le résultat dans la session. L'interaction dépend du portefeuille : Smart-ID demande un code personnel, tandis que Mobile-ID demande également un numéro de téléphone. Les deux utilisent un code de comparaison et une approbation sur l'appareil de l'utilisateur.
L'authentification par portefeuille est une méthode au sein de la vérification d'identité, aux côtés de la capture de documents et de la recherche sans document. Dans l'API de workflow, cette fonctionnalité est nommée OCR. Les portefeuilles disponibles dépendent du pays et de l'environnement. Commence par la documentation des portefeuilles.
MitID, Smart-ID, Mobile-ID et Finnish Trust Network sont disponibles. Smart-ID couvre l'Estonie, la Lettonie, la Lituanie et la Belgique ; Mobile-ID couvre l'Estonie et la Lituanie ; Finnish Trust Network couvre la Finlande. MitID dessert le Danemark. Les autres portefeuilles listés, y compris iDIN, BankID, Freja eID, ConnectID et le portefeuille EUDI, sont « bientôt disponibles ».
Choisis les portefeuilles acceptés pour chaque pays dans la console. L'API de workflow utilise le catalogue pour ton environnement et ton pays. Utilise le guide d'intégration pour configurer le fallback documentaire.
L'utilisateur choisit un portefeuille accepté, saisit son code personnel et fournit un numéro de téléphone pour Mobile-ID. Didit affiche un code de comparaison. L'utilisateur vérifie que le code correspond à celui de son téléphone et approuve la demande d'authentification sur celui-ci. Le code PIN n'est saisi que sur l'appareil de l'utilisateur, jamais dans Didit.
Didit attend la réponse signée, vérifie la signature et le statut du certificat, et renvoie les attributs d'identité vérifiés à la session. Le temps d'achèvement dépend de l'utilisateur et de la réponse du portefeuille. Suis le guide Smart-ID et Mobile-ID.
Didit vérifie la signature d'authentification par rapport au défi de cette session, vérifie le certificat par rapport aux émetteurs de confiance et vérifie son statut de révocation. L'identité renvoyée doit correspondre au code personnel et au pays utilisés pour la demande. Le flux hébergé valide également son jeton de session et rejette les tentatives de complétion répétées.
Ces vérifications connectent la réponse signée à l'utilisateur et à la demande attendus. Elles ne remplacent pas la nécessité pour l'utilisateur de comparer les codes et de protéger son appareil. Lis la méthode de vérification, le fournisseur de portefeuille et les attributs signés sur le résultat de la session, et vérifie les signatures de webhook avant d'utiliser un résultat dans ton application. Consulte le guide technique.
Un seul réglage gère ces trois cas : pas de portefeuille, annulation ou échec de connexion. Il bascule vers la capture de document ou refuse la session, et tu peux le configurer par pays.
Le résultat enregistre la méthode de repli et la raison, ainsi une connexion par portefeuille abandonnée n'est jamais invisible.
Smart-ID est disponible pour l'Estonie, la Lettonie, la Lituanie et la Belgique. Mobile-ID est disponible pour l'Estonie et la Lituanie. Mobile-ID n'est pas pris en charge pour la Lettonie. Les utilisateurs ont besoin d'un identifiant éligible pour le portefeuille sélectionné.
Active chaque portefeuille pour le pays correspondant dans ton workflow. Lis le guide Smart-ID et Mobile-ID pour les étapes d'authentification, les champs d'identité vérifiés et le fallback documentaire.
Chiffrées en transit et au repos, dans la région de ton choix, sous SOC 2 Type 1 et Type 2, ISO 27001 et GDPR.
Un portefeuille ne partage que les attributs demandés par la requête, et tu peux décocher tout attribut optionnel pour qu'il ne soit jamais stocké. Les attributs requis sont toujours stockés, avec la référence de l'assertion signée dont un auditeur a besoin.
Tous les détails sur /security-compliance.
Didit est en production avec plus de 2 000 entreprises dans des secteurs réglementés — fintech, banque, iGaming, crypto, marketplaces, santé et gouvernement.
La connexion par portefeuille atteint une assurance cryptographique, la preuve la plus solide des trois méthodes, et le niveau d'assurance est enregistré pour chaque session. Lorsqu'un régulateur nomme un eID national spécifique, accepter ce portefeuille est généralement le moyen le plus simple de s'y conformer.
Mémos sur /security-compliance.
En quelques minutes, de trois façons.
Commence sur business.didit.me, ou lis docs.didit.me/integration/integration-prompt.
Une seule API pour le KYC, le KYB, la surveillance des transactions et le screening de portefeuilles. Intégration en 5 minutes.