Personnalisation anti-fraude
Concevoir, tester et mettre en œuvre des signaux de fraude, des décisions des prestataires, le routage et les commentaires sur les résultats, sans dépendre des résultats d'un navigateur.
Sur cette page
Personnalisez les contrôles anti-fraude en tant que système de décision complet : collectez les signaux autorisés, demandez à la prestataire configurée de prendre une décision, traduisez cette décision en action de paiement, et renvoyez les résultats confirmés afin que le modèle puisse s'améliorer.
Cycle de décision en matière de fraude#
01 · observe
Collecter les signaux approuvés
Envoyer des informations précises sur la commande, le client, le vendeur, l'adresse et l'appareil, en veillant à ce que le fournisseur sélectionné les prenne en charge.
02 · assess
Évaluer le risque
DEUNA active la connexion anti-fraude configurée au point approprié de la stratégie de paiement.
03 · act
Appliquer la politique
Continuez, demandez l'authentification, suspendez pour examen, redirigez différemment ou refusez conformément au résultat standardisé.
04 · confirm
Vérifier l'état du paiement
Utilisez l'état de paiement officiel ou un webhook vérifié avant de procéder à l'exécution.
05 · learn
Résultats
Envoyer les résultats d'analyse de fraude et de contestation convenus afin que le prestataire puisse évaluer les performances du modèle.
Diagramme de flux
Le seul niveau de risque n'est pas une indication du résultat du paiement. Une transaction à faible risque peut toujours être rejetée par un processeur, et une authentification réussie peut toujours être suivie d'une autorisation infructueuse. Conservez les concepts de fraude, d'authentification et d'état du paiement comme des champs distincts.
Sélectionnez la tâche de personnalisation#
Empreinte digitale de l'appareilGénérez et transmettez l'identifiant de l'appareil requis par le fournisseur de lutte contre la fraude ou de paiement configuré.Web and supported SDK flowsMode ombreComparer les décisions des fournisseurs concernant le trafic de production avant qu'un nouveau modèle n'affecte l'expérience client.Observe without blockingRetour d'information sur les résultatsEnvoyer les résultats historiques de contestations approuvés sans confondre l'ingestion de commentaires avec la gestion des litiges.Email or provisioned SFTPStratégies de paiementEffectuer une évaluation de la fraude avant ou après l'autorisation et définir l'action correspondante pour chaque résultat pris en charge.Decision to actionStatuts de fraudeÉvaluer la fraude séparément du cycle de vie financier et de l'état de revue manuelle.State and decisionsCapacités des fournisseursVérifiez où chaque fournisseur de lutte contre la fraude est référencé et consultez sa documentation de connexion.Country and capability filters
Déterminez les points d'attaque#
| Position | Ce que cela protège | Principale considération | Gestion requise |
|---|---|---|---|
| Avant l'autorisation | Évite l'envoi de tentatives bloquées par les politiques vers le processeur | Un délai d'attente en cas de fraude peut retarder ou empêcher le paiement avant qu'une autorisation ne soit obtenue. | Définir le délai d'attente et le comportement en cas d'échec ; ne pas inventer de résultat de paiement. |
| Après l'authentification | Permet au prestataire d'évaluer le contexte du processeur et de l'autorisation. | Une autorisation approuvée peut nécessiter d'être annulée lorsque le risque rejette la commande. | Maintenir le traitement des paiements en attente et vérifier le résultat de l'annulation ou de la capture. |
| Mode ombre | Mesurer un prestataire sans modifier les décisions de paiement. | Les résultats sont observatoires et ne doivent pas être utilisés implicitement pour faire appliquer des règles. | Séparer les métriques de comparaison des données de routage en temps réel. |
| Examen manuel | Ajoute une étape de validation par un humain ou un fournisseur avant l'action finale | Le flux client et de livraison restent en attente plus longtemps | Considérez manual_review et sont marqués comme non résolus, consommant ainsi l'état autoritaire ultérieur |
Utilisation Authentification dynamique lorsque le résultat de la détection de fraude sélectionne un contrôle de vérification tel que 3DS. Utilisez Examen manuel pour les transactions bloquées et 3DS pour le comportement d'authentification de l'émetteur.
Signal de contrat#
Envoyez uniquement les données qui sont exactes, autorisées et prises en charge par le fournisseur sélectionné. L'ajout de champs supplémentaires ne garantit pas automatiquement une meilleure décision.
| Groupe de signaux | Exemples | Règle d'intégration |
|---|---|---|
| Commande | Montant, devise, articles, livraison, réductions | Assurer la cohérence des totaux avec la commande traitée par le backend |
| Client | Référence client stable, historique de compte, contexte de contact | Ne pas inclure de données sensibles ou des informations personnelles non pertinentes dans les champs libres |
| Appareil | Empreinte ou identifiant de session compatible avec le fournisseur | Générez-le dans le flux client pris en charge et associez-le à la même tentative de commande |
| Plateforme de commerce électronique | Identificateurs de vendeurs et attributs de vendeurs approuvés | Confirmer quels marketplace_sellers champs le fournisseur consomme réellement |
| Résultat | Résultat du paiement, fraude confirmée ou état de contestation accepté | Envoyer de manière idempotente avec l'identifiant de transaction DEUNA |
Déployer en toute sécurité#
- Confirmer le support. Sélectionnez le fournisseur, les marchés, les canaux et la stratégie d'évaluation à partir des capacités et du contrat commercial publiés.
- Définir la politique. Écrivez l'action pour chaque résultat de fournisseur pris en charge, délai d'attente, réponse non disponible et résultat de révision manuelle.
- Identifier les signaux. Documentez la source officielle, le format, la base de consentement et la procédure de secours pour chaque champ que vous envoyez.
- Valider dans l'environnement de test. Tester les cas suivants : faible, moyen, élevé, indisponible, timeout, doublon et signal malformé.
- Comparer en mode de test. Mesurer la couverture et les divergences avant de déployer un nouveau fournisseur ou modèle en production.
- Déployer progressivement. Suivez l'état des approbations, des contestations, des revues, des faux positifs, de la fraude et des résultats des paiements.
- Terminez le processus. Retournez les résultats approuvés via le flux de rétroaction sur les contestations.
Liste de contrôle d'exploitation#
- Conservez les informations d'identification du prestataire dans DEUNA Admin ou dans un backend sécurisé, jamais dans le code du navigateur ou des applications mobiles.
- Corrélez l'évaluation de la fraude, la tentative de paiement, la commande et le résultat ultérieur avec des identifiants stables.
- Assurez-vous que les tentatives de reprise sont idempotentes ; un délai d'attente du client ne prouve pas qu'une évaluation ou un paiement a échoué.
- Conservez la référence du prestataire brute requise pour le support, tout en exposant uniquement la décision normalisée à la logique métier.
- Détecter les problèmes liés à l'absence de données de périphérique, la latence, les réponses indisponibles, les dérives de décision et les échecs de traitement des commentaires.
- Valider la stratégie à chaque fois qu'un fournisseur, un SDK, un marché ou un signal requis change.