Saltar al contingut principal

Visió general

L’informe de verificació d’identitat recull tot el que Didit ha extret i validat a partir d’un document d’identitat emès pel govern: passaports, documents d’identitat, permisos de conduir i permisos de residència. Agrupa els camps biogràfics i del document obtinguts mitjançant OCR, URL signades dels fitxers multimèdia capturats, dades d’adreça analitzades i geolocalitzades, puntuacions de qualitat d’imatge per cada cara, contingut de la MRZ, desglossaments de diversos sistemes d’escriptura (llatí / no llatí) i coincidències de documents entre sessions. L’informe es genera després que l’usuari completi el pas de captura de documents en un flux de treball (o cridi l’endpoint d’OCR autònom). Didit identifica el tipus de document, executa l’OCR, valida la MRZ / codi de barres / codi QR, analitza l’adreça, detecta manipulacions (captura de pantalla, còpia impresa, manipulació del retrat) i compara el document amb tots els altres documents capturats a la teva aplicació. Cada informe té el seu propi status —independent de l’estat general de la sessió— que reflecteix com s’ha resolt exclusivament el pas d’identitat:
  • Aprovada — document reconegut, tots els camps obligatoris extrets i no s’ha activat cap advertència que encamini el resultat al rebuig.
  • En revisió — s’han activat una o més advertències i el teu flux de treball les encamina a revisió.
  • Rebutjada — s’ha activat una condició de rebuig automàtic (document no compatible, document caducat, retrat absent, coincidència amb la llista de bloqueig, error d’edat adaptativa) o s’ha activat una advertència l’acció configurada de la qual és Rebutjar (les edats mínima i màxima tenen Rebutjar com a acció predeterminada).
  • Caducada — la expiration_date del document ha vençut després de la verificació. El monitoratge continu de caducitat de Didit canvia l’informe de Approved a Expired, afegeix una advertència DOCUMENT_EXPIRED i passa una sessió aprovada a l’estat de sessió Kyc Expired.
  • No finalitzada — l’usuari no ha completat mai el pas de captura.

On apareix a les respostes de l’API

L’informe de verificació d’identitat s’inclou dins de la matriu id_verifications[] —sempre una matriu JSON, mai un objecte id_verification singular. Apareixen diverses entrades quan un flux de treball executa més d’un pas de document (per exemple, un document d’identitat principal més un pas d’escalada).
  • API de decisió de sessió — GET /v3/session/{sessionId}/decision/ retorna id_verifications[] al nivell superior. Consulta Recuperar la decisió de la sessió.
  • Webhooks — els payloads de session.status.updated inclouen la mateixa matriu id_verifications[] un cop el pas ha generat dades. Consulta Webhooks.
  • API d’OCR autònoma — l’enviament directe de documents retorna un objecte id_verification singular amb els mateixos camps. Consulta API d’OCR autònoma.
Llegeix response.id_verifications[0] i recorre la matriu. L’estructura singular id_verification només existeix a l’API d’OCR autònoma; no existeix a l’endpoint de decisió v3.

Esquema

L’esquema canònic camp per camp es troba a la pàgina de referència de Models de dades. Els camps següents provenen directament d’IDVerificationV3Serializer, que estén IDVerificationV2Serializer i afegeix node_id, la matriu matches[] entre sessions i la matriu document_selfie_face_matches[] de Silent Capture.

Camps de primer nivell

issuing_state és sempre a nivell de país, mai subnacional. Per a cada tipus de document, inclosos els permisos de conduir emesos per un estat o província (Austràlia, els Estats Units, el Canadà), issuing_state i issuing_state_name informen del país (per exemple AUS / Australia), no de l’estat. El valor subnacional, quan el document en conté un, està disponible per separat a parsed_address.region (amb extra_fields.state com a alternativa en alguns tipus de document). El resum de la sessió de la Business Console ho mostra com una fila Regió a sota d’Estat emissor quan està present.
Permisos de conduir que contenen dos números (Austràlia). Els permisos australians imprimeixen tant un número de permís, que identifica l’habilitació per conduir del titular i es manté igual quan se substitueix una targeta, com un número de targeta, que identifica la targeta física i canvia amb cada reemissió. Per a aquests permisos, Didit sempre assigna els números de la mateixa manera:
  • personal_number — el número de permís
  • document_number — el número de targeta
Això s’aplica a tots els estats i territoris australians (NSW, VIC, QLD, WA, SA, TAS, ACT, NT). En algunes variants, el número de targeta només està imprès al dors, de manera que només es llegeix quan es captura el dors del permís. Quan no es pot llegir cap número de targeta, el número de permís s’informa tant a document_number com a personal_number, de manera que document_number sempre porta un identificador un cop finalitzada la verificació. personal_number és el número de permís en ambdós casos. En altres tipus de document, document_number continua sent el número principal obtingut per OCR i pot ser ell mateix un identificador a nivell de titular.
El CUIL argentí és extra_fields.tax_number, mai personal_number. Els documents argentins imprimeixen el CUIL —l’identificador d’11 dígits en què es basen l’AFIP, l’ANSES i les agències d’informació creditícia— en un lloc diferent a cada document, i el DNI n’imprimeix un segon d’11 dígits al costat:
  • a la llicència de conduir, el CUIL és el que conté personal_number;
  • al DNI, personal_number conté el número de trámite, que identifica la sol·licitud de la targeta i no és un identificador del titular. El CUIL del DNI es llegeix del seu propi camp imprès.
