> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Builder di workflow KYC senza codice > Crea flussi KYC senza codice con il builder visuale di Didit: ID, liveness, AML, NFC e logica condizionale. Paghi solo i passaggi completati. I Workflow orchestrati di Didit sono il modo più potente e flessibile per progettare e pubblicare percorsi di verifica dell'identità completi e articolati in più passaggi. Questa lezione della Didit Academy mostra come costruire un flusso di verifica nella console reale, dal modello al flusso pubblicato: come scegliere i controlli su ciascun nodo, come impostare regole e soglie, come gestire le diramazioni AML, come usare i nodi webhook e come ripristinare una versione precedente. [Crea il tuo primo flusso di verifica — Didit Academy](https://www.youtube.com/embed/7-nJ3JE20i4?rel=0\&playsinline=1) Questo percorso di integrazione ti permette di sfruttare tutta l'intelligenza della piattaforma Didit V2, creando sequenze di verifica sofisticate con il builder visuale senza codice. Definisci la logica una sola volta nella tua Business Console, e Didit gestisce l'intera esperienza rivolta all'utente, la gestione dello stato e i passaggi condizionali. Scegli questo percorso quando ti serve una soluzione completa dall'inizio alla fine per l'onboarding degli utenti (KYC), la verifica dell'età o la riautenticazione, e vuoi partire rapidamente con uno sforzo di sviluppo minimo, mantenendo al tempo stesso il massimo controllo sul processo. ## Metodi di identità per paese In Verifica dell'identità, apri **Paesi e metodi di identificazione consentiti** per configurare, per ciascun paese, l'acquisizione del documento, la ricerca senza documento e i wallet di identità digitale. **Impostazioni aggiuntive** contengono i sottotipi di documento, i tentativi di ricerca e le regole di fallback. La ricerca senza documento utilizza il prezzo del servizio Validazione su database della tua organizzazione. Ogni tentativo completato viene addebitato separatamente, inclusi i riscontri parziali e quelli senza corrispondenza: due tentativi completati significano due addebiti. Gli errori di formato e gli errori del provider che non restituiscono alcuna risposta non vengono addebitati. Se più servizi di database rispondono a un unico tentativo, i prezzi applicabili di tali servizi vengono sommati. Il valore predefinito è **un tentativo prima del fallback**, configurabile da uno a cinque. L'acquisizione del documento viene addebitata in aggiunta quando una ricerca completata ricorre al documento come fallback. Le applicazioni in produzione possono abilitare solo i wallet disponibili per la produzione. I wallet in attesa di lancio restano disabilitati. Le applicazioni in sandbox possono testare tutti i wallet del catalogo con risultati simulati; la disponibilità in sandbox non indica la disponibilità in produzione. Consulta [Test in sandbox](https://docs.didit.me/it/integration/sandbox-testing.md) per gli scenari di errore della ricerca e dei wallet. ## Gestione delle versioni dei workflow I workflow supportano la **gestione delle versioni delle bozze e delle pubblicazioni**. Questo significa che puoi modificare il tuo workflow in modo sicuro senza influire sulle sessioni attive: * Le **versioni bozza** sono completamente modificabili: aggiungi, rimuovi o ristruttura i nodi liberamente * **Pubblicare** una bozza crea una versione immutabile che le nuove sessioni utilizzeranno * Le **versioni precedenti** vengono conservate, così puoi ispezionare la configurazione esatta usata per qualsiasi sessione passata * Le **sessioni fanno sempre riferimento alla versione specifica** con cui sono state create, garantendo coerenza anche dopo la pubblicazione di aggiornamenti Per modificare un workflow pubblicato, crea una nuova bozza a partire dalla versione pubblicata, modificala e pubblicala quando è pronta. La cronologia delle versioni è disponibile tramite la Management API. *** ## Due modi per creare i workflow Didit offre **due approcci distinti** per creare i workflow di verifica, così puoi scegliere il livello di complessità più adatto alle tue esigenze: ![Didit workflow di verifica dell'identità con le modalità builder semplice e avanzata affiancate](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple-and-complex.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=07f4e97f94cb1179de16732573612b6e) ### 1. Modalità semplice: builder basato su modelli La **Modalità semplice** è ideale per iniziare rapidamente. Seleziona un modello predefinito, attiva o disattiva le funzionalità che ti servono, e sei pronto. ![Interfaccia del builder basato su modelli in modalità semplice per il workflow di verifica dell'identità di Didit](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=ebe4da7cf6549793629497fb36053fe2) **Ideale per:** * Configurazione e messa in produzione rapide * Flussi di verifica standard * Team che si avvicinano per la prima volta alla verifica dell'identità * Casi d'uso che rientrano in schemi comuni **Come funziona:** 1. Scegli un modello di workflow (KYC, verifica dell'età, ecc.) 2. Attiva o disattiva le funzionalità (Rilevamento della vitalità, Confronto facciale, Screening AML, ecc.) 3. Configura le impostazioni di base per ciascuna funzionalità 4. Pubblica e inizia a verificare *** ### 2. Modalità avanzata: builder visuale a grafo La **Modalità avanzata** sblocca tutta la potenza del motore di orchestrazione di Didit. Crea flussi di verifica complessi e condizionali con il nostro editor visuale a grafo, con nodi trascinabili, rami e logiche personalizzate. ![Builder visuale di workflow a grafo basato su nodi](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/node-based-workflow.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2c0997ab8bbb09dbf7c4cb26b201eced) **Ideale per:** * Percorsi di verifica complessi con più strade possibili * Logiche condizionali basate sui dati dell'utente o sui risultati della verifica * Regole di business personalizzate e diramazioni * Requisiti di compliance di livello enterprise **Funzionalità principali:** * **Editor visuale dei nodi**: trascina, rilascia e collega i nodi su una tela infinita * **Connessioni intelligenti**: trascina da un punto di collegamento di un nodo fino a uno spazio vuoto per creare e collegare subito un nuovo nodo * **Rami condizionali**: instrada gli utenti in base ai dati estratti, allo stato della verifica, al paese, al tipo di documento, al [sottotipo di documento](https://docs.didit.me/it/core-technology/id-verification/document-subtypes-id-verification.md), alla data di emissione, all'età, ai percorsi della risposta JSON del webhook o a regole personalizzate * **Automazione delle azioni**: aggiungi tag, imposta metadati o instrada alla revisione manuale in base agli esiti del flusso * **Scorciatoie da tastiera**: Annulla (Ctrl/Cmd+Z), Ripeti (Ctrl/Cmd+Maiusc+Z), Elimina (Canc/Backspace) * **Zoom e panoramica**: naviga nei flussi complessi con lo zoom tramite scroll e lo spostamento trascinando #### Tipi di nodo del builder a grafo | Tipo di nodo | Colore icona | Descrizione | Esempi | | - | - | - | - | | **Nodi di funzionalità** | Blu | Controlli di verifica che elaborano i dati dell'utente | Verifica dell'identità (OCR), Liveness, Face Match, NFC, AML, Verifica telefonica/Verifica email, Questionario, Prova di residenza, Document AI, Validazione su database, Analisi dispositivo e IP, Stima dell'età | | **Nodi di diramazione** | Viola | Instradamento condizionale in base a dati o risultati | Instradamento per paese, punteggio di rischio, tipo di documento, sottotipo di documento, età, data di emissione, mesi dalla data di emissione, stato della verifica | | **Nodi azione** | Ambra | Trigger di automazione che modificano i dati della sessione o dell'utente | Aggiungi tag, Rimuovi tag, Imposta metadati, Aggiungi nota di revisione | | **Nodi webhook** | Ciano | Richieste HTTP che possono trasferire dati ai rami successivi | Invia i dati della sessione al tuo server, analizza le risposte JSON, dirama in base a percorsi come `category`, `status` o `tags.0` | | **Nodi di stato** | Verde/Rosso/Ambra | Esiti finali che concludono il flusso di verifica | Approvata, Rifiutata, In revisione | #### Categorie di funzionalità dei nodi **Funzionalità interattive con l'utente** (possono avviare un workflow): * Verifica dell'identità (OCR) * Rilevamento della vitalità (Liveness Detection) * Confronto facciale (Face Match) * Stima dell'età * Verifica telefonica * Verifica email * Questionario * Prova di residenza * Document AI * NFC / ePassport **Funzionalità solo backend** (vengono eseguite automaticamente, senza interazione con l'utente): * Screening AML (richiede prima un passaggio di Verifica dell'identità, Registro delle imprese KYB o Document AI, vedi [Entità sottoposta a screening](#entità-sottoposta-a-screening)) * Validazione su database (richiede prima l'OCR) * Analisi dispositivo e IP > **Nota:** le funzionalità solo backend sono contrassegnate da un indicatore specifico nel builder e vengono eseguite automaticamente, senza interazione con l'utente, una volta soddisfatte le dipendenze. La prima scheda di configurazione di ogni nodo funzione si apre con il controllo **Motore di verifica**: esegui il controllo con il motore di Didit oppure passa a un provider di terze parti che colleghi da [Marketplace](https://docs.didit.me/it/console/marketplace.md), con fallback automatico su Didit se quel provider non è disponibile. #### Entità sottoposta a screening Lo Screening AML di solito ricava il soggetto da sottoporre a screening dal passaggio che lo precede: la persona che un passaggio **Verifica dell'identità** ha ricavato da un documento, oppure l'azienda restituita da un passaggio **registro delle imprese KYB**. Alcuni flussi non hanno né l'uno né l'altro. Un flusso costruito interamente su **Document AI**, con documenti non standardizzati come un certificato fiscale o un atto costitutivo notarile, contiene già nome, data di nascita, numero del documento e paese, ma sotto le tue chiavi di campo personalizzate. La scheda **Avanzate** del nodo AML è dove puoi indicare a quali chiavi fare riferimento per lo screening: * **Tipo di entità**: sottoponi a screening una **persona**, oppure l'**azienda** indicata in un documento caricato. Un nodo azienda cerca nei registri delle aziende e non tra le persone. * **Origini dei campi**: associa ciascuno dei quattro input di screening (nome, data di nascita, paese, numero del documento) a un campo di Document AI, a una risposta del questionario o a un valore che invii alla creazione della sessione (`expected_details` / `metadata`). Un campo di Document AI che hai già chiamato `full_name` viene riconosciuto automaticamente. * **Dati di screening incompleti**: cosa succede quando lo screening viene eseguito con dati identificativi incompleti. La revisione è l'impostazione predefinita; scegli *No action* solo quando il flusso contiene consapevolmente soltanto un nome. Due cose vale la pena sapere prima di affidarti a questo flusso. Senza un passaggio di Verifica dell'identità o di KYB Registry, il **nome è obbligatorio**: il workflow non può essere pubblicato finché non viene inserito un nome, perché non esiste ricerca senza un nome. E la precisione dello Screening AML dipende direttamente da quanti identificativi fornisci: uno screening basato solo sul nome è ciò che genera il volume di falsi positivi di cui si lamentano i revisori, quindi associa la data di nascita e il paese ogni volta che il documento li riporta. #### Come leggere le condizioni dei rami sui dati di sessione **Quale record legge una condizione.** Una condizione di ramo è associata al nodo della funzionalità da cui è stata creata e legge il risultato di quel nodo. Quando un singolo nodo ha prodotto più record, la condizione legge quello **più recente**. Questo conta soprattutto per **Analisi dispositivo e IP**: Didit registra un'osservazione per ogni dispositivo e indirizzo da cui una sessione viene aperta, quindi un utente che cambia telefono o rete a metà sessione lascia più record sullo stesso nodo. Una regola come `IP COUNTRY is in [...]` viene quindi valutata rispetto all'osservazione **più recente**, cioè lo stesso record mostrato per primo nel pannello Analisi dispositivo e IP della sessione e nell'array `ip_analyses` del payload della decisione. Le sessioni con più di un'osservazione riportano anche l'avviso `MULTIPLE_DEVICES_IN_SESSION`, che segnala di esaminare l'elenco completo invece del solo esito del ramo. **Valori dei paesi.** Le condizioni sui paesi vengono confrontate sul paese stesso, non sulla notazione. Scegli i paesi dal selettore dei campi e Didit normalizza entrambi i lati del confronto, quindi una regola scritta in ISO 3166-1 alpha-3 (`UKR`) corrisponde comunque a un valore acquisito in alpha-2 (`UA`). **Valori mancanti, valori vuoti e confronti negativi.** Un campo **senza alcun valore** (il documento non lo riporta, la chiave dei metadati non è stata inviata, la funzionalità non è stata eseguita) corrisponde solo a `is empty` e `equals not_defined`; ogni altro confronto - `equals`, `contains`, `greater than`, e anche `not equals` e `not in` - non corrisponde, e il nodo di ramificazione passa al ramo successivo. Un campo che contiene una **stringa vuota** è un valore, non un campo mancante: una sessione creata con `"metadata": {"credential_state": ""}` non supera `metadata.credential_state equals IL`, ma supera `not equals IL`, `not in [IL, MA, NJ]` e `equals ""` (`is empty` corrisponde a entrambi i casi). Un ramo che approva su un confronto negativo approva quindi una sessione il cui stato è stato inviato vuoto, mentre la stessa sessione senza la chiave prende il ramo di fallback. Quando instradi su `not equals` o `not in`, aggiungi `metadata. is not empty` allo stesso ramo (logica AND) in modo che entrambi i casi terminino dove dovrebbe terminare un valore assente. I rami vengono valutati in ordine e vince il primo che corrisponde; il ramo di fallback (il ramo senza condizioni) viene seguito **solo quando nessun altro ramo ha corrisposto**, quindi assegna a ogni nodo di ramificazione un fallback che termini dove vuoi che finisca un valore inatteso. Una sessione che arriva in In revisione senza avvisi su alcuna funzionalità è stata instradata lì da un nodo di stato nel grafo, non da un controllo; il ramo di fallback di un nodo di ramificazione è la causa più comune. **Metadati di sessione.** I valori che invii in `metadata` alla creazione della sessione sono disponibili a ogni ramo come `metadata.` e possono essere confrontati con un valore fisso o con un altro campo della sessione (ad esempio `metadata.min_age <= Age`). I numeri vengono confrontati come numeri, quindi `18` e `"18"` si comportano allo stesso modo. **Sandbox / modalità di test.** Le condizioni dei rami, i metadati e i nodi di stato funzionano in sandbox esattamente come in produzione, e la sandbox non porta mai una sessione in revisione da sola. La differenza riguarda il documento: una sessione in sandbox contiene un documento fittizio senza stato / regione degli Stati Uniti, quindi le condizioni `Region` non possono corrispondere. Consulta [cosa non contiene il documento fittizio](https://docs.didit.me/it/integration/sandbox-testing.md#ciò-che-il-documento-generato-non-riporta) per sapere come testare i flussi che dipendono dallo stato. **Reinvii.** I nodi di ramificazione vengono valutati a ogni tentativo, compreso un reinvio. Quando rimandi una sessione per passaggi specifici, i rami e le azioni posti tra questi passaggi vengono eseguiti di nuovo mentre l'utente li completa nuovamente, sui dati del **nuovo** tentativo. Un utente che si sposta in una giurisdizione soggetta a restrizioni tra un tentativo e l'altro viene quindi instradato dal ramo che la copre, e un ramo che termina con un esito rifiutato chiude lì la sessione reinviata. **Come vedere quale ramo ha preso una sessione.** Ogni decisione di ramificazione che il workflow prende durante l'esecuzione di una sessione, e ogni nodo di esito raggiunto, viene registrato nella cronologia degli eventi della sessione (Console session detail > Events, e `GET /v3/session/{id}/decision/?include=events`). Una riga **Instradamento del flusso** indica il nodo di ramificazione, la condizione che ha corrisposto e il nodo verso il quale la sessione è proseguita, oppure segnala che **nessuna condizione ha corrisposto** e che è stato seguito l'arco di fallback del nodo. Una riga **Esito del flusso** indica il nodo di stato che ha impostato lo stato della sessione. Quando un workflow porta una sessione in *In revisione* senza che alcuna funzionalità la segnali, quelle righe mostrano il percorso seguito, incluso qualsiasi arco di fallback e il nodo di esito a cui ha condotto. Le successive decisioni manuali non riscrivono questi eventi del workflow. Un input mancante è una possibile causa: le condizioni che richiedono un valore `metadata.*` presente non sono soddisfatte quando la chiave è stata omessa alla creazione della sessione. Le condizioni che verificano esplicitamente l'assenza di input, come `is_empty` o `equals` con `not_defined`, possono corrispondere a quella stessa chiave assente. L'arco di fallback viene seguito solo quando nessun ramo corrisponde, compreso un eventuale ramo else, e porta al nodo collegato all'uscita predefinita. Consulta [eventi di sessione](https://docs.didit.me/it/sessions-api/retrieve-session.md#eventi-di-instradamento-del-workflow) per i payload degli eventi. *** ## Modelli di workflow: il tuo punto di partenza Considera i modelli non come tipi rigidi, ma come **punti di partenza predefiniti e intelligenti** pensati per i casi d'uso più comuni. In modalità semplice sono subito pronti all'uso. In modalità avanzata costituiscono una base che puoi personalizzare in modo approfondito. ![Galleria dei modelli di workflow KYC di Didit per i casi d'uso KYC, KYB e verifica dell'età](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-template.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=a727315368aa2f6bd096e873d7fbae6c) ### Modelli disponibili #### **1. Workflow KYC** La soluzione completa per l'onboarding di nuovi utenti e per soddisfare tutti i requisiti di conformità Know Your Customer (KYC). * **Inizia con:** Verifica di base del documento d'identità. * **Funzionalità spesso aggiunte:** * `[+]` **Rilevamento della vitalità:** Assicura che l'utente sia fisicamente presente e previene lo spoofing. * `[+]` **Confronto facciale 1:1:** Confronta biometricamente il selfie dell'utente con la foto del suo documento d'identità. * `[+]` **Screening AML:** Confronta gli utenti con le liste globali di sanzioni, PEP e notizie negative. * `[+]` **Verifica NFC:** Aggiunge un livello di sicurezza di livello governativo leggendo i chip dei passaporti elettronici e delle carte d'identità elettroniche. * `[+]` **Prova di residenza (PoA):** Verifica l'indirizzo di residenza dell'utente. * `[+]` **Verifica telefonica:** Convalida la titolarità del numero di telefono come fattore aggiuntivo. * `[+]` **Verifica email:** Convalida la titolarità dell'indirizzo email come fattore aggiuntivo. * `[+]` **Validazione su database:** Convalida i dati rispetto a database governativi e di credito ufficiali. * `[+]` **Questionario:** Raccoglie attestazioni strutturate e documenti di supporto tramite moduli personalizzabili. * `[+]` **Analisi dispositivo e IP:** Analizza il rischio legato alla posizione e alla connessione. *** #### **2. Workflow di verifica dell'età adattivo** Un flusso a basso attrito e rispettoso della privacy per i servizi con limiti d'età. * **Inizia con:** Stima dell'età basata su selfie. * **Logica chiave:** * Se l'età stimata è chiaramente superiore alla tua soglia (ad esempio, un'età stimata di 25+ per un servizio 18+), l'utente supera la verifica immediatamente. * Se la stima è inferiore alla soglia o rientra in una "zona di tolleranza" (ad esempio, stimata tra 16-20 anni), puoi configurare il workflow in modo che attivi automaticamente un **fallback alla verifica completa dell'identità** per confermare la data di nascita esatta. * **Funzionalità spesso aggiunte:** * `[+]` **Analisi dispositivo e IP:** Limita l'accesso in base alla posizione geografica. *** #### **3. Workflow di autenticazione biometrica** Un modo rapido e sicuro per riverificare gli utenti che tornano, senza chiedere di nuovo i loro documenti. * **Inizia con:** Un controllo di Rilevamento della vitalità per confermare che l'utente è presente. * **Logica principale:** * Il sistema esegue un Confronto facciale tra il nuovo selfie acquisito dal vivo e il modello biometrico affidabile ottenuto dalla verifica KYC iniziale approvata dell'utente. * Se l'utente ha già un volto memorizzato sotto lo stesso `vendor_data` (volto acquisito durante un Rilevamento della vitalità approvato, foto del passaporto elettronico, ritratto del documento d'identità o volto di un profilo registrato), puoi omettere `portrait_image` quando crei la sessione e Didit riutilizza automaticamente il volto memorizzato. Altrimenti passa `portrait_image` (immagine codificata in Base64, massimo 2MB); senza l'uno o l'altro, la creazione della sessione non riesce con `400`. * **Funzionalità spesso aggiunte:** * `[+]` **Verifica telefonica:** Collega l'indirizzo a un numero di telefono verificato. * `[+]` **Verifica email:** Convalida la titolarità dell'indirizzo email come fattore aggiuntivo. * `[+]` **Analisi dispositivo e IP:** Segnala i tentativi di accesso sospetti da nuove posizioni. *** #### **4. Workflow di verifica dell'indirizzo** Un flusso dedicato per i casi in cui la Prova di residenza (PoA) è il requisito principale. * **Inizia con:** L'invio da parte dell'utente di un documento di Prova di residenza (ad esempio, una bolletta di un servizio o un estratto conto bancario). * **Logica principale:** La nostra AI estrae e convalida il nome e l'indirizzo dal documento. * **Funzionalità spesso aggiunte:** * `[+]` **Verifica telefonica:** Collega l'indirizzo a un numero di telefono verificato. * `[+]` **Verifica email:** Convalida la titolarità dell'indirizzo email come fattore aggiuntivo. * `[+]` **Analisi dispositivo e IP:** Confronta l'indirizzo del documento con la geolocalizzazione attuale dell'utente per una maggiore sicurezza. *** #### **5. Workflow di verifica tramite questionario** Un flusso mirato per quando il tuo obiettivo principale è raccogliere attestazioni strutturate e documenti di supporto tramite moduli personalizzabili. * **Inizia con:** Questionario. * **Logica principale:** Il sistema presenta il questionario configurato (sezioni, contenuti tradotti, campi obbligatori, caricamenti). * **Funzionalità spesso aggiunte:** * `[+]` **Analisi dispositivo e IP:** Aggiungi il contesto relativo alla posizione e alla connessione agli invii del questionario. > **Personalizzazione completa** > Ogni funzionalità all'interno di un workflow può essere ulteriormente personalizzata con parametri specifici per soddisfare i tuoi requisiti esatti. Esplora le impostazioni di ogni controllo nel generatore di workflow. *** ## Regole di costruzione in base allo stato civile In **modalità avanzata** puoi usare il campo OCR `kyc.marital_status` nei rami condizionali e nelle regole di stato personalizzate. Scegli il valore dal selettore dei campi in modo che la regola utilizzi l'enumerazione supportata e non testo libero. Se il documento non riporta lo stato civile, il valore è vuoto e si applica il tuo ramo di ripiego. Il copilota del workflow può anche creare e configurare i passaggi di **Validazione su database** in un'unica azione. Quando gli chiedi di aggiungere questo controllo, specifica i paesi che ti servono: la console individua il servizio supportato per ciascun paese e mostra la configurazione salvata nell'area di lavoro. *** ## Confronto tra modalità Semplice e Avanzata | Capacità | Modalità Semplice | Modalità Avanzata | | - | - | - | | Selezione del modello | ✅ | ✅ | | Attivazione e disattivazione delle funzionalità | ✅ | ✅ | | Configurazione base delle funzionalità | ✅ | ✅ | | Editor visuale di grafi | ❌ | ✅ | | Diramazioni condizionali | ❌ | ✅ | | Automazione delle azioni (tag, metadati) | ❌ | ✅ | | Percorsi di verifica paralleli | ❌ | ✅ | | Decisioni basate sul rischio | Limitate | ✅ Controllo completo | | Supporto per annullare/ripetere | ❌ | ✅ | | Scorciatoie da tastiera | ❌ | ✅ | *** ## Flusso di integrazione Integrare un workflow orchestrato è semplice. Il tuo server crea una sessione con Didit, riceve un URL univoco e reindirizza l'utente a quell'URL. Didit gestisce il resto e comunica al tuo server i risultati tramite webhook. ```mermaid theme={null} sequenceDiagram participant Customer participant Client participant Server participant Didit Customer->>Client: Go to verification page Client->>Server: POST /create-verification-session Server->>Didit: POST /v3/session/ Didit-->>Server: Return new verification session Server-->>Client: Return verification session's url Client->>Customer: Redirect customer to url Customer->>Didit: Complete verification steps Didit->>Server: Send status updates Server->>Customer: Notify of status changes Customer->>Customer: Return to callback URL ``` *** ## Casi d'uso comuni
Caso d'uso Modello consigliato Modalità consigliata Funzionalità suggerite
Verifica dell'identità di base KYC Semplice Rilevamento della vitalità, Confronto facciale
Onboarding ad alta sicurezza KYC Avanzata NFC, Rilevamento della vitalità, Confronto facciale, AML, Verifica telefonica
Contenuti o servizi con limiti di età Verifica dell'età adattiva Semplice Fallback su verifica dell'identità
Autenticazione degli utenti abituali Autenticazione biometrica Semplice Analisi dispositivo e IP
Verifica dell'indirizzo Prova di residenza Semplice Verifica telefonica
Onboarding per servizi finanziari KYC Avanzata Rilevamento della vitalità, Confronto facciale, Prova di residenza, AML, Validazione su database
Conformità specifica per regione KYC Avanzata Instradamento condizionale per paese, controlli diversi per regione
Verifica basata sul rischio KYC Avanzata Rami condizionali basati sui punteggi di rischio, percorsi di escalation
*** ## Per iniziare 1. **Non conosci ancora Didit?** Inizia con la **Modalità Semplice** e un modello predefinito 2. **Hai bisogno di personalizzazione?** Passa alla **Modalità Avanzata** per aggiungere logica condizionale > Contatta il nostro team commerciale per discutere configurazioni personalizzate dei workflow o per ricevere indicazioni sulla soluzione più adatta alle tue esigenze specifiche. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.