Orchestration dynamique de l’authentification et de la vérification avec DEUNA

L'orchestration des paiements ne doit pas se limiter au choix d'un processeur.

Dans de nombreux systèmes de paiement réels, la décision la plus difficile n'est pas seulement où pour envoyer une transaction, mais combien d'authentification ou de vérification doit être exigé avant que le paiement soit autorisé, réessayé, approuvé ou refusé.

C'est là que DEUNA crée un effet de levier.

Le moteur de routage de DEUNA peut être étendu au-delà de la sélection du processeur pour orchestrer décisions d'authentification dynamique et de vérification des transactions à l'intérieur du flux de paiement. Cela permet aux commerçants de réagir aux résultats de la fraude, au comportement de l'émetteur, aux attributs de transaction, au contexte de l'utilisateur et aux signaux de réponse de la passerelle en insérant le bon contrôle uniquement lorsqu'il ajoute de la valeur.

Le résultat est une architecture plus adaptative :

• moins de faux positifs
• moins de dépendance aux règles de rejet statiques
• une protection renforcée sur les transactions qui en ont réellement besoin
• meilleur équilibre entre contrôle de la fraude et conversion
• une politique de fraude plus cohérente entre les PSP et les marchés

Ce que couvre ce guide#

Cette page explique comment DEUNA peut être utilisé pour orchestrer des contrôles d'authentification et de vérification tels que :

• Authentification EMV 3DS complète
• Modèles Données 3DS uniquement / Partage de données uniquement
• Expériences d'authentification basées sur un mot de passe Mastercard
• Fournisseurs de biométrie et de vérification d’identité comme la vérification basée sur le visage ou sur l'appareil
• Orchestration des révisions manuelles tirer parti des capacités d’examen des analystes des fournisseurs de fraude
• Orchestration AVS standardisée normaliser les réponses à la vérification de l'adresse des émetteurs et appliquer une politique de rejet universelle

Il ne s’agit pas simplement d’une fonctionnalité d’acheminement des paiements. C'est un architecture décisionnelle où l’authentification et la vérification des transactions deviennent des contrôles configurables dans la stratégie de paiement du commerçant.

---

Pourquoi c'est important#

De nombreux commerçants fonctionnent encore avec un modèle rigide :

• le moteur de fraude dit approuver → envoyer au processeur
• le moteur de fraude dit rejeter → refuser le paiement
• la passerelle renvoie une réponse AVS → chaque PSP l'expose différemment et le commerçant la gère de manière incohérente ou l'ignore

Ce modèle est simple, mais coûteux.

Cela tend à produire trois problèmes en même temps :

1. Faux positifs: les clients légitimes sont rejetés parce que les règles sont trop agressives.
2. Frottements inutiles: chaque cas qui semble risqué est traité comme tout aussi dangereux, même lorsqu'une intervention plus légère pourrait récupérer le paiement en toute sécurité.
3. Contrôles post-autorisation fragmentés: L'AVS et les signaux de réponse similaires varient selon la passerelle, ce qui rend difficile l'application d'une politique de fraude unifiée.

DEUNA permet aux commerçants de remplacer cette décision binaire par un flux plus nuancé :

• approuver directement lorsque la confiance est élevée
• intensifiez votre authentification lorsque la confiance est faible
• utiliser des chemins de partage de données plus légers lorsque le commerçant souhaite préserver la conversion
• appliquer une vérification biométrique ou native de l'appareil lorsque la certitude de l'identité compte plus que le seul risque lié à la carte
• standardiser les résultats AVS et décider si une autorisation doit toujours être acceptée ou refusée sur la base d'une politique universelle

Ceci est particulièrement utile pour les commerçants opérant dans différentes zones géographiques, émetteurs, profils de risque et segments de clientèle.

---

L'approche DEUNA#

DEUNA permet aux commerçants de traiter l'authentification et la vérification comme contrôles de transactions enfichables.

Au lieu d'intégrer un comportement statique au paiement, les commerçants peuvent définir une logique de routage telle que :

• si le fournisseur antifraude approuve, passez directement à l'autorisation
• si le fournisseur antifraude refuse, ne perdez pas immédiatement le paiement
• évaluer le motif du rejet, le montant de la transaction, le niveau de confiance du client, le comportement de l'émetteur, le marché ou l'ensemble de règles du commerçant
• invoquer dynamiquement la meilleure étape d'authentification pour ce scénario
• une fois la réponse de paiement renvoyée, standardisez les artefacts de vérification des émetteurs et des passerelles tels que AVS et appliquez une politique universelle
• réintégrer la transaction dans le flux de décision du commerçant avec des preuves plus solides ou un contexte plus riche

