Authentification dynamique
Orchestration dynamique de l’authentification et de la vérification avec DEUNA
Sur cette page
- Ce que couvre ce guide
- Modèle de décision
- Architecture de référence
- Choisir un contrôle d'authentification
- Examen manuel
- Vérification post-autorisation
- Comment les architectes de solutions devraient-ils y penser
- Exemples de modèles de décision
- Entrées que DEUNA peut utiliser dans la logique de routage
- Considérations relatives à la mise en œuvre
Orchestration dynamique de l’authentification et de la vérification avec DEUNA
L'authentification dynamique sélectionne le contrôle dont une transaction a besoin avant l'autorisation et applique une politique de vérification cohérente après la réponse du processeur. La décision peut utiliser les résultats de fraude, les attributs de transaction, le contexte client, le comportement de l'émetteur, les règles du marché et la politique de risque du marchand.
Ce que couvre ce guide#
Modèle de décision#
| Moment | Implémentation rigide | Implémentation orchestrée |
|---|---|---|
| Requête à faible risque | Appliquer la même authentification à chaque client. | Continuer directement lorsque la route et la politique du marchand le permettent. |
| Risque limite | Approuver ou rejeter à partir d'un score unique. | Sélectionner un enrichissement léger, une authentification forte, une vérification d'identité ou une revue manuelle. |
| Demande à haut risque | Refuser immédiatement. | Arrêter la transaction ou tenter un contrôle de récupération approuvé lorsqu'il est configuré. |
| Réponse du processeur | Interpréter les valeurs AVS spécifiques au fournisseur de manière indépendante. | Normaliser les signaux de vérification pris en charge et appliquer une politique marchande commune. |
La politique de routage doit séparer l'évaluation du risque de la sélection de l'action. Un score ou une décision du fournisseur est une entrée ; la route configurée détermine la prochaine action autorisée.
Architecture de référence#
Vous trouverez ci-dessous une architecture conceptuelle simple.
Interprétation architecturale
| Scène | Responsabilité | Résultat |
|---|---|---|
| Évaluer | Combiner les entrées approuvées de fraude, client, transaction, émetteur, marché et politique marchande. | Une décision de route avec la prochaine action autorisée. |
| Contrôle | Continuer directement ou invoquer un enrichissement, une authentification, une vérification d'identité ou une revue manuelle pris en charge. | Preuve ou décision finale. |
| Autoriser | Envoyer la transaction éligible au processeur de paiement sélectionné. | Autorisation et données de vérification prises en charge. |
| Appliquer | Normaliser les signaux de réponse pris en charge et appliquer la politique commune du marchand. | Accepter, refuser ou escalader. |
L'authentification et la vérification restent donc une partie de la même route de transaction au lieu de devenir des intégrations spécifiques au fournisseur isolées.
Choisir un contrôle d'authentification#
Sélectionner le contrôle pris en charge le moins perturbateur qui satisfait aux exigences de risque et de politique de la route.
| Contrôle | Meilleure solution | Impact client | Résultat de la route |
|---|---|---|---|
| Autorisation directe | Trafic de confiance, à faible risque, sans exigence supplémentaire. | Aucune étape d'authentification ajoutée. | Continuer vers le processeur sélectionné. |
| Données 3DS uniquement / Partage de données uniquement | Trafic limite où le contexte de l'émetteur peut aider, mais un défi n'est pas justifié. | Aucun défi complet du titulaire de la carte. | Continuer avec le contexte supplémentaire de l'émetteur, là où pris en charge. |
| EMV 3DS complet | Risque élevé, valeur élevée, première utilisation, conditions de l'émetteur, ou exigence réglementaire ou du marchand. | Authentification sans friction ou avec défi selon le résultat 3DS pris en charge. | Continuer uniquement avec un résultat d'authentification acceptable. |
| Clé d'accès (Passkey) | Parcours d'utilisateur récurrent éligible ou natifs de l'appareil où une preuve plus forte est utile. | Authentification native de l'appareil, là où prise en charge. | Continuer avec le résultat de clé d'accès pris en charge. |
| Vérification biométrique ou d'identité | Risque de prise de contrôle de compte, produits sensibles, valeur très élevée, ou besoin d'une certitude d'identité plus forte. | Vérifications faciales, de vivacité, de possession ou d'identité selon le fournisseur sélectionné. | Continuer, arrêter ou escalader selon le résultat configuré. |
| Examen manuel | Transactions ambigües ou sensibles sur le plan opérationnel où le jugement humain apporte de la valeur. | La transaction attend une décision d'un analyste. | Approuver, rejeter ou escalader. |
Le routage peut évaluer le montant de la transaction, l'ancienneté du client, les changements d'appareil ou de vélocité, le segment de l'émetteur ou du BIN, le marché, le résultat de fraude et les tentatives précédentes. Ne supposez pas que chaque contrôle est disponible sur chaque processeur ou dans chaque marché.
Examen manuel#
Utilisez la revue manuelle lorsqu'un workflow de fournisseur de fraude pris en charge peut prendre une meilleure décision qu'un refus automatique ou une authentification client supplémentaire. Les candidats typiques incluent les commandes de haute valeur, les signaux de fraude mixtes, les clients stratégiquement importants et les transactions avec un contexte opérationnel que les règles statiques ne peuvent pas évaluer de manière fiable.
| Résultat de la revue | Action suivante |
|---|---|
| Approuver | Continuer vers l'autorisation, la capture ou la réalisation selon le flux du marchand. |
| Rejet | Arrêter la transaction ou bloquer la réalisation selon la politique. |
| Escalader | Invoquer un chemin d'authentification ou de vérification d'identité pris en charge lorsque la route le permet. |
La revue manuelle est un chemin de validation humaine. Elle ne remplace pas EMV 3DS, les passkeys, la vérification biométrique ou les contrôles de réalisation du marchand.
Vérification post-autorisation#
AVS est un signal de réponse, pas un remplacement pour 3DS ou la vérification d'identité. Les processeurs pris en charge peuvent exposer différentes valeurs brutes, donc DEUNA normalise ces valeurs avant que la politique du marchand ne décide de l'action finale.
| Scène | Comportement DEUNA | Décision du marchand |
|---|---|---|
| Recevoir | Lire la réponse AVS brute prise en charge depuis le processeur ou la passerelle. | Aucun parsing spécifique au fournisseur dans le flux de paiement. |
| Normaliser | Mapper la réponse au modèle AVS DEUNA pris en charge. | Maintenir une politique unique sur les connexions éligibles. |
| Appliquer | Évaluer le résultat normalisé par rapport à la politique configurée. | Accepter, refuser ou escalader. |
| Exemple de contexte | Résultat de la politique |
|---|---|
| Risque faible avec un résultat AVS acceptable | Continuer normalement. |
| Risque modéré avec une correspondance faible ou partielle | Refuser ou escalader selon la politique du marchand. |
| L'autorisation réussit mais le résultat AVS normalisé est bloqué | Appliquer le refus post-réponse configuré. |
| Commande stratégiquement importante avec un résultat incertain | Escalader vers une revue prise en charge ou une autre action permise. |
Définir des règles de refus automatique dans DEUNA Admin
Un flux de configuration typique est :
- Connectez-vous à Administrateur DEUNA.
- Accédez à Gestion des erreurs.
- Ouvrez Paramètres AVS.
- Sélectionnez les codes DEUNA AVS qui représentent un risque inacceptable pour votre entreprise.
- Enregistrez la configuration.
Une fois configurée, la politique s'applique de manière cohérente aux routes prises en charge où les données AVS sont disponibles. Voir Gestion AVS pour le modèle de réponse détaillé et le comportement de configuration.
Comment les architectes de solutions devraient-ils y penser#
Une bonne implémentation n'ajoute pas plus d'authentification partout. Elle définit une échelle de décision et ne fait avancer une transaction que jusqu'au point requis par son risque, sa politique et ses preuves.
Échelle de décision recommandée
| Niveau | Contrôle | Utiliser quand |
|---|---|---|
| 1 | Autorisation directe | La transaction est de confiance et aucun contrôle supplémentaire n'est requis. |
| 2 | Enrichissement léger | Le contexte de l'émetteur est utile mais un défi complet n'est pas justifié. |
| 3 | Authentification forte du porteur de carte | Le risque ou la politique nécessite une preuve plus forte du porteur de carte. |
| 4 | Validation humaine | Le signal est ambigu et le jugement d'un analyste peut ajouter de la valeur. |
| 5 | Certitude d'identité plus forte | La transaction nécessite une confiance au-delà des contrôles de la couche de paiement. |
| 6 | Application de la vérification de réponse | Un signal post-réponse pris en charge doit toujours être accepté, refusé ou escaladé. |
L'échelle évite une authentification forte inutile, des transactions récupérables qui se soldent par défaut par des refus définitifs, et une sémantique de réponse spécifique au fournisseur qui fragmente la politique du marchand.
Exemples de modèles de décision#
Entrées que DEUNA peut utiliser dans la logique de routage#
Une route robuste combine des entrées approuvées au lieu de s'appuyer sur un seul score.
| Groupe de signaux | Exemples |
|---|---|
| Fraude | Décision, score, motif de rejet, bande de revue, file d'attente ou résultat de revue manuelle. |
| Client | Historique, ancienneté, niveau de confiance et résultats antérieurs. |
| Transaction | Montant, profil du panier, sensibilité du produit et tentatives précédentes. |
| Carte et émetteur | BIN, émetteur, type de carte, pays et contexte d'authentification pris en charge. |
| Session | Appareil, localisation, vélocité et autres anomalies de session approuvées. |
| Politique du marchand | Secteur vertical, marché, géographie, route et exigences de tolérance au risque. |
| Réponse du processeur | Signaux normalisés pris en charge tels que AVS. |
Gardez les entrées de la route explicites et observables afin qu'une décision puisse être reproduite sans dupliquer la logique spécifique au fournisseur dans le code de paiement.
Considérations relatives à la mise en œuvre#
Mesurer chaque branche
| Zone de mesure | Métriques utiles |
|---|---|
| Récupération | Taux de récupération et augmentation d'autorisation pour le trafic précédemment rejeté. |
| Friction client | Taux de défi, abandon et impact sur la conversion par segment. |
| Risque | Taux de fraude, taux d'inadéquation AVS et taux de refus piloté par la politique. |
| Économie | Coût de traitement et coût pour récupérer une transaction éligible. |
Protéger les preuves d'authentification
Lorsque 3DS fait partie du flux, traitez les données d'authentification selon les règles actuelles des réseaux de cartes, des fournisseurs de paiement et de conformité. Ne comptez pas sur le stockage à long terme de valeurs d'authentification cryptographiques telles que CAVV ou AAV, et ne conservez pas de cryptogrammes bruts dans les journaux ou analyses du marchand.
Traitez AVS comme un signal parmi d'autres, aux côtés de l'historique client, de la valeur de la transaction, des preuves de fraude, du comportement de l'appareil et du contexte du marché — pas comme la seule source de vérité.