Passer au contenu principal
Didit lève 7,5 M$ pour bâtir l'infrastructure pour l'identité et la fraude
Didit
Vérification NFC

Lis la puce.
Vérifie la signature.

Approche un passeport ou une e-ID du téléphone. La puce est lue, la signature gouvernementale est validée, et les falsifications que les vérifications photo classiques manquent sont détectées. 0,15 $ par lecture, 500 gratuites/mois.

Soutenu par
Y CombinatorRobinhood Ventures
Vérification d'identité NFC Didit, lis la puce eID d'un passeport ou d'une carte nationale.

ICAO 9303

Lis la puce.
Signée cryptographiquement.

Approche le passeport. La puce renvoie les mêmes données que la photo, sauf que cette fois, elles sont signées par le pays émetteur. 0,15 $, en moins de 2 secondes.

Comment ça marche

De l'inscription à l'utilisateur vérifié en quatre étapes.

  1. Étape 01

    Crée le workflow

    Choisis les vérifications que tu souhaites, ID, détection du vivant, correspondance faciale, sanctions, adresse, âge, téléphone, e-mail, questions personnalisées. Glisse-les dans un flux sur le tableau de bord, ou publie le même flux via notre API. Crée des branches conditionnelles, lance des tests A/B, aucun code requis.

  2. Étape 02

    Intègre

    Intègre nativement avec nos SDK Web, iOS, Android, React Native ou Flutter. Redirige vers une page hébergée. Ou envoie simplement un lien à ton utilisateur, par e-mail, SMS, WhatsApp, n'importe où. Choisis ce qui correspond à ta stack.

  3. Étape 03

    L'utilisateur suit le parcours

    Didit gère la caméra, les indications lumineuses, le transfert mobile et l'accessibilité. Pendant que l'utilisateur est dans le flux, nous évaluons plus de 200 signaux de fraude en temps réel et vérifions chaque champ par rapport à des sources de données fiables. Résultat en moins de deux secondes.

  4. Étape 04

    Tu reçois les résultats

    Des webhooks signés en temps réel maintiennent ta base de données synchronisée dès qu'un utilisateur est approuvé, refusé ou envoyé en révision. Interroge l'API à la demande. Ou ouvre la console pour inspecter chaque session, chaque signal, et gérer les cas à ta manière.

Conçu pour les développeurs · Conçu contre la fraude · Ouvert par nature

Six fonctionnalités. Un seul *feature flag*. NFC.

Chaque fonctionnalité ci-dessous est un interrupteur sur le même module. Pas de paliers de prix, pas de SKU séparés, pas d'appels pour des add-ons. Active-les par workflow, ou inclus le module NFC quand tu crées un workflow via l'API.
01 · Lecture cryptographique

Vérifie la signature sur chaque puce, pas l'impression sur la page.

Chaque passeport électronique et e-ID moderne contient une puce sans contact signée par le gouvernement émetteur. Nous la lisons via NFC (communication en champ proche), validons la signature numérique et renvoyons un verdict infalsifiable. Cela permet de détecter les attaques de morphing, les substitutions de photos et les falsifications qui passent l'inspection visuelle.
02 · Groupes de données ICAO 9303

Contenu complet de la puce extrait, structuré et signé.

Chaque groupe de données ICAO 9303 sur la puce est lu, objet de sécurité signé, données personnelles, MRZ (zone de lecture automatique), image faciale haute résolution, image de signature, plus toute biométrie supplémentaire stockée par le pays émetteur. Tu obtiens un JSON `chip_data` propre, ainsi que des URL signées pour le portrait et la signature.
03 · Confiance ICAO PKD

Confiance ancrée au répertoire de clés publiques de l'ICAO.

Chaque lecture de puce retrace la chaîne complète de certificats, signataire du document → autorité de signature du pays → racine du répertoire de clés publiques ICAO, et vérifie la liste de révocation du pays en temps réel. Les certificats révoqués et expirés apparaissent comme des avertissements configurables ; les autres passent comme des booléens d'authenticité sur le rapport.
04 · Photo vs puce

