Vai al contenuto principale

Panoramica

Ogni report per funzionalità segue la forma del serializzatore V3 definita in service-didit-verification. Lo stesso oggetto compare in tre punti, quindi lo schema che vedi qui è l’unica fonte di verità per tutti e tre:
  • GET /v3/session/{sessionId}/decision/: ogni funzionalità viene restituita come array al plurale (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], poa_verifications[], phone_verifications[], email_verifications[], aml_screenings[], ip_analyses[], database_validations[], questionnaire_responses[], signatures[], bank_verifications[] (vedi Metodi di verifica bancaria), e gli equivalenti KYB registry_checks[], document_verifications[], key_people_checks[]).
  • Payload dei webhook (status.updated, data.updated): stessa forma all’interno dell’envelope decision.
  • API standalone: le risposte con un solo oggetto (Face Search, Age Estimation, Biometric Authentication) riutilizzano lo stesso insieme di campi.
V3 ha introdotto i workflow multi-istanza: ogni oggetto funzionalità contiene un node_id che collega il report al nodo del grafo del workflow che lo ha prodotto. Gli endpoint V2 (al singolare kyc, face, aml, ecc.) restano retrocompatibili, ma restituiscono solo la prima istanza.

Campi comuni

Ogni oggetto report espone i seguenti campi: I campi media (portrait_image, front_image, document_file, …) sono URL prefirmati con un periodo di validità limitato: scaricali subito invece di salvare l’URL. Gli esempi li mostrano come https://<media-host>/....

Oggetto avviso

Restituito in ogni array warnings[]. Schema da logs/serializers/log.py:8-65 (LogV3Serializer).

Oggetti report

Le sezioni successive descrivono ciascun oggetto di report per funzionalità. Il testo dei titoli H3 è volutamente stabile, così che altre pagine possano collegarvisi direttamente.

Verifica dell’identità

Viene restituito per ogni documento KYC/ID inviato da un utente. Compare come id_verifications[] in GET /v3/session/{sessionId}/decision/ e all’interno del campo kyc delle risposte V2. Fonte: kyc/serializers/kyc.py:383-414 (IDVerificationV3Serializer, che estende IDVerificationV2Serializer in kyc/serializers/kyc.py:320-380).
Lo stesso oggetto con un metodo diverso dal documento. Cambiano solo le chiavi specifiche del metodo: tutto ciò che di norma viene compilato dalla lettura del documento viene invece compilato dal record del registro o dagli attributi del wallet, e le chiavi che non si applicano sono null.

Verifica NFC

Restituito per ogni lettura del chip su un documento d’identità: un chip ePassport ICAO 9303 o eID, oppure una lettura della My Number Card giapponese tramite JPKI (chip_protocol: "jpki"). Compare come nfc_verifications[] in GET /v3/session/{sessionId}/decision/ (uno per record KYC principale). Fonte: kyc/serializers/epassport.py:121-139 (NFCV3Serializer, estende NFCV2Serializer in kyc/serializers/epassport.py:83-118).

Rilevamento della vitalità

Restituito per ogni sessione di rilevamento della vitalità. Compare come liveness_checks[] in GET /v3/session/{sessionId}/decision/. Fonte: face/serializers/face.py:301-320 (LivenessV3Serializer, estende LivenessV2Serializer in face/serializers/face.py:216-298).

Confronto facciale

Restituito per ogni confronto facciale (tipicamente il volto dell’utente rilevato durante il controllo di vitalità, confrontato con il ritratto sul documento). Compare come face_matches[] in GET /v3/session/{sessionId}/decision/. Fonte: face/serializers/face.py:367-389 (FaceMatchV3Serializer, estende FaceMatchV2Serializer in face/serializers/face.py:323-364).

Ricerca facciale

Restituito dall’API autonoma di Ricerca facciale (POST /v3/face-search/). Ricerca facciale non compare mai come array plurale in /v3/session/{sessionId}/decision/. Quando viene salvata con save_api_request=true, la sessione compare lì come voce FACE_SEARCH in features[], insieme a un elemento liveness_checks[] che contiene le matches salvate. Fonti: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer, che incapsula FaceSearchDetailsSerializer); i dizionari delle corrispondenze sono costruiti in face/utils/utils.py:869-884. Risposta di primo livello: Oggetto face_search:

