Vai al contenuto principale

Panoramica

Il report di confronto facciale acquisisce un confronto biometrico 1:1 tra il selfie dal vivo acquisito durante il rilevamento della vitalità e un’immagine di riferimento, più comunemente la fototessera estratta dal documento d’identità. Restituisce un singolo punteggio di somiglianza da 0 a 100, URL firmati per le due immagini confrontate, la sessione di origine per l’immagine di riferimento ed eventuali avvisi generati dal confronto. Il report viene generato dopo che l’utente ha completato sia il passaggio di rilevamento della vitalità sia quello del documento in un workflow (oppure, per i workflow basati su fototessera come l’autenticazione biometrica, solo dopo la vitalità), o direttamente tramite l’API autonoma di confronto facciale quando fornisci tu stesso due immagini facciali arbitrarie. Ogni report include un proprio status, indipendente dallo stato generale della sessione, che riflette l’esito del solo passaggio di confronto facciale:
  • Approvato — score è superiore alla soglia di revisione e non è scattato alcun avviso di rifiuto automatico.
  • In revisione — score è compreso tra la soglia di rifiuto e quella di revisione, oppure non è stato possibile calcolare alcun punteggio e face_match_not_computed_action è impostato su REVIEW.
  • Rifiutato — score è pari o inferiore alla soglia di rifiuto, è scattato NO_REFERENCE_IMAGE, oppure non è stato possibile calcolare alcun punteggio e face_match_not_computed_action è impostato su DECLINE.
  • Nuova richiesta di invio — un revisore ha richiesto che l’utente invii nuovamente questo passaggio dalla console.
  • Non completato — il passaggio di confronto facciale non ha ancora prodotto un risultato (incluso il caso in cui l’utente stia ritentando un’acquisizione non riuscita).

Dove compare nelle risposte API

Il report di confronto facciale è incluso all’interno dell’array face_matches[] — sempre un array JSON, mai un singolo oggetto face_match. È null finché almeno un passaggio di confronto facciale non ha prodotto dati, e compaiono più voci quando un workflow esegue il confronto facciale più di una volta. Anche un workflow di Adaptive Age Verification lo compila quando viene eseguito il fallback con verifica dell’identità: tale voce riporta il nodo di stima dell’età come proprio node_id, poiché il workflow non include un nodo di confronto facciale dedicato.
  • API di decisione della sessione — GET /v3/session/{sessionId}/decision/ restituisce face_matches[] al livello principale. Vedi Recupera la decisione della sessione.
  • Webhook — i payload di session.status.updated includono lo stesso array face_matches[] una volta che il passaggio ha prodotto dati. Vedi Webhook.
  • API autonoma di confronto facciale — per confronti diretti 1:1, vedi API autonoma di confronto facciale.
Leggi response.face_matches[0] e itera sull’array: la struttura singolare face_match a cui facevano riferimento alcuni vecchi tutorial non esiste sull’endpoint di decisione v3.

Schema

Lo schema canonico campo per campo si trova nella pagina di riferimento Modelli di dati. I campi sottostanti rispecchiano tale schema canonico.

Valori di stato

I fallimenti dovuti a bassa somiglianza prevedono nuovi tentativi prima che lo stato diventi definitivo: l’utente ha a disposizione fino a face_match_max_attempts acquisizioni (3 per impostazione predefinita), e viene applicato solo il punteggio dell’ultimo tentativo. Le regole di stato personalizzate configurate sul nodo del workflow possono modificare ulteriormente lo stato risultante, combinandosi con lo stato derivato dal punteggio secondo la precedenza Declined > In Review > Approved.

Esempi

Approvato — corrispondenza netta

In revisione — somiglianza al limite

Rifiutato — nessuna immagine di riferimento con cui effettuare il confronto

Nota sulla sicurezza

Gli URL firmati per source_image e target_image costituiscono dati biometrici e scadono dopo un breve intervallo di validità. Trattali come temporanei: non memorizzarli nella cache né esporli pubblicamente. In genere la tua applicazione ha bisogno solo di status e score: memorizza la minor quantità possibile di informazioni per ridurre al minimo i dati biometrici sui tuoi server.

Correlati

Ultima modifica il 7 novembre 2026