Vérifie chaque champ. Refus automatique en cas de non-concordance.

Les données de la photo doivent correspondre aux données de la puce. En cas de divergence, la session est automatiquement refusée, ce déclencheur ne peut pas être désactivé. C'est le signal le plus clair d'une zone photo altérée, d'une puce échangée ou d'un faux document avec une impression d'apparence réelle.
05 · Mobile SDK d'abord

iOS, Android, React Native, Flutter, lecture de puce intégrée.

Les SDK natifs gèrent pour toi le lecteur NFC de l'appareil, les autorisations et l'interface utilisateur de lecture de puce. iOS utilise Core NFC ; Android utilise IsoDep sur NfcAdapter ; React Native et Flutter enveloppent les deux. Les navigateurs sans NFC basculent automatiquement vers l'ID standard + selfie, un avertissement de saut est déclenché et la session continue.
06 · Couverture mondiale

Tous les pays émetteurs ICAO, en croissance chaque trimestre.

La plupart des passeports émis après 2006 intègrent une puce, ainsi qu'une liste croissante d'e-ID nationaux, DNIe espagnol, Personalausweis allemand, CIE italien, carte d'identité estonienne, Cartão de Cidadão portugais, eID belge, eID néerlandais. Les certificats nationaux sont mis à jour automatiquement ; les nouveaux pays deviennent lisibles le jour où nous les intégrons.
Intègre

Un workflow. Deux façons de lancer la lecture de la puce.

Le NFC n'a pas de point de terminaison autonome de serveur à serveur, la puce nécessite un appareil doté du matériel NFC. Les deux chemins ci-dessous partagent le même appel de création de session ; ils ne diffèrent que par le fait que l'utilisateur lise la puce dans notre interface hébergée ou dans ta propre application via le SDK natif.
POST /v3/session/Interface hébergée
$ curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "wf_id_nfc",
    "vendor_data": "user-42"
  }'
201Créé{ "session_url": "verify.didit.me/..." }
Nous hébergeons l'interface de lecture de puce. Le workflow doit inclure ID_VERIFICATION + NFC.docs →
DiditSdk.startVerificationSDK natif
// iOS · Swift
import DiditSdk

let result = try await DiditSdk.shared.startVerification(
    avec : sessionId,
    configuration : config
)
donein-app{ "status": "Approved" }
Tu gères l'interface utilisateur. Le SDK gère le NFC. Android, React Native, Flutter sont tous pris en charge.docs →
Intégration prête pour agent

Déploie la vérification NFC en une seule instruction.

Colle le bloc ci-dessous dans Claude Code, Cursor, Codex, Devin, Aider ou Replit Agent. Remplace le placeholder my_stack par ton framework, ton langage et ton cas d'utilisation. L'agent provisionne Didit, construit le workflow avec NFC activé, connecte le webhook et déploie.
didit-integration-prompt.md
# Didit NFC Verification — integrate in 5 minutes

You are integrating Didit's NFC Verification (cryptographic e-passport
and e-ID chip reading) module into <my_stack>. Follow these steps exactly.
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).
- Or provision programmatically: POST https://apx.didit.me/auth/v2/programmatic/register/
  (returns an API key bound to the workspace + application).

## 2. What NFC Verification actually does
NFC Verification reads the secure contact-less chip embedded in modern
e-passports and e-IDs (the small chip-and-antenna sticker symbol on the
cover) and runs four cryptographic checks against the data it extracts:

1. Passive Authentication — every Data Group (DG1 personal data, DG2
   facial image, etc.) is hashed and compared against the signed hash
   stored in the Document Security Object (SOD). Catches any single-bit
   tampering of the chip contents.
2. Certificate chain validation — Document Signer Certificate (DSC) →
   Country Signing Certificate Authority (CSCA) → ICAO Public Key
   Directory (PKD) root. Proves the chip was signed by the issuing
   government, not a clone.