Oggetto di corrispondenza di Ricerca facciale

Screening AML

Restituito per ogni entità sottoposta a screening. Compare come aml_screenings[] in GET /v3/session/{sessionId}/decision/, sia per le sessioni KYC sia per quelle KYB. Fonte: aml/serializers/aml.py:63-85 (AMLV3Serializer, che estende AMLV2Serializer in aml/serializers/aml.py:28-60).

Analisi IP

Restituito per ogni posizione di rete acquisita. Compare come ip_analyses[] in GET /v3/session/{sessionId}/decision/ sia per le sessioni KYC sia per quelle KYB. Fonte: kyc/serializers/location.py:196-243 (IPAnalysisSerializerV3).

Verifica della posizione

Restituito per ogni passaggio di Verifica della posizione. Compare come geolocation_checks[] in GET /v3/session/{sessionId}/decision/: un elemento per passaggio, corrispondente al tentativo accettato. geolocation_attempts[] elenca ogni tentativo di ogni passaggio, dal più vecchio al più recente. Entrambi sono null per un workflow che non include il passaggio. Fonte: GeolocationDecisionSerializer. Tutti i campi e gli esempi sono nel report di verifica della posizione.

Prova di residenza

Restituito per ogni documento di indirizzo inviato. Compare come poa_verifications[] in GET /v3/session/{sessionId}/decision/. Fonte: poa/serializers/poa.py:212-227 (POAV3Serializer, estende POAV2Serializer in poa/serializers/poa.py:173-209).

Verifica telefonica

Restituito per ogni tentativo di verifica telefonica. Compare come phone_verifications[] in GET /v3/session/{sessionId}/decision/ per le sessioni KYC e KYB. Fonte: phone/serializers/phone.py:251-266 (PhoneV3Serializer, estende PhoneV2Serializer in phone/serializers/phone.py:103-248).

Verifica email

Restituito per ogni tentativo di verifica email. Compare come email_verifications[] in GET /v3/session/{sessionId}/decision/ per le sessioni KYC e KYB. Fonte: email_verification/serializers/email.py:149-164 (EmailV3Serializer, estende EmailV2Serializer in email_verification/serializers/email.py:38-146).

Validazione su database

Restituito per ogni ricerca in database eseguita sui dati inviati dall’utente. Compare come database_validations[] in GET /v3/session/{sessionId}/decision/. Fonte: database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer, estende DatabaseValidationV2Serializer).

Risposta del questionario

Restituita per ogni invio di un questionario. Compare come questionnaire_responses[] in GET /v3/session/{sessionId}/decision/ sia per le sessioni KYC sia per quelle KYB. Fonte: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, estende QuestionnaireResponseSerializer in questionnaires/serializers/questionnaire.py:520-588).

Firma elettronica

Restituita per ogni firmatario di un passaggio di Firma elettronica. Compare come signatures[] in GET /v3/session/{sessionId}/decision/ sia per le sessioni KYC sia per quelle KYB, solo quando il workflow include il passaggio. A differenza degli altri oggetti del report, il suo status indica la fase di firma e l’esito si trova in verdict, e gli elementi di warnings[] sono { code, node_id } anziché oggetti avviso. Il report Firma elettronica contiene un esempio completo e tutti i campi annidati.

Stima dell’età

Restituito dalla API autonoma di Stima dell’età (POST /v3/age-estimation/). La risposta contiene un sottoinsieme della struttura di Liveness check all’interno di un contenitore age_estimation: status, method, score, age_estimation, warnings. Include inoltre un blocco user_image per il rilevamento del volto, disponibile solo nella modalità autonoma; non include reference_image, video_url, matches, face_quality o face_luminance. Nelle sessioni workflow non esiste un array separato: l’età stimata compare in liveness_checks[].age_estimation in GET /v3/session/{sessionId}/decision/. Fonte: apis/serializers/age_estimation.py:50-55 (AgeEstimationResponseSerializer), contenitore costruito in apis/views/age_estimation.py:138-174.

