Personalizzazione anti-fraud
Progetta, testa e gestisci i segnali di frode, le decisioni del fornitore, il routing e il feedback sui risultati, senza collegare l'esecuzione all'esito di un browser.
In questa pagina
Personalizza i controlli antifrode come un sistema decisionale end-to-end: raccogli i segnali consentiti, richiedi una decisione al fornitore configurato, traduci la decisione in un'azione di pagamento e restituisci i risultati confermati in modo che il modello possa migliorare.
Ciclo di vita della decisione antifrode#
01 · observe
Raccogli i segnali approvati
Invia informazioni accurate sull'ordine, sul cliente, sul venditore, sull'indirizzo e sul dispositivo, supportate dal fornitore selezionato.
02 · assess
Valuta il rischio
DEUNA invoca la connessione antifrode attiva nel punto configurato nella strategia di pagamento.
03 · act
Applica la policy
Continua, richiedi l'autenticazione, metti in attesa per la revisione, reindirizza diversamente o rifiuta in base al risultato standardizzato.
04 · confirm
Riconcilia lo stato del pagamento
Utilizza lo stato di pagamento autorevole o un webhook verificato prima dell'esecuzione.
05 · learn
Restituisci i risultati
Invia i risultati concordati di frodi e contestazioni per consentire al fornitore di valutare le prestazioni del modello.
Diagramma di flusso
Il solo livello di rischio non determina il risultato di un pagamento. Una transazione a basso rischio può comunque essere rifiutata da un processore, e un'autenticazione completata può comunque portare a un'autorizzazione fallita. Mantenere separati i concetti di frode, autenticazione e stato del pagamento.
Seleziona l'attività di personalizzazione#
Impronte di dispositivoGenera e inoltra l'identificatore del dispositivo richiesto dal fornitore di sicurezza o di pagamento configurato.Web and supported SDK flowsModalità ombraConfrontare le decisioni dei fornitori in merito al traffico di produzione prima che un nuovo modello influisca sull'esperienza del cliente.Observe without blockingFeedback sui risultatiInviare i risultati storici di contestazioni senza confondere l'acquisizione di feedback con la gestione delle controversie.Email or provisioned SFTPStrategie di pagamentoEseguire la valutazione del rischio prima o dopo l'autorizzazione e definire l'azione corrispondente a ciascun risultato supportato.Decision to actionStati di frodeValutare la frode separatamente dal ciclo finanziario e dallo stato di revisione manuale.State and decisionsFunzionalità dei providerVerificare dove è pubblicato ciascun fornitore di servizi antifrode e consultare la sua guida di connessione.Country and capability filters
Definire dove si verificano le frodi.#
| Posizionamento. | Cosa protegge | Compromesso principale. | Gestione richiesta. |
|---|---|---|---|
| Prima dell'autorizzazione. | Evitare di inviare tentativi bloccati dalle policy al processore. | Un timeout per la frode può ritardare o interrompere il pagamento prima che sia stata effettuata l'autorizzazione. | Definire timeout e comportamento di fallback; non inventare risultati di pagamento. |
| Dopo l'autorizzazione | Permette al fornitore di valutare il contesto del processore e dell'autorizzazione. | Una autorizzazione approvata potrebbe dover essere annullata quando il sistema rileva un rischio per l'ordine. | Mantenere lo stato di blocco dell'elaborazione e verificare l'esito dell'annullamento o del completamento della transazione. |
| Modalità ombra | Misurare un fornitore senza alterare le decisioni relative ai pagamenti. | I risultati sono osservazionali e non devono essere utilizzati implicitamente per l'applicazione di regole. | Separare le metriche di confronto dagli input di routing in tempo reale. |
| Analisi manuale | Aggiunge una revisione manuale o da parte del fornitore prima dell'azione finale | Il flusso cliente e di completamento rimangono in attesa più a lungo | Considera manual_review e vengono mantenuti come non risolti, consumando lo stato autorevole successivo |
Uso Autenticazione dinamica quando il risultato di controllo antifrode seleziona un controllo di verifica come 3DS. Utilizzare Analisi manuale per le transazioni bloccate e 3DS per il comportamento di autenticazione dell'emittente.
Segnale di contratto#
Inviare solo i dati accurati, consentiti e supportati dal fornitore selezionato. L'aggiunta di più campi non garantisce automaticamente una decisione migliore.
| Gruppo di segnali | Esempi | Regola di integrazione |
|---|---|---|
| Ordine | Importo, valuta, articoli, spedizione, sconti | Mantenere i totali coerenti con gli ordini elaborati dal backend |
| Cliente | Riferimento stabile del cliente, storico degli account, contesto di contatto | Non inserire credenziali segrete o dati personali non pertinenti nei campi di testo libero |
| Dispositivo | Impronta o identificatore di sessione del dispositivo compatibile con il fornitore | Generare nel flusso del cliente supportato e associarlo allo stesso tentativo di ordine |
| Marketplace | Identificatori del venditore e attributi del venditore approvati | Confermare quali marketplace_sellers campi il fornitore effettivamente consuma |
| Risultato | Risultato del pagamento, frode confermata o stato di contestazione concordato | Inviare in modo idempotente con l'identificatore della transazione DEUNA |
Implementare in modo sicuro#
- Confermare il supporto. Selezionare il fornitore, i mercati, i canali e la posizione di valutazione dalla funzionalità e dal contratto commerciale pubblicati.
- Definire la politica. Definire l'azione per ogni risultato, timeout, risposta non disponibile e risultato di revisione manuale del fornitore supportato.
- Mappare i segnali. Documentare la fonte autorevole, il formato, la base di consenso e il meccanismo di fallback per ogni campo inviato.
- Validare in ambiente sandbox. Testare i casi di segnali bassi, medi, alti, non disponibili, timeout, duplicati e malformati.
- Confrontare in modalità shadow. Misurare la copertura e la discrepanza prima di attivare un nuovo fornitore o modello.
- Rilasciare gradualmente. Monitorare insieme i risultati di approvazione, contestazione, revisione, falsi positivi, frodi e pagamenti.
- Chiudere il ciclo. Restituire i risultati approvati tramite il workflow di feedback per le contestazioni.
Elenco di controllo operativo#
- Mantenere le credenziali del fornitore private in DEUNA Admin o in un backend protetto, mai nel codice del browser o mobile.
- Correlare la valutazione della frode, il tentativo di pagamento, l'ordine e il risultato finale con identificatori stabili.
- Rendere idempotenti i retry; un timeout del client non è prova che una valutazione o un pagamento siano falliti.
- Mantenere la referenza originale del fornitore necessaria per il supporto, esponendo solo la decisione normalizzata alla logica di business.
- Avviso in caso di dati del dispositivo mancanti, valutazione della latenza, risposte non disponibili, deriva delle decisioni e fallimenti nell'elaborazione del feedback.
- Rivalutare la strategia ogni volta che cambia un fornitore, SDK, mercato o segnale richiesto.