3. Certificate Revocation List (CRL) check — DSCs revoked by the issuing
   country are caught and flagged.
4. Chip Authentication — where the document supports it, prevents chip
   cloning by challenging the chip with a key-pair handshake.

PACE (Password Authenticated Connection Establishment) or BAC (Basic
Access Control) is used to derive the session key from the Machine-Readable Zone (MRZ); Didit
handles that automatically. All of this is ICAO 9303 standard.

## 3. Two integration paths — pick one

### Path A — Workflow Builder (hosted UI, REQUIRED for NFC)
NFC Verification has no server-to-server standalone endpoint. The chip
has to be read by a device with NFC hardware, so you always integrate
through the Workflow + native SDK (or hosted mobile web that falls back).

1. Create a workflow that contains the NFC feature:
   POST https://verification.didit.me/v3/workflows/
   Authorization header:  x-api-key: <your-api-key>
   Body: workflow_label, features array with the entries
         { feature: "ID_VERIFICATION" }
         { feature: "NFC" }
         (UPPERCASE — strict enum)
   You should always pair NFC with ID_VERIFICATION so the MRZ is captured
   for the chip handshake AND so an OCR cross-validation is available.

2. Create a verification session for an end user:
   POST https://verification.didit.me/v3/session/
   Body: workflow_id (from step 1), vendor_data (your own user id).
   Response: session_url — redirect the user to it (or open it in the
   native SDK with shared.startVerification(with: sessionId)).

3. Listen for webhook callbacks (see "Webhooks" below).

### Path B — Native SDKs (drop-in, recommended for mobile apps)
Same workflow + session above, but launch the verification flow in your
own iOS or Android app via the Didit SDK. The SDK wires the NFC reader,
the entitlements, and the chip-reading UI for you.

- iOS: DiditSdk.shared.startVerification(with: sessionId, configuration:)
  Required entitlements (handled by the SDK):
    - com.apple.developer.nfc.readersession.formats = ["TAG"]
    - ISO7816 application identifiers for ePassports
- Android: DiditSdk.startVerification(sessionId, config) — uses
  IsoDep (android.nfc.tech.IsoDep) under the hood.
- React Native / Flutter: the same SDK, exposed through the cross-
  platform module — see docs.didit.me/integration/native-sdks/.

### Web browsers — NFC is unavailable
Web NFC API is not generally available. Chrome on Android has an
experimental Web NFC that is unstable and requires explicit permissions;
Safari on iOS has no support. For web integrations, NFC is automatically
skipped and the user proceeds with standard ID + selfie. If you require
NFC, deep-link the user into the Didit App or your own native app.

## 4. Webhooks
- Register a webhook destination once via
  POST https://verification.didit.me/v3/webhook/destinations/
  Body: url, subscribed_events: ["session.verified", "session.review_started",
                                  "session.declined"]
- Response includes secret_shared_key — store it.
- Every webhook delivery carries an X-Signature-V2 header you MUST verify
  before trusting the payload.  HMAC-SHA256 verification MUST run against the raw body bytes (the raw payload as Didit sent it) BEFORE any JSON parsing — re-serialising the parsed body changes whitespace and key order, which invalidates the signature.Algorithm:
    1. sortKeys(payload) recursively
    2. shortenFloats (truncate trailing zeros after the decimal point)
    3. JSON.stringify the result
    4. HMAC-SHA256 with the secret_shared_key
    5. Hex-encode, compare to the X-Signature-V2 header.

## 5. Reading the report
The session report includes an nfc object alongside the id_verification
object. Top-level fields on nfc:

- status: "Approved" | "Declined" | "In Review" | "Not Finished"
- portrait_image: signed URL to the chip-extracted DG2 facial image
- signature_image: signed URL to the chip-extracted DG7 signature
- chip_data:
    document_type, issuing_country (ISO 3166-1 alpha-3),
    document_number, expiration_date (YYYY-MM-DD),
    first_name, last_name, birth_date, gender ("M" | "F" | "U"),
    nationality (ISO 3166-1 alpha-3), address, place_of_birth.
