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 propistatus —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_datedel document ha vençut després de la verificació. El monitoratge continu de caducitat de Didit canvia l’informe deApprovedaExpired, afegeix una advertènciaDOCUMENT_EXPIREDi 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 matriuid_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/retornaid_verifications[]al nivell superior. Consulta Recuperar la decisió de la sessió. - Webhooks — els payloads de
session.status.updatedinclouen la mateixa matriuid_verifications[]un cop el pas ha generat dades. Consulta Webhooks. - API d’OCR autònoma — l’enviament directe de documents retorna un objecte
id_verificationsingular 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ísdocument_number— el número de targeta
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_numberconté 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.
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:
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:
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àmetrepreferred_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(ifull_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=latinperò 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 exposafirst_name_latin,last_name_latin,middle_name_latin,full_name_latin,place_of_birth_latiniaddress_latincom 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 necessitastatus, 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
- Advertències de la verificació d’identitat: enumeració completa de les advertències, causes i resolució.
- Monitoratge de documents: com Didit detecta manipulacions i duplicats entre sessions.
- Documents admesos: quins tipus de documents i països estan coberts.
- Subtipus de documents: llista completa de codis de
document_subtype, inclosa la detecció de si un permís de conduir dels EUA és comercial o estàndard. - Webhooks: escolta
session.status.updatedper rebre l’informe. - Models de dades — Verificació d’identitat: esquema canònic amb tots els camps.