Cela transforme DEUNA en un plan de contrôle pour les deux :

• acheminement des paiements
• routage d'authentification
• normalisation de la vérification des réponses et application des politiques

Cette combinaison est puissante car elle maintient la logique décisionnelle du commerçant centralisée dans une seule couche d'orchestration au lieu de la disperser entre les PSP, les outils anti-fraude, les tables de codes AVS spécifiques à la passerelle et la logique de paiement personnalisée.

---

Architecture de référence#

Vous trouverez ci-dessous une architecture conceptuelle simple.

DEUNADiagramme de fluxAgrandir

Interprétation architecturale

Dans ce modèle, DEUNA se situe entre la création de l'intention de paiement et le résultat du paiement final.

Il peut ingérer des signaux provenant de plusieurs systèmes, évaluer la logique de routage et déterminer si la transaction doit :

• continuer sans étape supplémentaire
• être enrichi de données supplémentaires
• passer à une authentification plus forte du titulaire de la carte
• être acheminé via un contrôle de vérification d'identité supplémentaire avant la soumission du paiement
• être acheminé vers une file d'attente d'examen manuel du fournisseur de fraude lorsqu'une décision humaine est plus appropriée qu'un refus automatique
• avoir des signaux de vérification de passerelle tels que AVS normalisés et interprétés de manière cohérente après la réponse d'autorisation

C’est la principale différence architecturale : l'authentification et la vérification ne sont plus des fonctionnalités isolées. Ils font partie de l’orchestration des transactions.

---

Contrôles d'authentification et de vérification que DEUNA peut orchestrer#

1. Authentification EMV 3DS complète#

Lorsqu'une authentification plus forte est requise, DEUNA peut acheminer la transaction vers un flux EMV 3DS complet avant autorisation.

Les déclencheurs typiques incluent :

• rejet anti-fraude ou score de risque sévère
• valeur transactionnelle élevée
• premier acheteur ou signaux de confiance faibles des clients
• changements d'appareil, de vitesse ou d'emplacement suspects
• émetteur, BIN ou conditions de marché associées à une pression de fraude plus élevée
• exigence du commerçant ou de la réglementation pour une authentification client plus forte

Quand l'utiliser

La 3DS complète est généralement le bon choix lorsque le commerçant souhaite un une preuve plus solide de la légitimité du titulaire de la carte avant de tenter une autorisation.

Cela est particulièrement utile lorsque le commerçant est prêt à introduire des frictions en échange de :

• une plus grande confiance dans la transaction
• meilleur contrôle de la fraude
• avantages potentiels en matière de rétrofacturation et de responsabilité en fonction du réseau et du contexte de la transaction

Rôle de conception DEUNA

Le rôle de DEUNA ne se limite pas à « activer ou désactiver la 3DS ».

Il peut utiliser des critères de routage tels que :

• seuils de montant des transactions
• émetteur ou segment BIN
• code de décision antifraude
• l'ancienneté du client ou le niveau de confiance
• marchand vertical ou pays
• comportement de repli après un déclin précédent

Cela permet aux commerçants d’appliquer la 3DS de manière sélective plutôt qu’aveugle.

---

2. Modèles Données 3DS uniquement / Partage de données uniquement#

Toutes les transactions suspectes ne doivent pas être transférées dans un flux 3DS entièrement compatible avec les défis.

Dans certains cas, le commerçant souhaite préserver la conversion tout en offrant à l'émetteur un contexte plus riche. C'est là Données uniquement ou Partage de données uniquement les modèles deviennent utiles.

Qu'est-ce que c'est

Il s'agit d'un chemin plus simple où les données de transaction et de client sont partagées via des rails ou des constructions de programmes liés à 3DS, mais le commerçant est ne pas effectuer l'authentification complète du titulaire de la carte de la même manière qu'un step-up 3DS standard.

Quand l'utiliser

Ce chemin est utile lorsque :

• le montant est faible ou économiquement tolérant à un risque supplémentaire
• la transaction est à la limite du risque et n'est pas clairement frauduleuse
• le commerçant souhaite améliorer la prise de décision des émetteurs sans ajouter de frictions significatives lors du paiement
• le but est de préserver la conversion plutôt que de forcer un défi
• le commerçant est prêt à rester plus exposé à la fraude en échange d'une expérience utilisateur plus légère