Autenticazione biometrica

L’autenticazione biometrica esegue la stessa pipeline di Rilevamento della vitalità + Confronto facciale usata nel KYC standard, ma configurata per confrontare il volto acquisito con l’immagine di riferimento di un utente esistente, invece che con un ritratto del documento appena sottoposto a OCR. Non esiste un serializzatore dedicato: GET /v3/session/{sessionId}/decision/ restituisce gli oggetti standard Rilevamento della vitalità e Confronto facciale in liveness_checks[] e face_matches[]. Il workflow della sessione è configurato con workflow_type = "biometric_authentication" (WorkflowTypeChoices, common/config/choices.py:636).

Registro KYB

Restituito per ogni azienda confermata dal registro in un workflow KYB. Compare come registry_checks[] in GET /v3/session/{sessionId}/decision/ per le sessioni aziendali. Fonte: kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer).

Oggetto azienda

Da kyb/serializers/kyb.py:220-321 (KYBCompanyResponseSerializer).

Documento KYB

Restituito per ogni nodo che raccoglie documenti di supporto KYB. Compare come document_verifications[] in GET /v3/session/{sessionId}/decision/ per le sessioni aziendali: una voce per ogni node_id, con items[] che elenca ciascun documento caricato. Fonte: kyb/serializers/kyb.py:1053-1068 (DocumentVerificationV3Serializer); ogni elemento segue kyb/serializers/kyb.py:811-851 (KYBDocumentResponseSerializer).

Oggetto voce documento KYB

Persona chiave KYB

Restituita per ogni nodo Persone chiave in un workflow KYB. Compare come key_people_checks[] in GET /v3/session/{sessionId}/decision/ per le sessioni aziendali. Fonte: kyb/serializers/kyb.py:967-1050 (KeyPeopleCheckV3Serializer).

Campi a livello di decisione

Queste chiavi si trovano accanto agli array delle funzionalità in GET /v3/session/{sessionId}/decision/ e all’interno del campo decision di un webhook. Per capire come leggerli, consulta Recupera sessione.

Consenso biometrico

Ogni decisione di Verifica degli utenti e ogni webhook di sessione contiene un unico oggetto biometric_consent (non un array): se la sessione richiedeva un consenso biometrico esplicito, il motivo e le prove della risposta. È null quando la sessione non è mai stata valutata, ad esempio un workflow senza acquisizione del volto. Fonte: BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). Quando compare il passaggio e cosa significa ogni caso è spiegato in Consenso biometrico. I campi senza un valore registrato sono null, mai una stringa vuota. Una sessione nell’Illinois servita da un SDK nativo precedente alla 4.10.0, che ha acquisito il selfie senza il passaggio:
Una persona con una VPN che esce al di fuori degli Stati Uniti, che ha acconsentito nel flusso ospitato:

Riferimento agli enum di stato

Due spazi di valori distinti condividono il nome di campo status. Ogni oggetto report per funzionalità in questa pagina usa l’enum a livello di funzionalità; il campo status di primo livello della sessione padre usa l’enum più ampio della sessione.

Stati a livello di funzionalità

Usati dal campo status di ogni oggetto report. Fonte: common/config/choices.py:343-348 (FeatureStatusChoices). La verifica telefonica, la verifica email e la verifica dell’identità possono inoltre restituire Expired quando il loro passaggio scade (PhoneStatusChoices in common/config/choices.py:377-382, EmailStatusChoices in common/config/choices.py:434-439).

Stati a livello di sessione

Usati dal campo status di primo livello della sessione padre. Fonte: common/config/choices.py:106-117 (StatusChoices).
I valori di sessione finali sono Approved, Declined, In Review, Expired, Kyc Expired e Abandoned. Una sessione può raggiungere la decisione complessiva mentre una singola funzionalità resta In Review.
Ultima modifica il 7 novembre 2026