Per tant, personal_number no és un CUIL fiable per a l’Argentina: en un DNI és un número d’11 dígits que silenciosament no retornarà cap resultat de cap registre. Llegeix extra_fields.tax_number en el seu lloc. Didit només l’informa quan el valor es valida com un CUIL real (prefix de persona més el dígit de control mòdul 11), en dígits canònics sense separadors (27111111117), independentment del document argentí que hagi presentat el titular. Quan no s’ha pogut llegir el CUIL de la targeta, la clau és absent en lloc d’estar emplenada amb un número que no és un CUIL —captura la llicència de conduir com a segon document, o recopila el CUIL mitjançant una resposta d’un qüestionari o a les metadata de la sessió, per donar cobertura a aquests usuaris.

Puntuacions de qualitat de la imatge

front_image_quality_score i back_image_quality_score cadascun retorna:
Utilitza overall_score com una comprovació ràpida d’idoneïtat: les puntuacions per sobre de 70 generalment indiquen una captura prou bona per a una verificació fiable.

Puntuacions de prova de vida del document

document_liveness informa del que ha mesurat la comprovació de prova de vida del document, tant si ha generat una advertència com si no. Només hi ha una advertència quan una puntuació ha caigut per sota d’un dels llindars del flux de treball, de manera que abans d’aquest camp un document aprovat no contenia cap evidència de prova de vida; el camp és la manera d’auditar una sessió que ha passat. És null quan la comprovació no s’ha executat (per exemple, un mètode sense document, o una caiguda del model registrada als registres de la sessió). Conté un objecte per tipus de frau —portrait_replace, printed_copy i screen_replay—, cadascun amb:
Per a documents més antics sense evidència d’avaluació desada, les puntuacions emmagatzemades continuen sent visibles, però tant els llindars com bucket són null. La configuració actual del flux de treball mai s’utilitza per reconstruir un resultat històric. El mateix s’aplica a una captura l’avaluació del document de la qual encara no s’ha completat. La Business Console mostra les mateixes tres files al bloc Prova de vida del document de la secció de Verificació d’identitat de la sessió.

Coincidències entre sessions

matches[] llista fins a 5 altres documents de la teva aplicació que coincideixen amb aquest: mateixa data de naixement, mateix país emissor i un nom complet molt similar. Els documents a la llista de bloqueig requereixen a més una coincidència exacta del número de document. Les sessions que pertanyen al mateix usuari (mateix vendor_data) s’exclouen. Cada entrada inclou session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted (true quan el document s’ha afegit a la teva llista de bloqueig), api_service i un front_image_url signat.

Valors d’estat

Documents amb múltiples sistemes d’escriptura (llatí / no llatí)

Alguns documents — kirguisos, kazakhs, russos, japonesos, coreans, xinesos, àrabs, tailandesos i d’altres — inclouen el nom, l’adreça o el lloc de naixement del titular tant en una transliteració llatina com en el sistema d’escriptura local. Pots triar quin sistema d’escriptura omple la resposta de nivell superior mitjançant el paràmetre preferred_characters del flux de treball (o de l’API independent): Els valors del sistema d’escriptura alternatiu es troben dins d’extra_fields sota claus amb sufix: first_name_non_latin, last_name_non_latin, middle_name_non_latin, full_name_non_latin, address_non_latin, place_of_birth_non_latin (o les variants coincidents _latin).

Quan apareixen els camps del sistema d’escriptura alternatiu

  • Només quan ambdós sistemes d’escriptura són presents efectivament al document. Si un camp d’OCR etiquetat nominalment com a “Surname-Kyrgyz (Cyrillic)” s’extreu com a text en escriptura llatina (homòglifs o una transliteració llatina), no es considera un camp alternatiu no llatí i aquesta clau s’omet.
  • full_name_non_latin (i full_name_latin) sempre es reconstrueixen a partir dels components individuals de nom de pila, segon nom i cognom quan els components corresponents estan disponibles; el camp sense processar “Full Name” de l’OCR s’ignora per coherència.
  • Quan preferred_characters=latin però el document conté únicament text no llatí (de manera que els camps de nivell superior acaben sent no llatins), Didit executa una passada de transliteració i exposa first_name_latin, last_name_latin, middle_name_latin, full_name_latin, place_of_birth_latin i address_latin com a alternativa llatina.
last_name_non_latin no apareix perquè el camp “Surname (Cyrillic)” del document es va retornar amb caràcters llatins en aquesta mostra; no hi havia cap cognom no llatí autèntic per extreure.

Exemples

Aprovat: document d’identitat espanyol sense problemes (tots els camps)

En revisió: QR no detectat en un document que n’hauria de tenir

Abreujat: una resposta real sempre inclou el conjunt complet de camps que es mostra a dalt.

Nota de seguretat

Les URL signades que es retornen per a les imatges i vídeos dels documents són temporals: caduquen després d’un període de validesa limitat. Tracta-les com a recursos de curta durada: baixa el que necessitis sense demora i no les emmagatzemis en memòria cau ni les exposis públicament. Habitualment, la teva aplicació només necessita status, un grapat de camps biogràfics i les advertències; emmagatzema el mínim possible per reduir la superfície d’atac en cas de qualsevol futura bretxa de seguretat.

Relacionat

Darrera modificació el 7 de novembre del 2026