Valeur architecturale

Du point de vue DEUNA, cela est important car cela ajoute une couche intermédiaire entre :

• difficile d'approuver
• rejet dur

Cela offre aux commerçants une voie de récupération plus douce pour les transactions qui ne justifient pas une contestation complète mais bénéficient néanmoins d'un contexte d'émetteur supplémentaire.

En d’autres termes, DEUNA peut acheminer une partie du trafic vers :

• authentification complète
• enrichissement léger
• ou pas de renforcement du tout

en fonction de la stratégie du commerçant.

---

3. Expériences d'authentification basées sur un mot de passe Mastercard#

Les expériences basées sur les clés d'accès Mastercard représentent un modèle d'authentification plus récent qui peut réduire la dépendance aux flux lourds d'OTP et rendre la sécurité plus native sur l'appareil.

Ce que cela signifie architecturalement

Pour les commerçants, cela introduit une option d'authentification supplémentaire qui peut être mieux adaptée que les modèles de défi traditionnels dans certains parcours de paiement.

Au lieu de traiter les clés d'accès comme un silo de produits distinct, DEUNA peut les positionner comme un autre silo de produits. branche d'authentification enfichable à l'intérieur de la logique de routage où le support de l'écosystème existe.

Quand l'utiliser

Les cas d'utilisation potentiels incluent :

• transactions suspectes pour lesquelles le commerçant souhaite une preuve plus solide sans une expérience OTP traditionnelle
• parcours de cartes enregistrées ou d'utilisateurs récurrents qui bénéficient de l'authentification native de l'appareil
• des scénarios UX premium où minimiser les frictions est important mais où la force de l'identité doit toujours être élevée
• marchés ou programmes où un alignement fort en matière d’authentification est important

Pourquoi cela convient bien à DEUNA

Les clés d'accès sont un bon exemple de la raison pour laquelle l'orchestration des paiements doit évoluer au-delà du changement de processeur.

Un commerçant moderne peut vouloir décider de manière dynamique :

• s'il faut utiliser la 3DS
• s'il faut utiliser un chemin d'enrichissement plus léger
• s'il faut utiliser une méthode d'authentification native de l'appareil
• s'il faut envoyer directement à l'autorisation

Cette décision appartient naturellement à un moteur de routage comme DEUNA.

---

4. Fournisseurs de données biométriques et de vérification d'identité#

Certains commerçants ont besoin d’une plus grande certitude d’identité que ce que les modèles de risque liés aux cartes peuvent fournir à eux seuls.

Dans ces cas, DEUNA peut orchestrer des fournisseurs de services biométriques ou de vérification d’identité comme contrôles conditionnels au sein du flux de paiement.

Les exemples incluent les fournisseurs qui peuvent prendre en charge :

• vérification du visage
• contrôles de vivacité
• contrôles de possession d'appareils
• correspondance d'identité avec les enregistrements de clients connus

Quand l'utiliser

Ceci est particulièrement utile dans des scénarios tels que :

• risque de rachat de compte
• achats de très grande valeur
• nouveaux utilisateurs suspects
• catégories de produits réglementés ou sensibles
• flux marchands où la personne qui effectue la transaction doit être plus fortement liée à une identité connue

Valeur architecturale

Il n’est pas nécessaire d’imposer ces prestataires sur tout le trafic de paiement.

DEUNA peut les utiliser de manière sélective lorsqu'un modèle de transaction justifie une étape de vérification plus centrée sur l'identité. Cela les rend économiquement et opérationnellement viables dans le cadre d’une stratégie de décision à plusieurs niveaux.

---

5. Orchestration manuelle des révisions#

Toutes les transactions risquées ne devraient pas être automatiquement refusées, et tous les cas limites ne devraient pas être contraints à une authentification client plus stricte.

Pour certains commerçants, la bonne solution consiste à envoyer les transactions sélectionnées vers un file d'attente de révision manuelle alimenté par la plateforme de fraude déjà dans la pile. DEUNA peut traiter cela comme une autre branche d’orchestration dans le flux de décision de paiement.

Ce que cela signifie

Dans ce modèle, DEUNA achemine la transaction vers un fournisseur de fraude qui prend en charge l'examen des analystes ou la gestion des cas. Le fournisseur peut ensuite placer la commande dans un état d'examen afin qu'un analyste ou une équipe chargée des opérations anti-fraude puisse prendre la décision finale.