- authenticity:
    sod_integrity (boolean — every Data Group hash matched the SOD)
    dg_integrity (boolean — Data Group binary integrity check passed)
- certificate_summary:
    issuer (CSCA Common Name + serial + organization + country)
    subject (DSC Common Name)
    serial_number
    not_valid_after (YYYY-MM-DD HH:MM:SS)
    not_valid_before (YYYY-MM-DD HH:MM:SS)
- warnings: Array of { risk, additional_data, log_type,
                       short_description, long_description }

### Auto-decline (always enforced, never configurable)
- NFC_AND_OCR_DATA_NOT_SAME — Optical Character Recognition (OCR) data
  and chip data differ. Indicates document tampering or fake chip.

### Configurable warnings (per-workflow action: Decline / Review / Approve)
- SKIPPED_NFC_VALIDATION       — chip not read (no NFC hardware, no
                                  permissions, document has no chip)
- NFC_CHIP_NOT_VERIFIED        — chip read but signature could not be
                                  verified (missing CSCA, older document)
- DSC_CERTIFICATE_REVOKED      — Document Signer Certificate listed on
                                  the issuing country's CRL
- DSC_CERTIFICATE_EXPIRED      — Document Signer Certificate past its
                                  validity period

## 6. Hard rules — do not change
- Base URL for /v3/* endpoints is verification.didit.me (NOT apx.didit.me).
- Feature enum is UPPERCASE: NFC, ID_VERIFICATION, LIVENESS, FACE_MATCH.
- Auth header is x-api-key (lowercase, hyphenated).
- Webhook signature header is X-Signature-V2 (NOT X-Signature).
- Always verify webhook signatures before trusting payload data.
- Always pair NFC with ID_VERIFICATION in the workflow — NFC alone
  cannot derive the chip key without the MRZ from the document photo.
- Status casing matches exactly: "Approved", "Declined", "In Review",
  "Not Finished" (title-cased, space-separated).
- Treat NFC as an additive confidence boost, not a hard gate, unless
  your risk policy explicitly requires it (regulated remote
  onboarding under PSD3, AMLD6 high-risk customer flows, etc.).

## 7. Pricing reference (public)
- NFC Verification: $0.15 per chip read (standalone module).
- Bundled inside a full Know Your Customer (KYC) workflow (ID + Liveness + Face Match + NFC):
  priced as the underlying KYC bundle ($0.33) + $0.15 NFC if enabled.
- 500 free checks every month, forever, on every account.

## 8. Verify your integration
- Sandbox starts on signup at https://business.didit.me — no separate flag.
- Test documents: use the Didit App on a real iOS or Android device with
  any ICAO 9303 e-passport issued after 2006 (most modern passports).
- Sandbox webhook events fire the same shape as production; verify the
  X-Signature-V2 header in dev too.
- Switch to live: flip the application's environment toggle in console.

When in doubt: https://docs.didit.me/core-technology/nfc-verification/overview
Besoin de plus de contexte ? Consulte la documentation complète du module.docs.didit.me →
Conforme par nature

Ouvre un nouveau pays en un clic. On s'occupe du plus dur.

Nous ouvrons les filiales locales, obtenons les licences, effectuons les tests d'intrusion, obtenons les certifications et nous alignons sur chaque nouvelle réglementation. Pour déployer des vérifications dans un nouveau pays, il suffit d'activer un interrupteur. Plus de 220 pays en direct, audités et testés chaque trimestre, le seul fournisseur d'identité qu'un gouvernement d'un État membre de l'UE a formellement jugé plus sûr que la vérification en personne.
Lire le dossier sécurité & conformité
Bac à sable financier de l'UE
Tesoro · SEPBLAC · BdE
Jugendschutz geprüft
FSM · JMStV §4(2) · 2026
ISO/IEC 27001
Sécurité de l'information · 2026
SOC 2 · Type I
AICPA · 2026
iBeta Level 1 PAD
NIST / NIAP · 2026
GDPR
EU 2016/679
DORA
EU 2022/2554
MiCA
EU 2023/1114
AMLD6 · eIDAS 2.0
Conforme UE par conception

Chiffres à l'appui

Chiffres à l'appui
  • ICAO 9303
    Chaque puce lue est vérifiée par rapport à la norme canonique des passeports électroniques.
  • PKD
    Confiance ancrée à la racine du répertoire de clés publiques de l'ICAO.
  • <0s
    Lecture de puce de bout en bout sur un smartphone moderne.
  • $0.00
    Par lecture de puce NFC. 500 gratuites chaque mois.
Trois niveaux, une seule grille tarifaire

Démarre gratuitement. Paye à l'usage. Passe à l'Enterprise.

500 vérifications gratuites chaque mois, pour toujours. Paiement à l'usage pour la production. Contrats personnalisés, résidence des données et SLAs (Service Level Agreements) pour l'Enterprise.
Gratuit

Gratuit

0 $ / mois. Aucune carte de crédit requise.

  • Pack KYC gratuit (vérification d'identité + détection de vivacité passive + correspondance faciale + analyse appareil & IP), 500 / mois, chaque mois
  • Utilisateurs bloqués
  • Détection des doublons
  • Plus de 200 signaux de fraude par session
  • KYC réutilisable sur le réseau Didit
  • Plateforme de gestion des cas
  • Workflow Builder
  • Documentation publique, sandbox, SDKs, serveur MCP (Model Context Protocol)
  • Support communautaire
Le plus populaire
Paiement à l'usage

Basé sur l'usage

Payez uniquement ce que vous utilisez. Plus de 25 modules. Tarification publique par module, sans minimum mensuel.

  • KYC complet à 0,33 $ (ID + Biométrie + IP / Appareil)
  • Plus de 10 000 bases de données AML, sanctions, PEP, médias défavorables
  • Plus de 1 000 sources de données gouvernementales pour la validation de base de données
  • Surveillance des transactions à 0,02 $ par transaction
  • KYB en direct à 2,00 $ par entreprise
  • Filtrage de portefeuille à 0,15 $ par vérification
  • Flux de vérification en marque blanche, votre marque, notre infrastructure
Entreprise

Entreprise

MSA et SLA personnalisés. Pour les gros volumes et les programmes réglementés.

  • Contrats annuels
  • MSA, DPA et SLA personnalisés
  • Canal Slack et WhatsApp dédié
  • Réviseurs manuels sur demande
  • Conditions de revendeur et de marque blanche
  • Fonctionnalités exclusives et intégrations partenaires
  • CSM dédié, audit de sécurité, support conformité

Commence gratuitement → ne paie que lorsqu'une vérification est effectuée → débloque l'Enterprise pour un contrat personnalisé, un SLA ou la résidence des données.

FAQ

Questions fréquentes

Qu'est-ce que Didit ?

Didit est une infrastructure pour l'identité et la fraude, la plateforme que nous aurions aimé avoir lorsque nous développions nos propres produits : ouverte, flexible et pensée pour les développeurs, afin qu'elle s'intègre parfaitement à votre stack plutôt que d'être une boîte noire autour de laquelle vous devez bricoler.

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 :

  • Rapide, p99 inférieur à 2 secondes sur chaque session
  • Fiable, en production avec plus de 1 500 entreprises dans plus de 220 pays
  • Sécurisée, SOC 2 Type 1, ISO 27001, conforme au GDPR, et attestée officiellement par le régulateur financier espagnol comme plus sûre qu'une vérification en personne

L'empreinte sous-jacente : 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.

Quels documents et pays sont pris en charge ?
Tous les passeports et cartes d'identité électroniques conformes à la norme ICAO 9303 dotés d'une puce sans contact intégrée, généralement indiquée par le symbole puce et antenne sur la couverture. La plupart des passeports émis après 2006 intègrent des puces NFC ; la couverture des cartes d'identité nationales varie selon les pays (DNIe espagnol, Personalausweis allemand, CIE italien, carte d'identité estonienne, Cartão de Cidadão portugais, et bien d'autres). Liste complète par pays sur docs.didit.me/core-technology/nfc-verification/supported-documents-nfc-verification. La puce est lue via PACE (Password Authenticated Connection Establishment) ou BAC (Basic Access Control), Didit dérive automatiquement la clé de session de la Zone de Lecture Automatique (MRZ), l'utilisateur n'a donc qu'à approcher son document du téléphone.
Quelle est la structure de la réponse ?
Un seul objet JSON nfc à côté de l'objet id_verification. Le status de niveau supérieur est l'un des suivants : Approved, Declined, In Review, ou Not Finished. L'objet inclut également un bloc chip_data (document_type, issuing_country en ISO 3166-1 alpha-3, document_number, expiration_date, first_name, last_name, birth_date, gender, nationality, address, place_of_birth), un bloc authenticity (sod_integrity, dg_integrity), un certificate_summary (issuer, subject, serial_number, not_valid_after, not_valid_before), des URL signées pour portrait_image (image faciale DG2 extraite de la puce) et signature_image (image de signature DG7 extraite de la puce), et un tableau warnings. Référence complète sur docs.didit.me/core-technology/nfc-verification/report-nfc-verification.
Quelle est la rapidité de la vérification pour mon utilisateur final ?

Le processus complet prend normalement moins de 30 secondes de bout en bout, prendre la pièce d'identité, la scanner, prendre le selfie, c'est fait. C'est le plus rapide du marché. Les fournisseurs KYC traditionnels prennent généralement plus de 90 secondes pour le même processus.

Côté back-end, Didit renvoie le résultat en moins de deux secondes au p99, mesuré à partir du moment l'utilisateur termine le selfie jusqu'au déclenchement de votre webhook. La capture mobile est optimisée pour les téléphones et les réseaux lents : compression d'image progressive, chargement paresseux du kit de développement logiciel, et un transfert en un clic du bureau au téléphone via QR code si l'utilisateur commence sur le web.

Comment Didit déjoue-t-il la fraude documentaire ?
Quatre couches cryptographiques, chaque couche activée par défaut. (1) Authentification Passive, chaque hachage de groupe de données est vérifié par rapport à la signature dans l'Objet de Sécurité du Document (SOD), détectant toute altération d'un seul bit du contenu de la puce. (2) Validation de la chaîne de certificats, Certificat de Signataire de Document vers l'AC de Signature de Pays vers la racine du Répertoire de Clés Publiques de l'ICAO, prouvant que la puce a été signée par le gouvernement émetteur. (3) Vérification de la Liste de Révocation de Certificats (CRL), les Certificats de Signataire de Document révoqués par le pays émetteur sont détectés. (4) Authentification de la Puce, c'est pris en charge, un échange de clés empêche le clonage de la puce. Plus une validation croisée : le MRZ de la puce doit correspondre au MRZ extrait par OCR, sinon la session est automatiquement refusée.
Que se passe-t-il si un utilisateur échoue, abandonne ou expire ?

Chaque session aboutit à l'un des sept statuts clairs, afin que votre code sache toujours quoi faire :

  • Approved, toutes les vérifications ont réussi. Faites avancer l'utilisateur.
  • Declined, une ou plusieurs vérifications ont échoué. Vous pouvez permettre à l'utilisateur de soumettre à nouveau l'étape spécifique qui a échoué (par exemple, reprendre le selfie) sans relancer tout le processus.
  • In Review, signalé pour examen de conformité. Ouvrez le dossier dans la console, consultez tous les signaux, décidez d'approuver ou de refuser.
  • In Progress, l'utilisateur est en cours de processus.
  • Not Started, lien envoyé, l'utilisateur ne l'a pas encore ouvert. Envoyez un rappel s'il reste trop longtemps sans action.
  • Abandoned, l'utilisateur a ouvert le lien mais n'a pas terminé à temps. Relancez ou expirez.
  • Expired, le lien de session a expiré. Créez une nouvelle session.

Un webhook signé se déclenche à chaque changement de statut, afin que votre base de données reste toujours synchronisée. Les sessions abandonnées et refusées sont gratuites.

Où sont stockées mes données client et comment sont-elles protégées ?

Les données de production sont traitées et stockées par défaut dans l'Union Européenne, sur Amazon Web Services. Les contrats d'entreprise peuvent demander des régions alternatives pour les juridictions dont les régulateurs l'exigent.

Chiffrement partout. AES-256 au repos sur chaque base de données, stockage d'objets et sauvegarde. Transport Layer Security 1.3 en transit sur chaque appel API, webhook et session de la console Business. Les données biométriques sont chiffrées sous une Customer Master Key distincte.

La rétention est sous votre contrôle. La rétention par défaut est indéfinie (illimitée), sauf si vous configurez une durée plus courte, entre 30 jours et 10 ans par application, et vous pouvez supprimer n'importe quelle session individuelle à tout moment depuis le tableau de bord ou l'API.

Certifications : SOC 2 Type 1 (audit Type 2 en cours), ISO/IEC 27001:2022, iBeta Level 1 PAD, et une attestation publique du Tesoro / SEPBLAC / CNMV espagnol que la vérification d'identité à distance de Didit est plus sûre qu'une vérification en personne. Rapport complet sur /security-compliance.

Didit est-il conforme pour mon secteur d'activité ?

Didit est conforme par défaut aux régulateurs importants pour l'infrastructure d'identité :

  • GDPR + UK GDPR, séparation contrôleur / processeur, accord de traitement des données complet publié, autorité de contrôle principale désignée (AEPD espagnole).
  • AMLD6 + EU AML Single Rulebook, plus de 1 300 listes de sanctions, de personnes politiquement exposées et de médias défavorables examinées en temps réel.
  • eIDAS 2.0, aligné sur le portefeuille d'identité numérique de l'UE ; prêt pour l'identité réutilisable.
  • MiCA (Markets in Crypto-Assets), prêt pour les rampes d'accès crypto, les échanges et les dépositaires.
  • DORA, Digital Operational Resilience Act, résilience opérationnelle des services financiers de l'UE.
  • BIPA, CUBI, Washington HB 1493, CCPA / CPRA, confidentialité biométrique américaine (Illinois, Texas, Washington) et confidentialité des consommateurs californiens.
  • UK Online Safety Act, obligations de contrôle de l'âge et de sécurité des enfants.
  • FATF Travel Rule, données de l'expéditeur et du bénéficiaire sur les transferts crypto, interopérable IVMS-101.

Mémo détaillé, chaque certificat, chaque lettre de régulateur : /security-compliance.

À quelle vitesse puis-je intégrer et commencer à vérifier les utilisateurs ?
  • 60 secondes pour un compte sandbox sur business.didit.me, pas de carte de crédit.
  • 5 minutes pour une vérification fonctionnelle via Claude Code, Cursor, ou tout agent de codage via notre serveur Model Context Protocol (MCP).
  • Un week-end pour une intégration prête pour la production avec vérification de webhook signé, tentatives de réessai et un flux de remédiation lorsqu'un utilisateur est refusé.

Trois chemins d'intégration, choisissez celui qui correspond à votre stack :

  • Intégrez nativement avec nos SDK Web, iOS, Android, React Native ou Flutter.
  • Redirigez l'utilisateur vers la page de vérification hébergée, zéro SDK.
  • Envoyez un lien par e-mail, SMS, WhatsApp ou tout autre canal, zéro travail frontal.

Même tableau de bord, même facturation, même prix par succès pour les trois. Guide étape par étape sur docs.didit.me/integration/integration-prompt.

Infrastructure pour l'identité et la fraude.

Une seule API pour le KYC, le KYB, la surveillance des transactions et le screening de portefeuilles. Intégration en 5 minutes.

Demande à une IA de résumer cette page