Ceci est particulièrement pertinent pour les fournisseurs tels que :

• files d'attente d'examen des fournisseurs de fraude prises en charge qui renvoient une décision d'examen à DEUNA
• Certifier, dont la plateforme et les récentes orientations mettent en avant l'expertise humaine, la gestion centralisée des cas, l'affectation des analystes et les règles de remontée d'informations dans le cadre des flux de travail opérationnels d'examen des fraudes.

Quand l'utiliser

La révision manuelle est souvent appropriée dans les cas suivants :

• la transaction est de grande valeur ou sensible sur le plan opérationnel
• le signal de fraude est ambigu plutôt que clairement frauduleux
• le client est stratégiquement important et le commerçant veut éviter un déclin brutal
• l'ordre contient des caractéristiques qui sont mieux jugées par un analyste de fraude que par une règle statique
• le commerçant gère déjà une équipe d'opérations anti-fraude et souhaite que DEUNA intègre les cas dans ce processus

Valeur architecturale

L'examen manuel n'est pas la même chose que l'EMV 3DS, les mots de passe ou la vérification biométrique. Il est mieux compris comme un chemin de validation humaine à l’intérieur du même modèle d’orchestration.

Cela le rend toujours extrêmement précieux dans DEUNA car le commerçant peut décider de manière dynamique :

• quand une transaction doit être approuvée automatiquement
• quand il devrait passer à l'authentification des clients
• quand il faut passer à la vérification d'identité
• et quand la meilleure prochaine action est l'examen par un analyste au lieu de perdre le paiement

Modèles d'orchestration typiques

Les exemples incluent :

• le score anti-fraude tombe dans une bande de révision → envoyer en révision manuelle au lieu de refus immédiat
• utilisateur novice avec une valeur de commande inhabituellement élevée → envoyer à un analyste pour examen avant la capture ou l'exécution
• transaction suspecte mais non concluante → combiner la notation en amont avec l'examen manuel
• résultat AVS inacceptable sur une commande stratégiquement importante → passer à l'examen au lieu d'un refus général
• scénario à haut risque concernant les compagnies aériennes, les voyages, la billetterie ou les biens numériques → permettre à une équipe chargée de la fraude d'appliquer son jugement spécifique au commerçant

Gestion des résultats

Une fois que le fournisseur de fraude renvoie le résultat de l'examen, DEUNA peut acheminer l'étape suivante en conséquence, par exemple :

• approuver et poursuivre l'autorisation, la capture ou l'exécution en fonction du flux marchand
• rejeter et arrêter la transaction
• escalader à un chemin d'authentification ou de vérification d'identité plus fort si le commerçant souhaite un modèle hybride

C'est une raison supplémentaire pour laquelle DEUNA n'est pas seulement un processeur-routeur. Il devient la couche de coordination entre les systèmes automatisés de lutte contre la fraude, les opérations de contrôle humain et l'exécution des paiements.

---

6. Orchestration AVS et gestion AVS standardisée#

Le service de vérification d'adresse (AVS) est un signal essentiel de contrôle de la fraude qui vérifie si l'adresse de facturation soumise par le client correspond à l'adresse enregistrée auprès de la banque émettrice.

Le défi pour les commerçants n’est pas de savoir si l’AVS est utile. Le défi est que les PSP et les passerelles exposent AVS différemment :

• chaque PSP peut renvoyer son propre jeu de codes AVS bruts
• la sémantique de réponse varie selon la passerelle et l'acquéreur
• les commerçants finissent par maintenir des mappages fragmentés et des règles de décision incohérentes

DEUNA simplifie cela en traitant l'AVS comme un couche d'orchestration standardisée, pas seulement un champ spécifique à la passerelle.

Ce que DEUNA fait

Lorsque les transactions sont traitées via les PSP pris en charge et que les données AVS sont renvoyées, DEUNA peut :

• récupérer la réponse AVS brute de la PSP ou de la passerelle
• normaliser cette réponse en un Modèle de code DEUNA AVS unique
• laissez les commerçants définir une politique universelle de lutte contre la fraude à l'aide des codes DEUNA AVS
• appliquer automatiquement cette politique à chaque stratégie de paiement configurée qui reçoit des données AVS

Cela donne aux commerçants un langage de contrôle de la fraude unique et cohérent au lieu de maintenir une seule interprétation AVS par fournisseur.

Pourquoi c'est important sur le plan architectural

AVS ne remplace pas la 3DS ou la vérification d’identité. Il joue un rôle différent.

AVS est mieux compris comme un signal de vérification renvoyé dans le chemin de réponse au paiement cela peut encore affecter sensiblement le résultat final de la transaction.

Cela le rend très précieux dans une architecture DEUNA car les commerçants peuvent combiner :

• contrôles de préautorisation, comme l'évaluation de la fraude et l'authentification renforcée
• contrôles post-réponse, comme l'interprétation AVS standardisée et les règles de refus automatique

Cela crée une pile de décisions plus complète.

Normalisation DEUNA AVS

Différentes passerelles exposent AVS différemment, ce qui rend difficile une stratégie de fraude unifiée.

DEUNA résout ce problème en standardisant les codes AVS bruts des fournisseurs dans un ensemble commun de Codes DEUNA AVS plus faciles à comprendre et à mettre en œuvre.

Cette standardisation permet aux commerçants de créer une politique anti-fraude unique qui peut être réutilisée sur plusieurs passerelles sans reconstruire la logique pour chacune d'entre elles.

Refus automatique de transaction

L'une des utilisations les plus importantes de DEUNA AVS est la capacité d'arrêter automatiquement les transactions qui semblent trop risquées, même lorsque la passerelle ou le processeur les accepterait autrement.

Par exemple, les commerçants peuvent configurer des codes DEUNA AVS spécifiques pour :

• toujours permettre
• toujours nier
• faire remonter pour une action en aval, telle qu'un examen, un acheminement alternatif ou une vérification supplémentaire

Cela signifie que la politique du commerçant peut annuler l’acceptation aveugle de la passerelle lorsque le résultat AVS ne répond pas à la tolérance au risque du commerçant.

Quand l'utiliser

L'orchestration AVS est particulièrement utile lorsque les commerçants souhaitent :

• appliquer une politique de fraude sur plusieurs PSP
• réduire la gestion du code AVS spécifique à la passerelle dans le code de l'application
• bloquer les incompatibilités d'adresses à risque de manière rapide et cohérente
• combiner la vérification de l'adresse de facturation avec une stratégie plus large de risque et d'authentification
• améliorer le contrôle de la fraude sans imposer une authentification plus forte à chaque transaction

Positionner AVS dans une stratégie DEUNA

Un modèle fort consiste à utiliser AVS comme couche complémentaire aux côtés de l’authentification dynamique.

Par exemple :

• transaction à faible risque + bon résultat AVS → approuver normalement
• transaction à risque modéré + résultat AVS faible → refuser ou augmenter conformément à la politique
• Rejet anti-fraude + le commerçant souhaite un chemin de récupération → passer à 3DS avant autorisation
• autorisation approuvée + résultat AVS inacceptable → refus automatique basé sur la politique DEUNA AVS

C'est là que DEUNA ajoute une réelle valeur architecturale : les décisions d'authentification et la vérification de la réponse au paiement peuvent toutes deux vivre dans le même modèle d'orchestration.

Définir des règles de refus automatique dans DEUNA Admin

Un flux opérationnel typique peut être documenté comme :

1. Connectez-vous à Administrateur DEUNA.
2. Accédez à Gestion des erreurs.
3. Ouvrez Paramètres AVS.
4. Sélectionnez les codes DEUNA AVS qui représentent un risque inacceptable pour votre entreprise.
5. Enregistrez la configuration.

Une fois configurée, cette politique peut être appliquée de manière cohérente à toutes les transactions traitées via des stratégies prises en charge où les données AVS sont disponibles.

---

Comment les architectes de solutions devraient-ils y penser#

Une bonne implémentation ne consiste pas à « ajouter plus d’authentification partout ».

Une bonne implémentation définit un échelle de décision.

Échelle de décision recommandée

Niveau 1 — Autorisation directe
À utiliser pour des modèles à faible risque, fiables et reproductibles où la conversion doit rester aussi fluide que possible.

Niveau 2 — Enrichissement léger
Utilisez les chemins Données uniquement / Partage de données uniquement lorsque le contexte de l'émetteur est utile mais qu'un défi complet est trop coûteux pour la conversion.

Niveau 3 — Authentification forte du titulaire de la carte
Utilisez la version 3DS complète lorsque le risque augmente considérablement ou lorsqu'une preuve plus solide du titulaire de la carte est requise.

Niveau 4 — Validation humaine
Utilisez l'examen manuel lorsque le signal est ambigu et qu'un analyste de la fraude peut prendre une meilleure décision commerciale qu'une règle statique.

Niveau 5 — Certitude identitaire plus forte
Utilisez des contrôles biométriques ou de vérification d’identité lorsque la transaction nécessite une confiance allant au-delà des contrôles standards au niveau du paiement.

Niveau 6 — Application de la vérification des réponses
Utilisez l’application standardisée des politiques AVS pour décider si une autorisation doit toujours être acceptée, refusée ou transmise après le retour de la réponse au paiement.

Ce modèle à plusieurs niveaux aide les commerçants à éviter trois erreurs d'architecture courantes :

• abuser de l'authentification forte sur un trafic qui ne la justifie pas
• sous-utiliser les chemins d'intensification récupérables et recourir par défaut à des déclins sévères
• laisser la sémantique AVS spécifique à la passerelle fragmenter la politique de fraude entre les fournisseurs

---

Exemples de modèles de décision#

Modèle A — Récupération des rejets antifraude#

Objectif : sauver de bonnes transactions qui autrement seraient refusées.

Exemple de politique :

• si l'anti-fraude rejette et que le montant est élevé → déclencher la 3DS complète
• si l'antifraude rejette et que le montant est faible → essayez le chemin Données uniquement
• si l'anti-fraude rejette et que le commerçant a une forte confiance des utilisateurs récurrents → essayez le chemin activé par clé d'accès si pris en charge
• si les rejets antifraude et la certitude de l'identité de l'utilisateur sont essentiels → déclencher la vérification biométrique

C’est l’un des exemples les plus clairs de la valeur de DEUNA : un rejet de fraude ne doit pas nécessairement marquer la fin de la transaction.

Modèle B — Segmentation de la confiance des utilisateurs#

Objectif : évitez d’appliquer les mêmes règles à chaque client.

Exemple de politique :

• utilisateur régulier de confiance → autorisation directe ou enrichissement léger uniquement
• utilisateur répété avec un appareil ou un comportement géographique anormal → mot de passe ou 3DS
• premier utilisateur avec panier haut → 3DS complète
• nouvel utilisateur avec achat sensible à l'identité → vérification biométrique

Modèle C — Stratégie d'authentification tenant compte des coûts#

Objectif : aligner la profondeur de l’authentification avec l’économie des transactions.

Exemple de politique :

• panier de faible valeur → préserver l'UX, utiliser d'abord l'enrichissement lumineux
• panier de valeur moyenne avec risque modéré → 3DS sélectif
• panier de grande valeur ou cible de fraude à marge élevée → intensification plus forte par défaut
• ordre stratégiquement important mais ambigu → examen manuel au lieu d'un rejet automatique

Cela aide les commerçants à éviter d’appliquer uniformément le coût d’une authentification forte à tout le trafic.

Modèle D — Examen manuel des transactions ambiguës#

Objectif : évitez les baisses inutiles lorsqu’un analyste humain peut ajouter de la valeur.

Exemple de politique :

• si le fournisseur de fraude renvoie un score de plage d'examen → envoyer la transaction à un examen manuel
• si une première commande de grande valeur présente des signaux mitigés → acheminer vers la file d'attente des analystes
• si l'examen est approuvé → continuer selon le flux du commerçant
• si l'examen est rejeté → refuser la transaction ou bloquer l'exécution

Ceci est particulièrement utile pour les commerçants qui font déjà appel à des analystes de fraude et souhaitent que DEUNA orchestre le transfert au lieu de traiter l'examen comme un système entièrement distinct.

Modèle E – Politique universelle de rejet de l’AVS sur l’ensemble des PSP#

Objectif : standardiser la gestion des risques liés aux adresses de facturation entre les fournisseurs.

Exemple de politique :

• si la passerelle renvoie le code AVS que DEUNA mappe pour correspondre complètement → autoriser
• si la passerelle renvoie un code AVS que DEUNA mappe à une incompatibilité partielle → évaluer conformément à la politique du commerçant
• si la passerelle renvoie un code AVS que DEUNA mappe à une incompatibilité à haut risque ou à un modèle indisponible que le commerçant a bloqué → refuser automatiquement
• si le commerçant souhaite un traitement plus souple pour certains segments → passer à l'examen ou à l'action en aval au lieu d'un refus général

Cela permet au commerçant de gérer une seule politique AVS sur toutes les passerelles de paiement au lieu de créer une seule table de codes par intégration.

Modèle F – Authentification, examen et décision AVS combinés#

Objectif : utiliser différents contrôles à différents moments du flux de transactions.

Exemple de politique :

• rejet anti-fraude avant autorisation → récupérer avec 3DS
• autorisation réussie avec résultat AVS inacceptable → refuser la post-réponse conformément à la politique DEUNA
• utilisateur régulier de confiance avec un historique solide et un AVS acceptable → approuver avec un minimum de frictions
• nouvel utilisateur avec une correspondance d'adresse faible et un panier élevé → une posture d'intensification plus forte ou de refus plus stricte

Ce modèle démontre que la meilleure stratégie de fraude ne repose souvent pas sur un seul contrôle, mais sur plusieurs contrôles coordonnés sous une seule couche d’orchestration.

---

Entrées que DEUNA peut utiliser dans la logique de routage#

Une mise en œuvre robuste combine généralement plusieurs entrées plutôt que de s'appuyer sur un seul score de risque.

Les entrées typiques incluent :

• décision anti-fraude, score ou motif de rejet
• historique du client et niveau de confiance
• montant du paiement et profil du panier
• type de produit ou sensibilité à la fraude de la commande
• BIN, émetteur, type de carte ou pays
• anomalies de l'appareil ou de la session
• modèles de vitesse
• politiques verticales des commerçants
• exigences spécifiques à la géographie
• résultats historiques d’approbation ou de fraude par segment
• Résultats AVS renvoyés par les PSP ou passerelles prises en charge
• bandes d'examen des fournisseurs de fraude, files d'attente ou résultats d'examen manuel

Cela permet à DEUNA d'agir comme un moteur de décision centralisé au lieu d'une logique codée en dur au sein de l'intégration de chaque fournisseur.

---

Considérations relatives à la mise en œuvre#

1. Gardez la décision centralisée#

La politique d’authentification et de vérification doit résider dans la couche d’orchestration et ne pas être fragmentée indépendamment entre le code frontal, les paramètres PSP et les outils anti-fraude.

2. Séparer la notation des risques de la sélection des actions#

Un score de fraude ne définit pas en soi la meilleure action.

La couche d'orchestration doit traduire les signaux de risque en actions appropriées pour cette transaction, telles que :

• approuver
• enrichir
• intensifier
• vérifier l'identité
• appliquer un refus ou une escalade basé sur AVS
• voie vers la révision manuelle
• réessayer ou revenir en arrière

3. Conception pour l'observabilité#

Les commerçants doivent mesurer les performances de chaque succursale, notamment :

• taux de récupération des transactions précédemment rejetées
• augmentation de l'autorisation par chemin d'authentification
• taux de fraude par chemin
• taux de contestation et taux d’abandon le cas échéant
• impact sur la conversion par segment d'utilisateurs
• Taux d'inadéquation AVS par PSP et segment
• taux de refus piloté par une politique AVS standardisée
• économie du coût de recouvrement

4. Évitez les règles statiques universelles#

Une règle qui fonctionne bien pour les nouveaux utilisateurs de grande valeur peut être nuisible pour les clients réguliers de faible valeur.

DEUNA est plus efficace lorsque les commerçants segmentent la stratégie en fonction du risque et du contexte commercial.

5. Traitez soigneusement les artefacts d'authentification#

Lorsque 3DS fait partie du flux, les implémentations doivent gérer les données d'authentification selon les règles actuelles du réseau de cartes, du fournisseur de paiement et de la conformité. Ne dépendez pas du stockage à long terme de valeurs d'authentification cryptographiques telles que CAVV ou AAV. DEUNA transmet le résultat d'authentification requis dans le flux d'autorisation pris en charge ; les journaux et analyses des commerçants ne doivent pas conserver les cryptogrammes bruts.

6. Traitez l’AVS comme un signal et non comme la seule source de vérité#

L’AVS est précieux, mais il ne doit pas être interprété de manière isolée.

Les meilleures implémentations évaluent AVS avec :

• historique de l'utilisateur
• valeur de la transaction
• score anti-fraude
• comportement de l'appareil
• modèles de fraude spécifiques au marché

C'est exactement pourquoi AVS appartient à un modèle d'orchestration plutôt qu'à une règle de passerelle autonome codée en dur.