Introduction

Sogenactif est une solution de paiement de commerce électronique multicanale sécurisée conforme à la norme PCI DSS. Elle vous permet d’accepter et de gérer des transactions de paiement en prenant en compte les règles métiers liées à votre activité (paiement à la livraison, paiement différé, paiement récurrent, paiement échelonné , …).

L'objectif de ce document est de décrire les règles antifraudes en mode Go-No-Go, d'expliquer la manière de les mettre en oeuvre et de les configurer.

La terminologie Go-No-Go correspond au caractère binaire des règles, à avoir un GO ou un NOGO sur l'acceptation de la transaction.

À qui s'adresse ce document

Ce document s’adresse à tous les commerçants qui ont souscrit à l’offre Gestion de la lutte contre la fraude – Go-No-Go ou Go-No-Go+ et souhaitent bénéficier d’un outil de lutte contre la fraude administré par eux-mêmes sur le Portail Sogenactif .

Pour avoir une vue d’ensemble de la solution Sogenactif , nous vous conseillons de consulter les documents suivants :

  • Présentation fonctionnelle ;
  • Configuration des fonctionnalités ;
  • Glossaire.

Contacter l'assistance

Pour toute question technique ou demande d'assistance, nos services sont disponibles du lundi au vendredi, hors jours fériés, de 9 h à 19 h :

  • par téléphone au : +33 (0) 825 090 095 ;
  • par e-mail : supportsogenactif@worldline.com.

Pour faciliter le traitement de vos demandes, veuillez communiquer votre identifiant de commerçant : merchantId (numéro à 15 chiffres).

Vue d'ensemble

Accéder au Portail Sogenactif

Toutes les fonctionnalités de lutte contre la fraude décrites dans cette documentation sont gérées dans le Portail Sogenactif .

Vous devez donc avoir souscrit à l’offre Gestion de la lutte contre la fraude – Go-No-Go ou Go-No-Go+ pour pouvoir accéder à ces fonctionnalités.

L’accès au Portail Sogenactif se fait via l’URL suivante :

https://portail.sogenactif.com/

L’accès est sécurisé et nécessite un identifiant et un mot de passe.

Après identification, cliquez sur l'onglet 'Fraude' pour gérer la lutte contre la fraude pour votre offre.

Voir la partie 'Configurer des profils anti-fraude avec le Portail Sogenactif ' pour plus d'informations.

Comprendre la lutte contre la fraude

Avant de commencer, il est absolument essentiel pour vous de bien comprendre la manière dont les fraudeurs mènent leurs attaques.

Les fraudeurs sont très bien organisés et exploitent la plupart des faiblesses que comportent la sécurité et les aspects légaux du commerce électronique. Notamment :

  • ils opèrent à l'échelle internationale ;
  • ils se servent de citoyens honnêtes pour exercer leurs activités frauduleuses ;
  • ils se dissimulent derrière des serveurs mandataires étrangers ;
  • 3-D Secure n'est pas un obstacle pour eux ;
  • ils renouvellent leurs types d'attaques régulièrement.

Par conséquent, il est essentiel de comprendre au niveau commerçant les comportements frauduleux lors de la mise en œuvre des règles antifraudes. Il est également très important de surveiller les résultats régulièrement et de maintenir les bons paramétrages en fonction de cette surveillance. Cela nécessite généralement de mettre sur pied une cellule de gestion de la fraude de votre côté.

Le moteur de lutte contre la fraude s’appuie sur des profils antifraude afin d’évaluer les transactions. Ceux-ci sont composés de règles que vous configurez.

La gestion des règles antifraudes est un cercle vertueux qui débute par la création d’un profil antifraude efficace qui convient à votre activité. Elle se poursuit par des vérifications régulières des activités frauduleuses et l'affinage régulier du profil en question.

Note: l'onglet fraude du Portail Sogenactif et les outils de rapports existants sont conçus pour vous permettre de gérer la solution antifraude de manière indépendante.

Définition d'une règle antifraude

Qu'est-ce qu'une règle antifraude ?

Une règle antifraude est une vérification effectuée sur l’un des critères de la transaction. Le critère contrôlé peut être par exemple le pays de la carte, la plage de montants, le numéro de la carte, l’adresse IP, l’identifiant du client, etc. Les règles sont classées par catégorie : géolocalisation, vélocité, liste, panier et divers.

Les règles sont de type GO (détectant une condition favorable à la poursuite de la transaction) ou NOGO (détectant une condition défavorable à la transaction).

Les règles doivent être activées et paramétrées dans un profil antifraude afin d’être exécutées. Pour la définition d’un tel profil, veuillez-vous référer à la définition d'un profil antifraude.

Type de règle GO ou NOGO

Règle de type GO

Une règle de type GO a pour objectif de détecter une condition favorable sur la transaction qui génère un GO au niveau de l’acceptation de celle-ci (exemple : identifiant client présent dans la liste blanche des clients).

Elle retourne un résultat positif si la condition est remplie et un résultat neutre dans le cas contraire.

Actuellement les règles de type GO sont basées sur la présence d’un élément de la transaction dans des listes blanches appelées aussi listes positives.

Règle de type NOGO

Une règle de type NOGO a pour objectif, de détecter une condition défavorable sur la transaction qui génère un NOGO au niveau de l’acceptation de la transaction (exemple : identifiant client présent dans la liste noire des clients).

Elle retourne un résultat négatif si la condition est remplie et un résultat neutre dans le cas contraire.

Les règles du type NOGO sont réparties en 5 catégories :

  • règles de géolocalisation ;
  • règles d'encours (vélocité) ;
  • règles de listes ;
  • règles de panier ;
  • règles diverses.

Mode décisif ou informatif

Les règles peuvent être paramétrées en mode décisif ou informatif.

Mode décisif

Une règle paramétrée en mode décisif a un impact sur le déroulement de la transaction.

Les règles en mode décisif peuvent donner 3 types de résultat vis-à-vis de l’acceptation de la transaction :

  • Résultat positif

    Un résultat positif indique que le critère contrôlé est favorable à l’acceptation de la transaction.

    Exemple : si l’identifiant client fait partie de la liste des clients VIP (règle liste blanche des identifiants clients), il n’est pas nécessaire de contrôler les autres critères.

  • Résultat négatif

    Un résultat négatif indique que le critère contrôlé est défavorable à l’acceptation de la transaction.

    Exemple : en mode pré-autorisation, si la carte est dans la liste grise ou noire des cartes, on refuse la transaction.

  • Résultat neutre

    Un résultat neutre indique que le critère contrôlé n’est ni favorable ni défavorable à l’acceptation de la transaction.

    Exemple : l’identifiant client ne fait pas partie de la liste des clients VIP (règle liste blanche des identifiants clients).

Mode informatif

Une règle paramétrée en mode informatif n’a pas d’impact sur le déroulement de la transaction. Le résultat de la règle vous est restitué pour analyse. Par exemple : si la règle pays de l’adresse IP est paramétrée en mode informatif, le résultat de la règle a uniquement pour effet la restitution du pays de l’adresse IP, mais n’a pas d’impact sur l’acceptation de la transaction.

Configuration avancée

De base, certaines règles n’ont pas nécessairement un caractère positif ou négatif (par exemple les règles de géolocalisation ; vous pouvez vouloir favoriser certains pays ou en défavoriser d’autres) tandis que d’autres ont forcément un caractère positif (listes blanches) ou négatif (listes noires).

Par défaut les règles proposées sont configurables dans un mode de configuration simple, c’est-à-dire qu’une règle est définie comme étant  positive (GO) ou  négative (NOGO) .

Néanmoins, certaines règles bénéficient d’un mode de configuration avancée. En mode de configuration avancée, une même règle peut être à la fois  positive (GO) et  négative (NOGO) . Elle aura donc une influence positive, négative ou neutre sur le résultat du contrôle de la transaction en fonction du paramétrage de la règle et du contexte de transaction.

Le choix d’activer le mode de configuration avancée se fait lors du paramétrage de la règle dans le profil. Il est possible de n’activer ce mode que pour certaines règles et de laisser le mode de configuration simple pour les autres.

Le paramétrage avancé d’une règle permet de spécifier les critères qui auront une influence positive ou négative sur le résultat.

Exemple avec la règle plage de montant configurée en décisif :

Configuration de la règle (profil) Montant de la transaction Résultat Conséquence en mode pré-authentification
Mode de configuration simple
  • Min = 50
  • Max = 200
45 Négatif Déclencher 3-D Secure
150 Neutre Passer aux règles suivantes
250 Négatif Déclencher 3-D Secure
Mode de configuration avancée Plage positive :
  • Min = 50
  • Max = 150
Plage négative :
  • Min = 300
  • Max = 400
45 Neutre Passer aux règles suivantes
100 Positif Débrayer 3-D Secure
200 Neutre Passer aux règles suivantes
350 Négatif Déclencher 3-D Secure
450 Neutre Passer aux règles suivantes

Exemple avec la règle authentification 3-D Secure configurée en décisif :

Configuration de la règle (profil) Statut 3-D Secure de la transaction Résultat Conséquence en mode pré-autorisation
Mode de configuration simple Statuts négatifs :
ERROR
SUCCESS Neutre Passer aux règles suivantes
ERROR Négatif Refuser la transaction avant la demande d'autorisation
Mode de configuration avancée Statuts négatifs :
ERROR

Statuts positifs :

SUCCESS
SUCCESS Positif Passer à la demande d'autorisation directement sans passer par les autres règles
ERROR Négatif Refuser la transaction avant la demande d'autorisation

Modes d'exécution et leurs impacts sur l'acceptation

Sogenactif offre deux modes de contrôle de lutte contre la fraude :

  • mode pré-autorisation : permet d’arrêter les transactions frauduleuses avant la demande d’autorisation ;
  • mode pré-authentification : permet de débrayer le 3-D Secure pour les transactions considérées comme non risquées.
Figure 1. déroulement des traitements lors d'une transaction de paiement

Mode pré-autorisation

En mode pré-autorisation (le mode par défaut de contrôle de lutte contre la fraude de Sogenactif ), les règles sont exécutées avant la demande d’autorisation et après l’authentification 3-D Secure (si la boutique est enrôlée 3-D Secure). Si le résultat du contrôle est négatif, la transaction sera refusée avant la demande d’autorisation.

Pour les moyens de paiement avec redirection vers une page spécifique pour ce moyen de paiement (exemple : Paypal), le contrôle pré-autorisation est déclenché avant la redirection.

En fonction de votre besoin, vous définissez votre ou vos profils pré-autorisation en combinant :

  • les règles GO et/ou NOGO ;
  • les modes décisif et/ou informatif.

Un profil est informatif quand toutes les règles sont en mode informatif.

Un profil est décisif quand toutes les règles sont en mode décisif.

Un profil est mixte quand il comporte des règles en mode informatif et en mode décisif.

Type de profil Sogenactif  / commerçant Impacts sur l'acceptation
Profil informatif Sogenactif Pas d’impact, Sogenactif poursuit l’action de demande d’autorisation.
Commerçant Le commerçant doit analyser le résultat des règles et décider de la suite à donner à la transaction via les opérations de caisse annulation ou validation .
Profil décisif Sogenactif Si le résultat est négatif , la transaction est refusée par Sogenactif , il n’y a pas de demande d’autorisation.
Si le résultat est positif ou neutre , Sogenactif poursuit l’acceptation en faisant une demande d’autorisation.
Commerçant Pas d’impact sur l’acceptation de la transaction car le commerçant a délégué à Sogenactif la prise de décision sur la fraude.
Toutefois le commerçant peut analyser le motif.
Profil mixte Sogenactif Idem au cas du profil décisif.
Commerçant Si la transaction est refusée , pas d’impact pour le commerçant.
Si la transaction est acceptée , le commerçant doit analyser le résultat des règles en mode informatif et décider de la suite à donner.

Mode pré-authentification

En mode pré-authentification, les règles sont exécutées avant l’authentification 3-D Secure. Si le résultat du contrôle est positif, l’authentification 3-D Secure sera débrayée et Sogenactif poursuit la demande d’autorisation.

Ce mode est applicable uniquement pour les transactions carte avec l’authentification 3-D Secure.

En fonction de votre besoin, vous définissez votre ou vos profils pré-authentification en combinant les règles GO et/ou NOGO.

Un profil est décisif quand toutes les règles sont en mode décisif.

Dans un profil Go-No-Go pour la phase de pré-authentification, il est uniquement possible de paramétrer des règles décisives. Des règles informatives dans un tel profil n’ont pas d’utilité à cette étape.

Type de profil Sogenactif  / commerçant Impacts sur l'acceptation
Profil décisif Sogenactif Si le résultat est positif , Sogenactif débraye l’authentification 3-D Secure et poursuit le contrôle pré-autorisation.
Si le résultat est négatif ou neutre , Sogenactif poursuit l’authentification 3-D Secure avant de faire le contrôle pré-autorisation.
Commerçant Le commerçant peut analyser le résultat des règles et décider de la suite à donner à la transaction via les opérations de caisse annulation ou validation .
IMPORTANT: précision sur les règles proposées en pré-authentification

Comme le débrayage de l’authentification 3-D Secure a lieu lorsque le résultat est positif, il est important de paramétrer au moins une règle du type GO en décisif afin de débrayer l’authentification 3-D Secure pour certains clients.

Définition d'un profil antifraude

Qu'est-ce qu'un profil antifraude ?

Un profil antifraude est un ensemble de règles que vous choisissez et paramétrez parmi les règles proposées par Sogenactif . Les règles sont exécutées avant l’authentification 3-D Secure et avant la demande d’autorisation selon votre paramétrage (pour comprendre les modes pré-authentification et pré-autorisation, veuillez-vous référer aux modes d'exécution et leurs impacts sur l'acceptation).

Le paramétrage des profils antifraude se fait l'onglet fraude du Portail Sogenactif .

Profils moyen de paiement et profil par défaut

Dans la plupart des cas, vous définissez un profil antifraude unique qui est appliqué à l’ensemble de vos transactions, quel que soit le moyen de paiement utilisé. Cependant, vous pouvez également définir des profils antifraudes supplémentaires ayant un paramétrage adapté à un ou plusieurs moyens de paiement particuliers.

Lorsqu’une transaction doit être évaluée, le système de contrôle du risque commence par chercher, au sein du paramétrage de la boutique un profil antifraude spécifique au moyen de paiement utilisé.

Si un tel profil n’est pas trouvé, le système cherche le profil par défaut de la boutique. Ce profil est un profil permettant d’analyser les transactions qui n’ont pas été traitées par des profils spécifiques aux moyens de paiement.

Pour créer un profil par défaut, il suffit de créer un profil sans lui attribuer de moyen de paiement.

Attention: si aucun profil actif n'est disponible sur la boutique, c'est le profil offre du distributeur qui sera appliqué.

Il ne peut y avoir qu’un seul profil actif pour un moyen de paiement donné. De même, il ne peut y avoir qu’un seul profil par défaut actif.

Par exemple, il est possible d'avoir :

  • un profil dédié CB, VISA et MASTERCARD ;
  • un profil dédié AMEX ;
  • et un profil par défaut qui contrôlera les transactions payées avec un autre moyen de paiement.

Soit trois profils actifs simultanément.

Vous pouvez créer autant de profils inactifs que nécessaire. Ceci permet par exemple de garder des profils en réserve pour des périodes particulières de l’année (soldes, fêtes…).

Déroulement d'un profil antifraude

Les règles sont déclenchées séquentiellement suivant l'ordre du paramétrage du profil.

La première règle paramétrée en mode décisif qui donne un résultat positif pour les règles GO, ou négatif pour les règles NOGO, arrête le déclenchement de la suite des règles décisives.

Les règles en mode informatif sont déclenchées systématiquement.

Pour la restitution du résultat des règles en informatif ou en décisif veuillez-vous référer à la restitution du résultat des règles. Le schéma ci-dessous décrit le déclenchement de règles.

Figure 2. procédure de déclenchement d'un profil antifraude

Débrayage dynamique des règles

Vous avez la possibilité de débrayer dynamiquement, dans la requête de la transaction, certaines règles du profil. Pour avoir la liste des directives de débrayage reportez-vous à l’Annexe 1 : désactivation dynamique de certaines règles du profil.

Note: le débrayage dynamique est applicable aux règles actives dans des profils pré-authentification et pré-autorisation (pour comprendre les modes pré-authentification et pré-autorisation, veuillez-vous référer aux modes d’exécution (pré-autorisation & pré-authentification) et leur impacts sur l’acceptation).

Surcharge dynamique des règles

Vous avez la possibilité de surcharger dynamiquement, dans la requête de la transaction, certaines règles du profil.

Les modalités de surcharge dynamique sont décrites dans la description et mise en oeuvre des règles.

IMPORTANT: vous ne pouvez pas surcharger les règles imposées par le distributeur.
Note: la surcharge dynamique est applicable aux règles actives dans des profils pré-authentification et pré-autorisation (pour comprendre les modes pré-authentification et pré-autorisation, veuillez-vous référer aux modes d’exécution et leurs impacts sur l’acceptation).

Restitution du résultat des règles

Mode pré-autorisation

Le résultat de l’exécution du profil de pré-autorisation est restitué dans les champs complementaryCode, complementaryInfo , preAuthorisationProfile, preAuthorisationProfileValue et preAuthorisationRuleResultList  :

  • complementaryCode contient le code spécifique de la règle décisive ou informative qui a retourné un résultat négatif (pour les règles du type NOGO) ou positif (pour les règles du type GO). Si aucune règle décisive ou informative n’a retourné de résultat positif ou négatif, le champ vaut 00 ;
  • complementaryInfo * contient 3 types d’informations :
    1. le résultat de chaque règle (décisive ou informative) exécutée dans le profil marchand au format <RULE_RESULT XX=Y XX=Y … XX=Y />  :
      Lettre(s) Description Valeur
      XX Code de la règle. Pour connaître les codes de règles, veuillez vous référer à la liste des règles.
      Y Résultat d'exécution N : résultat négatif
      P : résultat positif
      O : résultat neutre
      U : règle pas exécutée car transaction incomplète (par exemple donnée non renseignée)
      X : règle non applicable à ce type de transaction
      B : règle non exécutée car vous l'avez débrayée
      E : règle non exécutée suite à erreur technique
      D : règle non exécutée suite à erreur de la surcharge dynamique

    2. les informations complémentaires générées par les règles exécutées.

      Pour connaître les informations détaillées, veuillez-vous référer à la description et mise en oeuvre des règles. Notez que seules certaines règles alimentent le champ complementaryInfo ,

    3. les informations sur la carte de paiement utilisée le cas échéant.
      Pour connaître les informations détaillées, veuillez-vous référer aux informations carte,
  • preAuthorisationProfile contient le nom du profil antifraude exécuté avant la demande d’autorisation ;
  • preAuthorisationProfileValue contient l’identifiant unique de la version du profil exécuté. Cette information est utile pour pouvoir retrouver le profil dans l’état où il se trouvait au moment de l’exécution des règles ;
  • preAuthorisationRuleResultList contient une liste du résultat détaillé de chaque règle exécutée avant la demande d’autorisation.
Chaque objet contenu dans le champ preAuthorisationRuleResultList correspond au résultat d’une règle et contient les valeurs suivantes :
Objet Description Valeur
ruleCode Code de la règle. Pour connaître les codes de règles, veuillez-vous référer à la liste des règles.
ruleType Type de la règle. Pour connaître le type de chaque règle, veuillez-vous référer à la liste des règles.
Si le mode de configuration avancée est activé sur une règle, la valeur du champ ruleType est valorisée à « MI ».
ruleWeight D : si la règle est paramétrée en décisif dans le profil
I : si la règle est paramétrée en informatif dans le profil
ruleSetting Type de configuration de la règle. D : dynamique (valeur donnée dans la requête de paiement)
S : statique (valeur venant du profil fraude)
I : statique imposée dans la configuration de l'offre distributeur
N : pas de configuration (lorsque la règle ne nécessite aucune configuration)
ruleResultIndicator Résultat d'exécution de la règle. N : résultat négatif
P : résultat positif
O : résultat neutre
U : règle non exécutée car transaction incomplète (par exemple donnée non renseignée)
X : règle non applicable à ce type de transaction
B : règle non exécutée car vous l'avez débrayée
E : règle non exécutée suite à erreur technique
D : règle non exécutée suite à erreur de la surcharge dynamique
ruleDetailedInfo Informations complémentaires générées par la règle. Pour connaître les informations détaillées, veuillez-vous référer à la description et mise en oeuvre des règles.

Ces champs vous sont restitués sur les interfaces suivantes :

  • la réponse automatique et la réponse manuelle de Sogenactif Paypage  ;
  • la réponse des connecteurs Sogenactif Office Serveur (services Checkout, CashManagement (duplication) et Diagnostic) ;
  • Portail Sogenactif  ;
  • le journal des transactions à l’exception du champ preAuthorisationRuleResultList .

Profil informatif

Champ Description
Résultat neutre
responseCode Valorisé en fonction de la réponse d’autorisation
acquirerResponseCode Valorisé en fonction de la réponse d’autorisation
complementaryCode Valorisé en fonction des règles informatives exécutées, sinon 00**
complementaryInfo* Valorisé en fonction des règles déroulées
preAuthorisationProfile Nom du profil antifraude exécuté
preAuthorisationProfileValue Identifiant unique du profil exécuté
preAuthorisationRuleResultList Liste du résultat détaillé de chaque règle exécutée

Profil décisif ou mixte

Champ Description
Résultat neutre
responseCode Valorisé en fonction de la réponse d’autorisation
acquirerResponseCode Valorisé en fonction de la réponse d’autorisation
complementaryCode Valorisé en fonction des règles informatives exécutées, sinon 00*
complementaryInfo* Valorisé en fonction des règles déroulées
preAuthorisationProfile Nom du profil antifraude exécuté
preAuthorisationProfileValue Identifiant unique du profil exécuté
preAuthorisationRuleResultList Liste du résultat détaillé de chaque règle exécutée
Résultat positif
responseCode Valorisé en fonction de la réponse d’autorisation
acquirerResponseCode Valorisé en fonction de la réponse d’autorisation
complementaryCode Valorisé en fonction de la règle GO qui a généré l’accord
complementaryInfo* Valorisé en fonction des règles déroulées
preAuthorisationProfile Nom du profil antifraude exécuté
preAuthorisationProfileValue Identifiant unique du profil exécuté
preAuthorisationRuleResultList Liste du résultat détaillé de chaque règle exécutée
Résultat négatif
responseCode Valorisé à 05
acquirerResponseCode Non renseigné
complementaryCode Valorisé en fonction de la règle NOGO qui a généré le refus
complementaryInfo* Valorisé en fonction des règles déroulées
preAuthorisationProfile Nom du profil antifraude exécuté
preAuthorisationProfileValue Identifiant unique du profil exécuté
preAuthorisationRuleResultList Liste du résultat détaillé de chaque règle exécutée

* Le champ complementaryInfo est déprécié. Il n’évoluera plus et cessera à terme d’être alimenté. Les informations qu’il contient sont disponibles dans une version améliorée, dans le champ preAuthorisationRuleResultList .

** Voir la liste des règles

Mode pré-authentification

Le résultat de l’exécution du profil de pré-authentification est restitué dans les champs preAuthenticationProfileValue, preAuthenticationProfile, preAuthenticationValue et preAuthenticationRuleResultList  :

  • preAuthenticationValue contient le code spécifique de la règle décisive qui a retourné un résultat négatif (pour les règles du type NOGO) ou positif (pour les règles du type GO). Si aucune règle décisive n’a retourné de résultat positif ou négatif, le champ est vide ;
  • preAuthenticationProfile contient le nom du profil antifraude exécuté avant l’authentification ;
  • preAuthenticationProfileValue contient l’identifiant unique de la version du profil exécuté. Cette information est utile pour pouvoir retrouver le profil dans l’état où il se trouvait au moment de l’exécution des contrôles ;
  • preAuthenticationRuleResultList contient une liste du résultat détaillé de chaque règle exécutée avant l’authentification.

Chaque objet contenu dans le champ preAuthenticationRuleResultList correspond au résultat d’une règle et contient les mêmes valeurs que le champ preAuthorisationRuleResultList en pré-autorisation. Pour en connaître le contenu, veuillez-vous référer au mode pré-autorisation.

Ces champs vous sont restitués sur les interfaces suivantes :

  • les réponses automatique et manuelle de Sogenactif Paypage  ;
  • la réponse des connecteurs Sogenactif Office Serveur (CashManagement (duplication) et Diagnostic) ;
  • Portail Sogenactif  ;
  • le journal des transactions à l’exception du champ preAuthorisationRuleResultList .

Champ Description
Résultat neutre
preAuthenticationValue Valorisé à vide*
preAuthenticationProfile Nom du profil antifraude exécuté
preAuthenticationProfileValue Identifiant unique du profil exécuté
preAuthenticationRuleResultList Liste du résultat détaillé de chaque règle exécutée
Résultat positif (3DS débrayé)
preAuthenticationValue Valorisé en fonction de la règle GO qui a généré l’accord*
preAuthenticationProfile Nom du profil antifraude exécuté
preAuthenticationProfileValue Identifiant unique du profil exécuté
preAuthenticationRuleResultList Liste du résultat détaillé de chaque règle exécutée
Résultat négatif
preAuthenticationValue Valorisé en fonction de la règle NOGO qui a généré le refus*
preAuthenticationProfile Nom du profil antifraude exécuté
preAuthenticationProfileValue Identifiant unique du profil exécuté
preAuthenticationRuleResultList Liste du résultat détaillé de chaque règle exécutée

____________________

* Voir les différents codes dans la liste des règles

Limites d'utilisation

Moyens de paiement

L'offre globale Sogenactif propose divers moyens de paiements internationaux, comme les cartes Visa/Mastercard, le portefeuille numérique Paypal, le virement iDeal, le prélèvement SDD, etc.

Les règles ne s'appliquent pas nécessairement à tous les moyens de paiement (exemple : les règles InfoScore ne sont applicables que pour les transactions ELV).

Pour les moyens de paiement single message**, la définition des profils informatifs est techniquement possible, mais le résultat du contrôle n’aura aucun impact sur l’acceptation de la transaction.

Pour savoir si une règle antifraude est applicable à un moyen de paiement, veuillez-vous référer aux correspondances entre moyens de paiement et règles antifraude (annexe 10).

____________________

** Moyen de paiement en single message : autorisation et remise en une étape, comme les virements tel que Ideal, Sofort, Paybutton ou Paypal en mode immédiate. Moyen de paiement en dual message : autorisation et remise en deux étapes.

Opérations

Les profils antifraudes s’appliquent aux transactions, ainsi qu’aux opérations de caisse provoquant la création d’une nouvelle transaction (duplication et recyclage).

Ainsi les opérations de caisse standards qui manipulent les transactions existantes (validation, annulation, remboursement…) ne font pas l’objet des contrôles antifraudes.

Paiement en n fois

Pour le paiement en N fois, seul le 1er paiement est soumis aux contrôles antifraudes.

Transfert de données dans la requête

Pour certaines règles, il est nécessaire de transmettre des données dans la requête. L’absence des données entraîne la non-exécution de la requête.

Par exemple, pour la règle de l’encours par identifiant client, il est nécessaire de transmettre l’identifiant du client dans la requête. Sinon la règle ne sera pas déclenchée.

Mode d'exécution et règles

Les règles ne s'appliquent pas nécessairement aux 2 modes (pré-authentification et pré-autorisation).

Par exemple la règle Authentification 3-D Secure n’est pas disponible en pré-authentification. En effet, cette règle se base sur le résultat de l’authentification 3-D Secure, or le profil antifraude de pré-authentification est appliqué en amont. Cette règle n’est pas applicable avant l’authentification.

Liste des règles

Table 1. Règles de géolocalisation
Nom de la règle Code de la règle Type Config. avancée Surch. Débray. Pré authen. Pré autor. En savoir plus
Pays de la carte CR NOGO V V V V V
Pays de l’adresse IP CY NOGO V V V V V
Pays de la carte et de l’adresse IP SI NOGO V V V V V
Pays de livraison et de facturation SB NOGO V V V
Codes postaux de livraison et de facturation ZC NOGO V V V
Pays de livraison et de la carte CS NOGO V V V V V
Pays de facturation et de la carte CB NOGO V V V V V
Pays de l’IBAN AC NOGO V V V V
Pays de livraison et l’IBAN DI NOGO V V V V
Pays du téléphone et de l’IBAN PI NOGO V V V V
Pays de l’adresse IP et de l’IBAN IS NOGO V V V V
Table 2. Règles d'encours
Nom de la règle Code de la règle Type Config. avancée Surch. Débray. Pré authen. Pré autor. En savoir plus
Encours carte SC NOGO V V V
Encours par adresse IP VI NOGO V V V
Encours par identifiant client VC NOGO V V V
Nombre de clients par carte MD NOGO V V V
Nombre de cartes par client MR NOGO V V V
Nombre de cartes par adresse IP CI NOGO V V V
Nombre d’IBAN par adresse IP II NOGO V V
Nombre d’adresses IP par IBAN IJ NOGO V V
Nombre de clients par IBAN CJ NOGO V V
Nombre d’IBAN par client IC NOGO V V
Nombre de mandats par adresse IP MJ NOGO V V
Encours par mandat EM NOGO V V
Encours par IBAN EI NOGO V V
Table 3. Règles diverses
Nom de la règle Code de la règle Type Config. avancée Surch. Débray. Pré authen. Pré autor. En savoir plus
Réputations d’adresse IP IR NOGO V V V
Carte en opposition OP NOGO V V V
Carte virtuelle EC NOGO V V V
Carte à autorisation systématique SA NOGO V V V
Carte commerciale (et pays de la carte) CC NOGO V V V V
Plage de montants CA NOGO V V V V
Carte réseau CB NC NOGO V V V
Adresse e-mail gratuite FE NOGO V V V
Authentification 3-D Secure A3 NOGO V V V
Syntaxe d’adresse e-mail ES NOGO V V V
Vérification d’adresse (InfoScore) AV NOGO V V
Vérification de compte (InfoScore) BV NOGO V V
Date d’expiration de la carte PE NOGO V V V
Table 4. Règles de liste
Nom de la règle Code de la règle Type Config. avancée Surch. Débray. Pré authen. Pré autor. En savoir plus
Adresses IP Noire BY NOGO V V V
Grise GY NOGO V V V
Blanche WY GO V V V
Codes postaux par pays Noire BZ NOGO V V V
Grise GZ NOGO V V V
Blanche WZ GO V V V
Adresses e-mail Noire BM NOGO V V V
Grise GM NOGO V V V
Blanche WM GO V V V
ID clients Noire BI NOGO V V V
Grise GI NOGO V V V
Blanche WI GO V V V
Noms de clients Noire BN NOGO V V V
Grise GN NOGO V V V
Blanche WN GO V V V
Numéros de carte Noire BC NOGO V V V
Grise GC NOGO V V V
Blanche WC GO V V V
Numéros de tél. Noire BP NOGO V V V
Grise GP NOGO V V V
Blanche WP GO V V V
Plages de BIN Noire BB NOGO V V V
Grise BR NOGO V V V
Blanche WB GO V V V
Liste de BIC Noire BE NOGO V V
Grise GE NOGO V V
Blanche WE GO V V
Liste d’IBAN Noire BA NOGO V V
Grise GA NOGO V V
Blanche WA GO V V
Liste de mandats Noire TB NOGO V V
Grise TG NOGO V V
Blanche TW GO V V
Table 5. Règles de panier
Nom de la règle Code de la règle Type Config. avancée Surch. Débray. Pré authen. Pré autor. En savoir plus
Liste de produits à risque RP NOGO V V V
Quantité de produits à risque PQ NOGO V V V
Ratio de produits à risque PR NOGO V V V
Quantité de produits QP NOGO V V V

Informations carte

Dans le cas d’un paiement par carte, certaines informations relatives à la carte sont retournées dans le champ complementaryInfo . Les informations retournées incluent :

  • le pays de la carte ;
  • le réseau de la carte ;
  • le code d'émetteur de la carte et le nom d'émetteur de la carte ;
  • le code produit de la carte et le nom de produit de la carte ;
  • le profil produit de la carte.

Les informations sont retournées au format suivant : <CARD_INFOS BDOM=<nom d’émetteur de la carte> COUNTRY=<pays de la carte> PRODUCTCODE=<code produit de la carte> NETWORK=<réseau de la carte> BANKCODE=<code d'émetteur de la carte> PRODUCTNAME=<nom de produit de la carte> PRODUCTPROFILE=<produit profil de la carte>/>$

Pour la liste de codes pays, veuillez-vous référer à l'Annexe 4 : codes pays alphabétiques ISO 3166.

Pour la liste de réseaux, veuillez-vous référer à l'Annexe 8 : liste de réseaux cartes.

Pour la liste de produits profils, veuillez-vous référer à l'Annexe 9 : liste de produits profils.

Description et mise en œuvre des règles

Les règles peuvent être paramétrées en combinant les modes décisif ou informatif d'une part et les modes pré-autorisation ou pré-authentification d'autre part.

Règles de géolocalisation : adresse et pays

Note: les listes évoquées dans les règles de géolocalisation ci-dessous sont limitées à 400 éléments, c'est-à-dire 400 pays ou 400 couples de pays (en fonction de la règle concernée).

Pays de la carte

Description de la règle

La règle du pays de la carte vous permet de décider de refuser ou non une transaction en fonction du pays d’émission de la carte du porteur.

La règle va interroger une base de données des plages porteuses afin de vérifier l’appartenance du pays d'origine de la carte à une liste de pays autorisés ou interdits.

En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre code pays comme le seul autorisé.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • et paramétrer la liste des pays de la carte autorisés ou interdits. Pour cela, vous devez :
    • paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même pays ne peut se trouver que dans l’une des deux listes.
IMPORTANT: information sur les cartes American Express

Notre module de fraude a pour référence la base CIS (Card Info Service), qui contient des informations sur les plages de BIN. Or ce référentiel ne contient pas la nationalité des cartes American Express. Il nous est donc impossible, via le module de fraude, de bloquer les cartes American Express via la règle « Pays de la carte ».

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
Le pays de la carte n’est pas connu -- Neutre CARD_COUNTRY=XXX*
Le pays de la carte est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés ou n’est pas équivalent au pays du marchand 06 Négatif
Le pays de la carte est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits ou est différent du pays du marchand -- Neutre

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166 )

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
Le pays de la carte n’est pas connu -- Neutre CARD_COUNTRY=XXX*
Le pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » 06 Négatif
Le pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » -- Neutre
Le pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » 06 Positif

Cette règle alimente le champ complementaryInfo sous la forme CARD_COUNTRY=XXX*.

____________________

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166 )

Surcharge dynamique

Vous avez la possibilité de fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Il existe 2 méthodes pour surcharger dynamiquement les paramètres de la règle.

MÉTHODE 1 :

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedCardCountryList pour la liste des pays autorisés,
    • DeniedCardCountryList pour la liste des pays interdits,
  • mode de configuration avancée :
    • NDeniedCardCountryList pour la liste des pays désavantagés,
    • NDeniedExceptCardCountryList pour la liste des pays non désavantagés,
    • PAllowedCardCountryList pour la liste des pays avantagés,
    • PAllowedExceptCardCountryList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedCardCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}
    

MÉTHODE 2 (dépréciée) :

La liste des pays carte est transmise dans le champ du connecteur :

  • fraudData.allowedCardCountryList pour la liste des pays autorisés ;
  • fraudData.deniedCardCountryList pour la liste des pays interdits.

  • Exemple en version POST :
      fraudData.allowedCardCountryList=FRA,BEL,GBR
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:allowedCardCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "allowedCardCountryList": ["FRA", "BEL", "GBR"]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir :

  • soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive ForeignBinCard .

  • Exemple en version POST :
      fraudData.bypassCtrlList=ForeignBinCard
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>ForeignBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["ForeignBinCard"]
}
    

Pays de l'adresse IP

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en fonction du pays affecté à l’adresse IP de l’acheteur.

La règle va vérifier l’appartenance du pays de l’adresse IP à une liste de pays autorisés ou interdits. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage . Dans ce cas-là, une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre code pays comme le seul autorisé.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l'onglet 'Fraude' du Portail Sogenactif .
  • paramétrer la liste des pays de l'adresse IP autorisés ou interdits. Pour cela, vous devez :
    • paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
  • et transmettre l'adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le pays de l'adresse IP n’est pas connu. -- Neutre IP_COUNTRY=XXX
Le pays de l'adresse IP est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés. 10 Négatif IP_COUNTRY=XXX*
Le pays de l'adresse IP est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits. -- Neutre

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le pays de l'adresse IP n’est pas connu. -- Neutre IP_COUNTRY=XXX
Le pays de l'adresse IP est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». 10 Négatif IP_COUNTRY=XXX*
Le pays de l'adresse IP est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». -- Neutre
Le pays de l'adresse IP est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». 10 Positif

Cette règle alimente le champ complementaryInfo sous la forme <COUNTRY_IP IP_COUNTRY=XXX*/>.

____________________

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous avez la possibilité de fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Il existe 2 méthodes pour surcharger dynamiquement les paramètres de la règle.

MÉTHODE 1 :

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedIpCountryList pour la liste des pays autorisés,
    • DeniedIpCountryList pour la liste des pays interdits,
  • mode de configuration avancée :
    • NDeniedIpCountryList pour la liste des pays désavantagés,
    • NDeniedExceptIpCountryList pour la liste des pays non désavantagés,
    • PAllowedIpCountryList pour la liste des pays avantagés,
    • PAllowedExceptIpCountryList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIpCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}
    

MÉTHODE 2 (dépréciée) :

La liste des pays de l'adresse IP est transmise dans le champ du connecteur :

  • fraudData.allowedIpCountryList pour la liste des pays autorisés ;
  • fraudData.deniedIpCountryList pour la liste des pays interdits.

  • Exemple en version POST :
      fraudData.allowedIpCountryList=FRA,BEL,GBR
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:allowedIpCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "allowedIpCountryList": ["FRA", "BEL", "GBR"]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir :

  • soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive IpCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=IpCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>IpCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["IpCountry"]
}
    

Pays de la carte et de l'adresse IP

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays de la carte et du pays de l'adresse IP de l'acheteur.

Cette règle va interroger la base de données des plages porteuses et celle des plages d’adresses IP afin de vérifier l’appartenance de la combinaison de ces 2 pays à une liste de combinaisons de pays autorisées ou interdites.

Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage . Dans ce cas-là, une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

En l’absence de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de la carte et le pays de l'adresse IP.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste des combinaisons pays de la carte et pays de l'adresse IP autorisés ou interdits. Pour cela, vous devez :
    • paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
  • et transmettre l'adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) -- Neutre NOT_APPLICABLE
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). -- Neutre CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
La combinaison du pays de la carte et du pays de l'adresse IP est interdite. 12 Négatif
La combinaison du pays de la carte et du pays de l'adresse IP est autorisée. -- Neutre

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) -- Neutre NOT_APPLICABLE
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). -- Neutre CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». 12 Négatif
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». -- Neutre
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». 12 Positif

Cette règle alimente le champ complementaryInfo sous la forme <COUNTRY_COMBINATION CARD_COUNTRY=XXX* IP_COUNTRY=YYY*/>.

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous avez la possibilité d'envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedIpCardCountryCombiList pour les combinaisons autorisées de pays de la carte et de l’adresse IP,
    • DeniedIpCardCountryCombiList pour les combinaisons interdites de pays de la carte et de l’adresse IP,
  • mode de configuration avancée :
    • NDeniedIpCardCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptIpCardCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedIpCardCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptIpCardCountryCombiList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCardCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam> AllowedIpCardCountryCombiList </urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

  • soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
  • soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilityIpCard .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilityIpCard
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilityIpCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilityIpCard"]
}
    

Pays de livraison et de facturation

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vérifiant que le pays de livraison et le pays de facturation sont identiques.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et transmettre le pays de livraison et de facturation dans la requête (champs billingAddress.country et deliveryAddress.country ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le pays de livraison ne correspond pas au pays de facturation 30 Négatif SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*
Le pays de livraison correspond au pays de facturation -- Neutre
Non connaissance des pays -- Neutre

Cette règle alimente le champ complementaryInfo sous la forme <COUNTRY_COMBINATION SHIP_COUNTRY=XXX* BILL_COUNTRY=YYY*/>.

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryBillingCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilarityDeliveryBillingCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingCountry"]
}
    

Codes postaux de livraison et de facturation

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vérifiant que le code postal de livraison et le code postal de facturation sont identiques.

Vous ne pouvez activer cette règle que si vous avez aussi activé la règle de comparaison des pays de livraison et de facturation. En effet, il n’est pas pertinent de comparer des codes postaux si les pays ne sont pas identiques.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • avoir déjà la règle « Pays de livraison et de facturation » activée ;
  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et transmettre le code postal de livraison et de facturation dans la requête (champs billingAddress.zipCode et deliveryAddress.zipCode ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le code postal de livraison ne correspond pas au code postal de facturation 26 Négatif SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*; SHIP_ZIP=A*; BILL_ZIP=B*
Le code postal de livraison correspond au code postal de facturation -- Neutre
Non connaissance des codes postaux -- Neutre

Cette règle alimente le champ complementaryInfo sous la forme <COUNTRY_ZIP_COMBINATION SHIP_COUNTRY=XXX* BILL_COUNTRY=XXX* SHIP_ZIP=A* BILL_ZIP=B*/>.

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

A, B : code postal

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryBillingPostalCode .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilarityDeliveryBillingPostalCode
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingPostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingPostalCode"]
}
    

Pays de livraison et de la carte

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays de la carte et du pays de livraison.

En premier lieu, cette règle va interroger la base de données des plages porteuses pour déterminer le pays de la carte. Ensuite, cette règle vérifiera la présence de la combinaison du pays de la carte fraichement déterminé et du pays de livraison dans la liste des combinaisons autorisées ou interdites.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de la carte et le pays de livraison.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer les combinaisons de pays de livraison et de la carte autorisés ou interdits. Pour cela, vous devez :
    • paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
  • et transmettre le pays de livraison dans la requête (champ deliveryAddress.country ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) -- Neutre NOT_APPLICABLE
La combinaison du pays de livraison et du pays de la carte est interdite. 42 Négatif SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
La combinaison du pays de livraison et du pays de la carte est autorisée. -- Neutre
Non connaissance du pays de la carte ou du pays de livraison. -- Neutre

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) -- Neutre NOT_APPLICABLE
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». 42 Négatif SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». -- Neutre
Non connaissance du pays de la carte ou du pays de livraison. -- Neutre
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». 42 Positif

Cette règle alimente le champ complementaryInfo sous la forme <COUNTRY_COMBINATION SHIP_COUNTRY=XXX* CARD_COUNTRY=YYY*/>.

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedDeliveryCardCountryCombiList pour les combinaisons autorisées de pays de livraison et de la carte,
    • DeniedDeliveryCardCountryCombiList pour les combinaisons interdites de pays de livraison et de la carte,
  • mode de configuration avancée :
    • NDeniedDeliveryCardCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptDeliveryCardCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedDeliveryCardCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptDeliveryCardCountryCombiList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryCardCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedDeliveryCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,#ZEURO),(#ZEURO,FRA)”
          }
     ]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

  • soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
  • soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryCardCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilarityDeliveryCardCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryCardCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryCardCountry"]
}
    

Pays de facturation et de la carte

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en se basant sur la combinaison du pays de la carte et du pays de facturation.

En premier lieu, cette règle va interroger la base de données des plages porteuses pour déterminer le pays de la carte. Ensuite, cette règle vérifiera la présence de la combinaison du pays de la carte fraichement déterminé et du pays de facturation dans la liste des combinaisons autorisées ou interdites.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de la carte et le pays de facturation.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer les combinaisons de pays de facturation et de la carte autorisés ou interdits. Pour cela, vous devez :
    • paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
  • et transmettre les pays de facturation et de la carte dans la requête (champs billingAddress.country et cardNumber ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) -- Neutre NOT_APPLICABLE
La combinaison du pays de facturation et du pays de la carte est interdite. 47 Négatif BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
La combinaison du pays de facturation et du pays de la carte est autorisée. -- Neutre
Non connaissance du pays de la carte ou du pays de facturation. -- Neutre

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) -- Neutre NOT_APPLICABLE
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » 47 Négatif BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » -- Neutre
Non connaissance du pays de la carte ou du pays de facturation. -- Neutre
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » 47 Positif

Cette règle alimente le champ complementaryInfo sous la forme <COUNTRY_COMBINATION BILL_COUNTRY=XXX* CARD_COUNTRY=YYY*/>.

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de facturation et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedBillingCardCountryCombiList pour les combinaisons autorisées de pays de facturation et de la carte,
    • DeniedBillingCardCountryCombiList pour les combinaisons interdites de pays de facturation et de la carte,
  • mode de configuration avancée :
    • NDeniedBillingCardCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptBillingCardCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedBillingCardCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptBillingCardCountryCombiList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedBillingCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedBillingCardCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedBillingCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,#ZEURO),(#ZEURO,FRA)”
          }
     ]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

  • soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
  • soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityBillingCardCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilarityBillingCardCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilarityBillingCardCountry"]
}
    

Pays de l'IBAN

Description de la règle

La règle du pays de l’IBAN vous permet de mesurer le risque sur un achat en fonction du pays d’émission de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

La règle va analyser le numéro de l’IBAN pour en extraire le pays et vérifier l’appartenance de celui-ci à une liste de pays autorisés ou interdits.

En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre pays comme le seul autorisé.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profilvia l’onglet fraude du Portail Sogenactif ,
  • et paramétrer la liste des pays d'IBAN autorisés ou interdits. Pour cela, vous devez :
    • paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
Le pays de l’IBAN est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés ou est différent de votre pays 55 Négatif IBAN_COUNTRY=XXX*
Le pays de l’IBAN est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits ou est équivalent à votre pays -- Neutre

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
Le pays de l’IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » 55 Négatif IBAN_COUNTRY=XXX*
Le pays de l’IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » -- Neutre
Le pays de l’IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » 55 Positif

Cette règle n'alimente pas le champ complementaryInfo .

____________________

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedIbanCountryList pour la liste des pays autorisés,
    • DeniedIbanCountryList pour la liste des pays interdits,
  • mode de configuration avancée :
    • NDeniedIbanCountryList pour la liste des pays désavantagés,
    • NDeniedExceptIbanCountryList pour la liste des pays non désavantagés,
    • PAllowedIbanCountryList pour la liste des pays avantagés,
    • PAllowedExceptIbanCountryList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIbanCountryList,riskManagementDynamicValue=FRA,BEL,GBR}
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIbanCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIbanCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}
    

La liste envoyée doit contenir :

  • soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166), séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive IbanCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=IbanCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>IbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["IbanCountry"]
}
    

Pays de livraison et de l'IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays de livraison et du pays de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

Elle va vérifier la présence de la combinaison du pays de livraison et du pays de l’IBAN dans la liste des combinaisons autorisées ou interdites.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de livraison et le pays de l’IBAN.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer les combinaisons de pays de livraison et de pays de l'IBAN autorisés ou interdits. Pour cela, vous devez :
    • paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
  • et transmettre le pays de livraison dans la requête (champ deliveryAddress.country ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation ComplementaryCode Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
La combinaison du pays de livraison et du pays de l'IBAN est interdite 56 Négatif SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s) -- Neutre
La combinaison du pays de livraison et du pays de l'IBAN est autorisée -- Neutre

Mode de configuration avancée :

Cas d'utilisation ComplementaryCode Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » 56 Négatif SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s) -- Neutre
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » -- Neutre
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » 55 Positif

Cette règle n'alimente pas le champ complementaryInfo .

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et pays de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedDeliveryIbanCountryCombiList pour les combinaisons autorisées de pays de livraison et de l’IBAN,
    • DeniedDeliveryIbanCountryCombiList pour les combinaisons interdites de pays de livraison et de l’IBAN,
  • mode de configuration avancée :
    • NDeniedDeliveryIbanCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptDeliveryIbanCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedDeliveryIbanCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptDeliveryIbanCountryCombiList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedDeliveryIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

La liste envoyée doit contenir des couples séparés par des virgules et constitués :

  • soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
  • soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryIbanCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilarityDeliveryIbanCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryIbanCountry"]
}
    

Pays du numéro de téléphone et de l'IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays du numéro de téléphone portable du client et du pays de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

La règle va vérifier la présence de la combinaison du pays du numéro de téléphone portable du client et du pays de l’IBAN dans la liste des combinaisons autorisées ou interdites.

Le pays du numéro de téléphone est obtenu en analysant l’indicatif de celui-ci. Si l’indicatif n’est pas spécifié, le pays ne pourra être récupéré.

En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays du numéro de téléphone portable du client et le pays de l’IBAN.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer les combinaisons de pays de numéro de téléphone et de pays de l'IBAN autorisés ou interdits. Pour cela, vous devez :
    • paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
  • et transmettre le numéro de téléphone portable du client dans la requête (avec indicatif ; champ mobile dans un ou plusieurs groupes d’informations de contact : billingContact, customerContact, deliveryContact, holderContact ).

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est interdite 57 Négatif PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
Le pays du numéro de téléphone portable du client et/ou le pays de l'IBAN n’est/ne sont pas connu(s) -- Neutre
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est autorisée -- Neutre

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » 57 Négatif PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
Le pays du numéro de téléphone portable du client et/ou le pays de l'IBAN n’est/ne sont pas connu(s) -- Neutre
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » -- Neutre
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » 57 Positif

Cette règle n'alimente pas le champ complementaryInfo .

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons du pays du numéro de téléphone portable du client et pays de l’IBAN. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les 2 paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedPhoneIbanCountryCombiList pour les combinaisons autorisées de pays du numéro de téléphone portable du client et de l’IBAN,
    • DeniedPhoneIbanCountryCombiList pour les combinaisons interdites de pays du numéro de téléphone portable du client et de l’IBAN,
  • mode de configuration avancée :
    • NDeniedPhoneIbanCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptPhoneIbanCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedPhoneIbanCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptPhoneIbanCountryCombiList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedPhoneIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>llowedPhoneIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedPhoneIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

  • soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
  • soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityPhoneIbanCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilarityPhoneIbanCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityPhoneIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilarityPhoneIbanCountry"]
}
    

Pays de l'adresse IP et de l'IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays de l’adresse IP du client et du pays de l’IBAN du client.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.

Elle va vérifier l’appartenance de la combinaison du pays de l’adresse IP et du pays de l’IBAN à une liste de combinaisons de pays autorisés ou interdits.

Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage . Dans ce cas-là, Une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur . En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de l’adresse IP du client et le pays de l’IBAN.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer les combinaisons de pays d'adresse IP et de pays de l'IBAN autorisés ou interdits. Pour cela, vous devez :
    • paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
  • et transmettre l'adresse IP de l'acheteur dans la requête, si vous êtes sur Sogenactif Office Serveur .

Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) . Un même couple de pays ne peut se trouver que dans l’une des deux listes.

Restitution du résultat

Mode de configuration simple :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
La combinaison du pays de l’adresse IP et du pays de l'IBAN est interdite 58 Négatif IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
Le pays de l’adresse IP et/ou le pays de l'IBAN n’est/ne sont pas connu(s) -- Neutre
La combinaison du pays de l’adresse IP et du pays de l'IBAN est autorisée -- Neutre

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) -- Neutre NOT_APPLICABLE
La combinaison du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » 58 Négatif IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
Le pays de l'adresse IP et/ou le pays de l'IBAN n’est/ne sont pas connu(s) -- Neutre
La combinaison du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » -- Neutre
La combinaison du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » 58 Positif

Cette règle n'alimente pas le champ complementaryInfo .

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons du pays de l’adresse IP et pays de l’IBAN. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les 2 paramètres applicables à cette règle sont :

  • mode par défaut (configuration simple) :
    • AllowedIpIbanCountryCombiList pour les combinaisons autorisées de pays d’adresse IP et de l’IBAN,
    • DeniedIpIbanCountryCombiList pour les combinaisons interdites de pays d’adresse IP et de l’IBAN,
  • mode de configuration avancée :
    • NDeniedIpIbanCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptIpIbanCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedIpIbanCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptIpIbanCountryCombiList pour la liste des pays non avantagés.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIpIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>>>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :

  • soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) ;
  • soit d'une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityIpIbanCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SimilarityIpIbanCountry
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SimilarityIpIbanCountry"]
}
    

Règles d'encours (vélocité)

Les règles d’encours calculent le cumul du montant ou de la quantité pour un aspect de la transaction sur une période (quelquefois deux) et le comparent à un seuil à ne pas dépasser. Ils vous permettent de superviser les activités d'un client, d’une adresse IP, d’une carte, etc.

Par exemple, des règles d’encours peuvent se déclencher si le montant cumulé dépensé sur une carte particulière dépasse 1 500€ sur les dernières 24 h ou si un client a passé plus de 10 transactions sur la semaine écoulée.

Il existe deux manières de calculer les encours :

  • par défaut, les encours sont calculés en prenant en compte les transactions d’une seule boutique ;
  • vous pouvez également calculer les encours en cumulant les activités de plusieurs boutiques. Un tel encours est dit « partagé ». Les encours partagés élargissent le périmètre de la surveillance.
Tip: lors du paramétrage d'un profil, vous avez la possibilité de prendre en compte les transactions refusées (en plus des transactions acceptées) dans les calculs.

Pour mettre en place un encours partagé, vous devez contacter votre gestionnaire de compte pour la configuration. Deux étapes sont à respecter :

  • tout d'abord créer un encours partagé en choisissant son type (encours par carte, encours par adresse IP, etc.) ;
  • puis associer l’encours partagé aux boutiques.

Lors de l'exécution d’un contrôle de lutte contre la fraude, si la règle d’encours partagé est active dans le profil de la boutique, les activités seront calculées et ajoutées avec les activités des autres boutiques du groupe.

5 encours partagés peuvent être mis en place par type de règle d’encours et par groupe commercial.

Encours carte

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant cumulé des transactions) de la carte.

La règle est exécutée sur toutes les transactions de paiement effectuées avec une carte. Le calcul de l’encours prend en compte les transactions qui ont été acceptées au préalable sur les périodes indiquées. Il est aussi possible d'ajouter les transactions refusées à ce calcul.

La règle contrôle l’activité d’une carte sur deux périodes distinctes. Vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions, ainsi que les périodes respectives, lors du paramétrage du profil.

Exemple

Le tableau suivant décrit l'évolution de l'historique de la carte de paiement dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour la même carte, pour un montant total de 500 € et par mois (30 j) :

Date de la transaction Détails du paiement Résultat de la règle Encours par carte
(nombre de transactions)
Encours par carte
(montant cumulé)
État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
Montant : 100 €
Carte : CB1
OK 1 100 € TR1 01/10/2018 CB1 100 €
07/10/2018 Transaction TR2
Montant : 400 €
Carte : CB2
OK 1 400 € TR1 01/10/2018 CB1 100 € OK
TR2 07/10/2018 CB2 400 €
10/10/2018 Transaction TR3
Montant : 400 €
Carte : CB2
KO 2 800 €
(> 500)
TR1 01/10/2018 CB1 100 € OK
TR2 07/10/2018 CB2 400 € OK
TR3 10/10/2018 CB2 400 €
12/10/2018 Transaction TR4
Montant : 200 €
Carte : CB1
OK 2 300 € TR1 01/10/2018 CB1 100 € OK
TR2 07/10/2018 CB2 400 € OK
TR3 10/10/2018 CB2 400 € KO
TR4 12/10/2018 CB1 200 €
15/10/2018 Transaction TR5
Montant : 100 €
Carte : CB1
KO 3
(> 2)
400 € TR1 01/10/2018 CB1 100 € OK
TR2 07/10/2018 CB2 400 €
TR3 10/10/2018 CB2 400 € KO
TR4 12/10/2018 CB1 200 € OK
TR5 15/10/2018 CB1 100 €
02/11/2018
(> 30j)
Transaction TR6
Montant : 300 €
Carte : CB1
OK 1 300 € TR6 02/11/2018 CB1 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • et paramétrer le nombre de transactions effectuées et/ou le montant cumulé, ainsi que les périodes respectives, via l’onglet fraude du Portail Sogenactif .

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Montant cumulé maximal 0.01 sur la période en devise du commerçant 9999999
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal de transactions 1 transaction sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cette carte sur la période dépasse(nt) la/les limite(s) acceptée(s) 02 Négatif TRANS=A:B;
CUMUL=C:D*
Le nombre des transactions effectuées et la somme des montants cumulés avec cette carte sur la période sont inférieurs aux limites acceptées -- Neutre

*A : le nombre de transactions effectuées avec cette carte sur la période.

B : le nombre maximum de transactions acceptées avec une carte sur la période.

C : la somme des montants cumulés sur la période avec cette carte.

D : la somme maximum des montants cumulés acceptés avec une carte sur la période.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityCard .

Exemple en version POST

      fraudData.bypassCtrlList=VelocityCard
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityCard</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["VelocityCard"]
}
    

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, l’annulation et le remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Encours par adresse IP

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre des transactions et/ou le montant cumulé des transactions) d’un client à partir d’une adresse IP sur une période.

La règle est exécutée sur toutes les transactions de paiement. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir d’une adresse IP sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

Exemple

Le tableau suivant décrit l'évolution de l'historique d'adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour la même IP, pour un montant total de 500 € et par mois (30 j) :

Date de la transaction Détails du paiement Résultat de la règle Encours par adresse IP
(nombre de transactions)
Encours par adresse IP
(montant cumulé)
État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
Montant : 100 €
IP : 105.24.68.102
OK 1 100 € TR1 01/10/2018 105.24.68.102 100 €
07/10/2018 Transaction TR2
Montant : 400 €
IP : 254.24.78.175
OK 1 400 € TR1 01/10/2018 105.24.68.102 100 € OK
TR2 07/10/2018 254.24.78.175 400 €
10/10/2018 Transaction TR3
Montant : 400 €
IP : 254.24.78.175
KO 2 800 €
(> 500)
TR1 01/10/2018 105.24.68.102 100 € OK
TR2 07/10/2018 254.24.78.175 400 € OK
TR3 10/10/2018 254.24.78.175 400 €
12/10/2018 Transaction TR4
Montant : 200 €
IP : 105.24.68.102
OK 2 300 € TR1 01/10/2018 105.24.68.102 100 € OK
TR2 07/10/2018 254.24.78.175 400 € OK
TR3 10/10/2018 254.24.78.175 400 € KO
TR4 12/10/2018 105.24.68.102 200 €
15/10/2018 Transaction TR5
Montant : 100 €
IP : 105.24.68.102
KO 3
(> 2)
400 € TR1 01/10/2018 105.24.68.102 100 € OK
TR2 07/10/2018 254.24.78.175 400 € OK
TR3 10/10/2018 254.24.78.175 400 € KO
TR4 12/10/2018 105.24.68.102 200 € OK
TR5 15/10/2018 105.24.68.102 100 €
02/11/2018
(> 30j)
Transaction TR6
Montant : 300 €
IP : 105.24.68.102
OK 1 300 € TR6 02/11/2018 105.24.68.102 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Montant cumulé maximal 0.01 sur la période en devise du commerçant 9999999
Nombre maximal de transactions 1 transaction sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cette adresse IP sur la période dépasse(nt) la/les limite(s) acceptée(s) 16 Négatif NOT_APPLICABLE
Le nombre des transactions effectuées et la somme des montants cumulés avec cette adresse IP sur la période sont inférieurs aux limites acceptées -- Neutre TRANS=A:B;
CUMUL=C:D*
L'adresse IP n'est pas renseignée (en Sogenactif Office Serveur ) -- Neutre

*A : le nombre de transactions effectuées avec cette adresse IP sur la période.

B : le nombre maximum de transactions acceptées avec une adresse IP sur la période.

C : la somme des montants cumulés sur la période avec cette adresse IP.

D : la somme maximum des montants cumulés acceptés avec une adresse IP sur la période.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityIp .

Exemple en version POST

      fraudData.bypassCtrlList=VelocityIp
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityIp</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["VelocityIp"]
}
    

Limites d'utilisation

L'historique d'adresse IP n'est pas mis à jour lors des opérations de remboursement, d'annulation ou de validation, qu'elles soient partielles ou totales.

Encours par identifiant client

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre des transactions et/ou le montant cumulé des transactions) d’un client à partir de son identifiant client sur une période donnée.

La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’identifiant client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir d’un identifiant client sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période.

Exemple

Le tableau suivant décrit l'évolution de l'historique d'ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois maximum pour le même client, pour un montant maximum de 500 € et par mois (30 j) :

Date de la transaction Détails du paiement Résultat de la règle Encours par client
(nombre de transactions)
Encours par client
(montant cumulé)
État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
Montant : 100 €
CustomerID : cust1
OK 1 100 € TR1 01/10/2018 cust1 100 €
07/10/2018 Transaction TR2
Montant : 400 €
CustomerID : cust2
OK 1 400 € TR1 01/10/2018 cust1 100 € OK
TR2 07/10/2018 cust2 400 €
10/10/2018 Transaction TR3
Montant : 400 €
CustomerID : cust2
KO 2 800 €
(> 500)
TR1 01/10/2018 cust1 100 € OK
TR2 07/10/2018 cust2 400 € OK
TR3 10/10/2018 cust2 400 €
12/10/2018 Transaction TR4
Montant : 200 €
CustomerID : cust1
OK 2 300 € TR1 01/10/2018 cust1 100 € OK
TR2 07/10/2018 cust2 400 € OK
TR3 10/10/2018 cust2 400 € KO
TR4 12/10/2018 cust1 200 €
15/10/2018 Transaction TR5
Montant : 100 €
CustomerID : cust1
KO 3
(> 2)
400 € TR1 01/10/2018 cust1 100 € OK
TR2 07/10/2018 cust2 400 € OK
TR3 10/10/2018 cust2 400 € KO
TR4 12/10/2018 cust1 200 € OK
TR5 15/10/2018 cust1 100 €
02/11/2018
(> 30j)
Transaction TR6
Montant : 300 €
CustomerID : cust1
OK 1 300 € TR6 02/11/2018 cust1 300 

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId ).

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Montant cumulé maximal 0.01 sur la période en devise du commerçant 9999999
Nombre maximal de transactions 1 transaction sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
L’identifiant client n’est pas fourni -- Neutre NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cet identifiant client sur la période dépasse(nt) la/les limite(s) acceptée(s) 20 Négatif TRANS=A:B;
CUMUL=C:D
Le nombre des transactions effectuées et la somme des montants cumulés avec cet identifiant client sur la période sont inférieures aux limites acceptées -- Neutre

A : le nombre de transactions effectuées avec cet identifiant client sur la période.

B : le nombre maximum de transactions acceptées avec un identifiant client sur la période.

C : la somme des montants cumulés sur la période avec cet identifiant client.

D : la somme maximum des montants cumulés acceptés avec un identifiant client sur la période.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityCustomerId .

Exemple en version POST

      fraudData.bypassCtrlList=VelocityCustomerId
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>VelocityCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["VelocityCustomerId"]
}
    

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, l’annulation et le remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Nombre de clients par carte

Description de la règle

Cette règle vous permet de vérifier qu’une carte donnée n’est pas utilisée par un nombre trop élevé de clients différents sur une période.

La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’identifiant client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir du numéro de carte et de l’identifiant du client sur une période donnée.

Exemple

Le tableau suivant décrit l'évolution de l'historique d'ID client/carte dans le cas où vous avez choisi de limiter les achats sur votre site à 3 clients par mois (30 j) avec la même carte :

Date de la transaction Détails du paiement Résultat de la règle Clients/carte État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
CustomerID : cust1
Carte : CB1
OK 1 TR1 01/10/2018 cust1 CB1
07/10/2018 Transaction TR2
CustomerID : cust2
Carte : CB2
OK 2 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1
12/10/2018 Transaction TR3
CustomerID : cust3
Carte : CB1
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1
20/10/2018 Transaction TR4
CustomerID : cust4
Carte : CB1
KO 4
(> 3)
TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1 OK
TR4 20/10/2018 cust4 CB1
25/10/2018 Transaction TR5
CustomerID : cust4
Carte : CB2
OK 1 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1 OK
TR4 20/10/2018 cust4 CB1 KO
TR5 25/10/2018 cust4 CB2
27/10/2018 Transaction TR6
CustomerID : cust1
Carte : CB1
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1 OK
TR4 20/10/2018 cust4 CB1 KO
TR5 25/10/2018 cust4 CB2 OK
TR6 27/10/2018 cust1 CB1
02/03/2018
(> 30j)
Transaction TR7
CustomerID : cust5
Carte : CB1
OK 1 TR7 02/03/2018 cust5 CB1

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId ).

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal de clients 1 client sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
Le nombre de clients différents utilisant la même carte sur la période dépasse la limite acceptée 21 Négatif MAX=A:B*
Le nombre de clients différents utilisant la même carte sur la période est inférieur à la limite acceptée -- Neutre
L'identifiant client n'est pas renseigné -- Neutre

*A : le nombre de clients ayant utilisé la même carte sur la période.

B : le nombre maximum de clients acceptés pour la même carte.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxCustomerIdPerCard .

Exemple en version POST

      fraudData.bypassCtrlList=MaxCustomerIdPerCard
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxCustomerIdPerCard</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxCustomerIdPerCard"]
}
    

Limites d'utilisation

L'historique CustomerID/Carte d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de cartes par client

Description de la règle

Cette règle vous permet de vérifier qu’un client donné n’utilise pas un nombre trop élevé de cartes différentes sur une période.

La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’identifiant client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir du numéro de carte et de l’identifiant du client sur une période donnée.

Exemple

Le tableau suivant décrit l'évolution de l'historique Cartes/ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 3 cartes par mois (30 j) pour un même client :

Date de la transaction Détails du paiement Résultat de la règle Cartes/client État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
ID client : cust1
Carte : CB1
OK 1 TR1 01/10/2018 cust1 CB1
07/10/2018 Transaction TR2
ID client : cust1
Carte : CB2
OK 2 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2
12/10/2018 Transaction TR3
ID client : cust1
Carte : CB3
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3
20/10/2018 Transaction TR4
ID client : cust1
Carte : CB4
KO 4
(> 3)
TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3 OK
TR4 20/10/2018 cust1 CB4
25/10/2018 Transaction TR5
ID client : cust2
Carte : CB4
OK 1 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3 OK
TR4 20/10/2018 cust1 CB4 KO
TR5 25/10/2018 cust2 CB4
27/10/2018 Transaction TR6
ID client : cust1
Carte : CB1
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3 OK
TR4 20/10/2018 cust1 CB4 KO
TR5 25/10/2018 cust2 CB4 OK
TR6 27/10/2018 cust1 CB1
02/03/2018
(> 30 j)
Transaction TR7
ID client : cust1
Carte : CB5
OK 1 TR7 02/03/2018 cust1 CB5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du Portail Sogenactif ,
  • et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId ).

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal de cartes 1 carte sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
Le nombre de cartes différentes utilisées par le même client sur la période dépasse la limite acceptée 22 Négatif MAX=A:B*
Le nombre de cartes différentes utilisées par le même client sur la période est inférieur à la limite acceptée -- Neutre
L'identifiant client n'est pas renseigné -- Neutre

*A : le nombre de cartes utilisées par le même client sur la période.

B : le nombre maximum de cartes acceptées pour le même client.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxCardPerCustomerId .

Exemple en version POST

      fraudData.bypassCtrlList=MaxCardPerCustomerId
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxCardPerCustomerId"]
}
    

Limites d'utilisation

L'historique Cartes/CustomerID d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de cartes par adresse IP

Description de la règle

Cette règle vous permet de vérifier que des transactions en provenance d’une IP donnée n’utilisent pas un nombre trop élevé de cartes différentes sur une période.

La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’adresse IP de client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir du numéro de carte et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

Exemple

Le tableau suivant décrit l'évolution de l'historique Cartes/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 cartes par mois (30 j), pour un même client :

Date de la transaction Détails du paiement Résultat de la règle Cartes/IP État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
IP : 105.24.68.102
Carte : CB1
OK 1 TR1 01/10/2018 105.24.68.102 CB1
07/10/2018 Transaction TR2
IP : 105.24.68.102
Carte : CB2
OK 2 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2
12/10/2018 Transaction TR3
IP : 105.24.68.102
Carte : CB3
OK 3 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3
20/10/2018 Transaction TR4
IP : 105.24.68.102
Carte : CB4
KO 4
(> 3)
TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4
25/10/2018 Transaction TR5
IP : 254.24.78.175
Carte : CB4
OK 1 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4 KO
TR5 25/10/2018 254.24.78.175 CB4
27/10/2018 Transaction TR6
IP : 105.24.68.102
Carte : CB1
OK 3 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4 KO
TR5 25/10/2018 254.24.78.175 CB4 OK
TR6 27/10/2018 105.24.68.102 CB1
02/03/2018
(> 30 j)
Transaction TR7
IP : 105.24.68.102
Carte : CB5
OK 1 TR7 02/03/2018 105.24.68.102 CB5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal de cartes 1 carte sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
Le nombre de cartes différentes provenant de la même adresse IP sur la période dépasse la limite acceptée 45 Négatif MAX=A:B*
Le nombre de cartes différentes provenant de la même adresse IP sur la période est inférieur à la limite acceptée -- Neutre
L’adresse IP n’est pas renseignée (en Sogenactif Office Serveur ) -- Neutre

*A : le nombre de cartes utilisées par la même adresse IP sur la période.

B : le nombre maximum de cartes acceptées pour la même adresse IP.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxCardPerIp .

Exemple en version POST

      fraudData.bypassCtrlList=MaxCardPerIp
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerIp</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxCardPerIp"]
}
    

Limites d'utilisation

L'historique Cartes/adresse IP d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre d'IBAN par adresse IP

Description de la règle

Cette règle vous permet de vérifier que des transactions en provenance d’une adresse IP donnée n’utilisent pas un nombre trop élevé d’IBAN différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

Exemple

Le tableau suivant décrit l'évolution de l'historique IBAN/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 IBAN par mois (30 j), pour une même adresse IP :

Date de la transaction Détails du paiement Résultat de la règle IBAN/IP État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
IP : 105.24.68.102
IBAN : IBAN1
OK 1 TR1 01/10/2018 105.24.68.102 IBAN1
07/10/2018 Transaction TR2
IP : 105.24.68.102
IBAN : IBAN2
OK 2 TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2
12/10/2018 Transaction TR3
IP : 105.24.68.102
IBAN : IBAN3
OK 3 TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2 OK
TR3 12/10/2018 105.24.68.102 IBAN3
20/10/2018 Transaction TR4
IP : 105.24.68.102
IBAN : IBAN4
KO 4
(> 3)
TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2 OK
TR3 12/10/2018 105.24.68.102 IBAN3 OK
TR4 20/10/2018 105.24.68.102 IBAN4
25/10/2018 Transaction TR5
IP : 254.24.78.175
IBAN : IBAN4
OK 1 TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2 OK
TR3 12/10/2018 105.24.68.102 IBAN3 OK
TR4 20/10/2018 105.24.68.102 IBAN4 KO
TR5 25/10/2018 254.24.78.175 IBAN4
27/10/2018 Transaction TR6
IP : 105.24.68.102
IBAN : IBAN1
OK 3 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4 KO
TR5 25/10/2018 254.24.78.175 CB4 OK
TR6 27/10/2018 105.24.68.102 CB1
02/03/2018
(> 30 j)
Transaction TR7
IP : 105.24.68.102
IBAN : IBAN5
OK 1 TR7 02/03/2018 105.24.68.102 IBAN5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal d'IBAN 1 IBAN sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) -- Neutre NOT_APPLICABLE
Le nombre d’IBAN différents provenant de la même adresse IP sur la période dépasse la limite acceptée 59 Négatif MAX=A:B*
L’adresse IP n’est pas renseignée (en Sogenactif Office Serveur ) -- Neutre
Le nombre d’IBAN différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée -- Neutre

*A : le nombre de d'IBAN utilisés par la même adresse IP sur la période.

B : le nombre maximum d'IBAN acceptés pour la même adresse IP.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxIbanPerIp .

Exemple en version POST

      fraudData.bypassCtrlList=MaxIbanPerIp
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerIp</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxIbanPerIp"]
}
    

Limites d'utilisation

L'historique IBAN/adresse IP n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre d'adresses IP par IBAN

Description de la règle

Cette règle vous permet de vérifier qu’un IBAN n’est pas utilisé par un nombre trop élevé d’adresses IP différentes sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

Exemple

Le tableau suivant décrit l'évolution de l'historique adresse IP/IBAN dans le cas où vous avez choisi de limiter les achats sur votre site à 3 adresses IP par mois (30 j) pour un même IBAN :

Date de la transaction Détails du paiement Résultat de la règle IP/IBAN État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
IP : 105.24.68.101
IBAN : IBAN1
OK 1 TR1 01/10/2018 105.24.68.101 IBAN1
07/10/2018 Transaction TR2
IP : 105.24.68.102
IBAN : IBAN1
OK 2 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1
12/10/2018 Transaction TR3
IP : 105.24.68.103
IBAN : IBAN1
OK 3 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1
20/10/2018 Transaction TR4
IP : 105.24.68.104
IBAN : IBAN1
KO 4
(> 3)
TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1 OK
TR4 20/10/2018 105.24.68.104 IBAN1
25/10/2018 Transaction TR5
IP : 105.24.68.104
IBAN : IBAN2
OK 1 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1 OK
TR4 20/10/2018 105.24.68.104 IBAN1 KO
TR5 25/10/2018 105.24.68.104 IBAN2
27/10/2018 Transaction TR6
IP : 105.24.68.101
IBAN : IBAN1
OK 3 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1 OK
TR4 20/10/2018 105.24.68.104 IBAN1 KO
TR5 25/10/2018 105.24.68.104 IBAN2
TR6 27/10/2018 105.24.68.101 IBAN1
02/03/2018
(> 30 j)
Transaction TR7
IP : 105.24.68.105
IBAN : IBAN1
OK 1 TR7 02/03/2018 105.24.68.105 IBAN1

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre maximum d'adresses IP et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal d'adresses IP 1 adresse IP sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) -- Neutre NOT_APPLICABLE
Le nombre d’adresses IP différentes avec le même IBAN sur la période dépasse la limite acceptée 60 Négatif MAX=A:B*
L’adresse IP n’est pas renseignée (en Sogenactif Office Serveur ) -- Neutre
Le nombre d’adresses IP différentes avec le même IBAN sur la période est inférieur à la limite acceptée -- Neutre

*A : le nombre d'adresses IP utilisées par le même IBAN sur la période.

B : le nombre maximum d'adresses IP acceptées pour le même IBAN.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxIpPerIban.

Exemple en version POST

      fraudData.bypassCtrlList=MaxIpPerIban
    

Exemple en version SOAP

      <urn:fraudData>
     <urn:bypassCtrlList>MaxIpPerIban</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON

      fraudData": {
   "bypassCtrlList":["MaxIpPerIban"]
}
    

Limites d'utilisation

L'historique adresse IP/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de clients par IBAN

Description de la règle

Cette règle vous permet de vérifier qu’un IBAN n’est pas utilisé par un nombre trop élevé de clients différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client et l’identifiant du client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

Exemple

Le tableau suivant décrit l'évolution de l'historique ID client/IBAN dans le cas où vous avez choisi de limiter les achats sur votre site à 3 clients par mois (30 j) avec le même IBAN :

Date de la transaction Détails du paiement Résultat de la règle Clients/IBAN État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
ID client : cust1
IBAN : IBAN1
OK 1 TR1 01/10/2018 cust1 IBAN1
07/10/2018 Transaction TR2
ID client : cust2
IBAN : IBAN1
OK 2 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1
12/10/2018 Transaction TR3
ID client : cust3
IBAN : IBAN1
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1
20/10/2018 Transaction TR4
ID client : cust4
IBAN : IBAN1
KO 4
(> 3)
TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1 OK
TR4 20/10/2018 cust4 IBAN1
25/10/2018 Transaction TR5
ID client : cust4
IBAN : IBAN2
OK 1 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1 OK
TR4 20/10/2018 cust4 IBAN1 KO
TR5 25/10/2018 cust4 IBAN2
27/10/2018 Transaction TR6
ID client : cust1
IBAN : IBAN1
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1 OK
TR4 20/10/2018 cust4 IBAN1 KO
TR5 25/10/2018 cust4 IBAN2 OK
TR6 27/10/2018 cust1 IBAN1
02/03/2018
(> 30 j)
Transaction TR7
ID client : cust5
IBAN : IBAN1
OK 1 TR7 02/03/2018 cust5 IBAN1

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’identifiant client dans la requête (champ customerId ).

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal de clients 1 client sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) -- Neutre NOT_APPLICABLE
Le nombre de clients différents utilisant le même IBAN sur la période dépasse la limite acceptée 61 Négatif MAX=A:B*
L’identifiant client n’est pas renseigné -- Neutre
Le nombre de clients différents utilisant le même IBAN sur la période est inférieur à la limite acceptée -- Neutre

*A : le nombre de clients utilisant le même IBAN sur la période.

B : le nombre maximum de clients acceptés pour le même IBAN.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryIbanCountry .

  • Exemple en version POST :
      fraudData.bypassCtrlList=MaxCustidPerIban
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>MaxCustidPerIban</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["MaxCustidPerIban"]
}
    

Limites d'utilisation

L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre d'IBAN par client

Description de la règle

Cette règle vous permet de vérifier qu’un client n’utilise pas un nombre trop élevé d’IBAN différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’identifiant du client est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir de l’identifiant client (customerId) et de l’IBAN sur une période donnée.

Exemple

Le tableau suivant décrit l'évolution de l'historique IBAN/ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 3 IBAN par mois (30 j) pour un client :

Date de la transaction Détails du paiement Résultat de la règle IBAN/client État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
ID client : cust1
IBAN : IBAN1
OK 1 TR1 01/10/2018 cust1 IBAN1
07/10/2018 Transaction TR2
ID client : cust1
IBAN : IBAN2
OK 2 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2
12/10/2018 Transaction TR3
ID client : cust1
IBAN : IBAN3
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3
20/10/2018 Transaction TR4
ID client : cust1
IBAN : IBAN4
KO 4
(> 3)
TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3 OK
TR4 20/10/2018 cust1 IBAN4
25/10/2018 Transaction TR5
ID client : cust2
IBAN : IBAN4
OK 1 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3 OK
TR4 20/10/2018 cust1 IBAN4 KO
TR5 25/10/2018 cust2 IBAN4
27/10/2018 Transaction TR6
ID client : cust1
IBAN : IBAN1
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3 OK
TR4 20/10/2018 cust1 IBAN4 KO
TR5 25/10/2018 cust2 IBAN4 OK
TR6 27/10/2018 cust1 IBAN1
02/03/2018
(> 30 j)
Transaction TR7
ID client : cust1
IBAN : IBAN5
OK 1 TR7 02/03/2018 cust1 IBAN5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du Portail Sogenactif
  • et transmettre l’identifiant client dans la requête (champ customerI d).

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal d'IBAN 1 IBAN sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) -- Neutre NOT_APPLICABLE
Le nombre d’IBAN différents utilisés par le même client sur la période dépasse la limite acceptée 62 Négatif MAX=A:B*
L’identifiant client n’est pas renseigné -- Neutre
Le nombre d’IBAN différents utilisés par le même client sur la période est inférieur à la limite acceptée -- Neutre

*A : le nombre d'IBAN utilisés pour un même client sur la période.

B : le nombre maximum d'IBAN acceptés pour le même client.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxIbanPerCustid .

  • Exemple en version POST :
      fraudData.bypassCtrlList=MaxIbanPerCustid
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerCustid</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["MaxIbanPerCustid"]
}
    

Limites d'utilisation

L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Nombre de mandats par adresse IP

Description de la règle

Cette règle vous permet de vérifier qu’une adresse IP n’utilise pas un nombre trop élevé de mandats SDD, désignés par leurs RUM (Référence Unique de Mandat), différents sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité à partir du mandat et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

Exemple

Le tableau suivant décrit l'évolution de l'historique mandat/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 mandats par mois (30 j) pour une adresse IP :

Date de la transaction Détails du paiement Résultat de la règle Mandats/IP État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
IP : 105.24.68.102
Mandat : RUM1
OK 1 TR1 01/10/2018 105.24.68.102 RUM1
07/10/2018 Transaction TR2
IP : 105.24.68.102
Mandat : RUM2
OK 2 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2
12/10/2018 Transaction TR3
IP : 105.24.68.102
Mandat : RUM3
OK 3 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3
20/10/2018 Transaction TR4
IP : 105.24.68.102
Mandat : RUM4
KO 4
(> 3)
TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3 OK
TR4 20/10/2018 105.24.68.102 RUM4
25/10/2018 Transaction TR5
IP : 254.24.78.175
Mandat : RUM4
OK 1 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3 OK
TR4 20/10/2018 105.24.68.102 RUM4 KO
TR5 25/10/2018 254.24.78.175 RUM4
27/10/2018 Transaction TR6
IP : 105.24.68.102
Mandat : RUM1
OK 3 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3 OK
TR4 20/10/2018 105.24.68.102 RUM4 KO
TR5 25/10/2018 254.24.78.175 RUM4 OK
TR6 27/10/2018 105.24.68.102 RUM1
02/03/2018
(> 30 j)
Transaction TR7
IP : 105.24.68.102
Mandat : RUM5
OK 1 TR7 02/03/2018 105.24.68.102 RUM5

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet 'Fraude' du Portail Sogenactif ,
  • paramétrer le nombre maximum de mandats et la durée du cumul également via l’onglet 'Fraude' du Portail Sogenactif
  • et transmettre l’adresse IP de l'acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Nombre maximal de mandats 1 mandat sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) -- Neutre NOT_APPLICABLE
Le nombre de mandats différents provenant de la même adresse IP sur la période dépasse la limite acceptée 63 Négatif MAX=A:B*
L'adresse IP n’est pas renseignée -- Neutre
Le nombre de mandats différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée -- Neutre

*A : le nombre de mandats utilisés pour une même adresse IP sur la période.

B : le nombre maximum de mandats acceptés pour la même adresse IP.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxMandatePerIp .

  • Exemple en version POST :
      fraudData.bypassCtrlList=MaxMandatePerIp
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>MaxMandatePerIp</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["MaxMandatePerIp"]
}
    

Limites d'utilisation

L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.

Encours par mandat

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant des transactions cumulé) du mandat SDD, désigné par son RUM (Référence Unique de Mandat), sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité d’un mandat sur une période donnée. Vous devez obligatoirement fournir le nombre des transactions et/ou le montant des transactions cumulé et la durée de la période lors du paramétrage du profil.

Exemple

Le tableau suivant décrit l'évolution de l'historique du mandat dans le cas où vous avez choisi de limiter les achats sur votre site à 3 fois pour un même mandat, pour un montant total de 500 € et par mois (30 j) :

Date de la transaction Détails du paiement Résultat de la règle Encours par mandat
(nombre de transactions)
Encours par mandat
(montant cumulé)
État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
Montant : 100 €
Mandat : RUM1
OK 1 100 € TR1 01/10/2018 RUM1 100 €
07/10/2018 Transaction TR2
Montant : 400 €
Mandat : RUM2
OK 1 400 € TR1 01/10/2018 RUM1 100 € OK
TR2 07/10/2018 RUM2 400 €
10/10/2018 Transaction TR3
Montant : 400 €
Mandat : RUM2
KO 2 800 €
(> 500)
TR1 01/10/2018 RUM1 100 € OK
TR2 07/10/2018 RUM2 400 € OK
TR3 10/10/2018 RUM2 400 €
12/10/2018 Transaction TR4
Montant : 200 €
Mandat : RUM1
OK 2 300 € TR1 01/10/2018 RUM1 100 € OK
TR2 07/10/2018 RUM2 400 € OK
TR3 10/10/2018 RUM2 400 € KO
TR4 12/10/2018 RUM1 200 €
15/10/2018 Transaction TR5
Montant : 100 €
Mandat : RUM1
KO 3
(> 2)
400 € TR1 01/10/2018 RUM1 100 € OK
TR2 07/10/2018 RUM2 400 € OK
TR3 10/10/2018 RUM2 400 € KO
TR4 12/10/2018 RUM1 200 € OK
TR5 15/10/2018 RUM1 100 €
02/11/2018
(> 30)
Transaction TR6
Montant : 300 €
Mandat : RUM1
OK 1 300 € TR6 02/11/2018 RUM1 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Portail Sogenactif

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Montant cumulé maximal 0.01 sur la période en devise du commerçant 9999999
Nombre maximal de transactions 1 transaction sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) -- Neutre NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec ce mandat sur la période dépasse(nt) la/les limite(s) acceptée(s) 64 Négatif TRANS=A:B;
CUMUL=C:D*
Le nombre des transactions effectuées et la somme des montants cumulés avec ce mandat sur la période sont inférieurs aux limites acceptées -- Neutre

*A : le nombre de transactions effectuées avec ce mandat sur la période.

B : le nombre maximum de transactions acceptées avec un mandat sur la période.

C : la somme des montants cumulés sur la période avec ce mandat.

D : la somme maximum des montants cumulés acceptés avec un mandat sur la période.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityMandate .

  • Exemple en version POST :
      fraudData.bypassCtrlList=VelocityMandate
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>VelocityMandate</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["VelocityMandate"]
}
    

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, de l’annulation et du remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Encours par IBAN

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant cumulé des transactions) de l’IBAN sur une période.

La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.

La règle contrôle l’activité d’un IBAN sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période.

Exemple

Le tableau suivant décrit l'évolution de l'historique du mandat dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour un même IBAN, pour un montant total de 500 € et par mois (30 j) :

Date de la transaction Détails du paiement Résultat de la règle Encours par IBAN
(nombre de transactions)
Encours par IBAN
(montant cumulé)
État de l'historique
(30 derniers jours)
01/10/2018 Transaction TR1
Montant : 100 €
IBAN : IBAN1
OK 1 100 € TR1 01/10/2018 IBAN1 100 €
07/10/2018 Transaction TR2
Montant : 400 €
IBAN : IBAN2
OK 1 400 € TR1 01/10/2018 IBAN1 100 € OK
TR2 07/10/2018 IBAN2 400 €
10/10/2018 Transaction TR3
Montant : 400 €
IBAN : IBAN2
KO 2 800 €
(> 500)
TR1 01/10/2018 IBAN1 100 € OK
TR2 07/10/2018 IBAN2 400 € OK
TR3 10/10/2018 IBAN2 400 €
12/10/2018 Transaction TR4
Montant : 200 €
IBAN : IBAN1
OK 2 300 € TR1 01/10/2018 IBAN1 100 € OK
TR2 07/10/2018 IBAN2 400 € OK
TR3 10/10/2018 IBAN2 400 € KO
TR4 12/10/2018 IBAN1 200 €
15/10/2018 Transaction TR5
Montant : 100 €
IBAN : IBAN1
KO 3
(> 2)
400 € TR1 01/10/2018 IBAN1 100 € OK
TR2 07/10/2018 IBAN2 400 € OK
TR3 10/10/2018 IBAN2 400 € KO
TR4 12/10/2018 IBAN1 200 € OK
TR5 15/10/2018 IBAN1 100 €
02/11/2018
(> 30)
Transaction TR6
Montant : 300 €
IBAN : IBAN1
OK 1 300 € TR6 02/11/2018 IBAN1 300 €

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Portail Sogenactif .

Paramètre Valeur minimale Valeur maximale
Période En heures : 1 heure
En jours : 1 jour
En semaines : 1 semaine
En heures : 720 heures
En jours : 30 jours
En semaines : 4 semaines
Montant cumulé maximal 0.01 sur la période en devise du commerçant 9999999
Nombre maximal de transactions 1 transaction sur la période 9999

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) -- Neutre NOT_APPLICABLE
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cet IBAN sur la période dépasse(nt) la/les limite(s) acceptée(s) 65 Négatif TRANS=A:B;
CUMUL=C:D*
Le nombre des transactions effectuées et la somme des montants cumulés avec cet IBAN sur la période sont inférieurs aux limites acceptées -- Neutre

*A : le nombre de transactions effectuées avec cet IBAN sur la période.

B : le nombre maximum de transactions acceptées avec un IBAN sur la période.

C : la somme des montants cumulés sur la période avec cet IBAN.

D : la somme maximum des montants cumulés acceptés avec un IBAN sur la période.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityIban .

  • Exemple en version POST :
      fraudData.bypassCtrlList=VelocityIban
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>VelocityIban</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["VelocityIban"]
}
    

Limites d'utilisation

Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.

Lors de la validation, de l’annulation et du remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.

Règles diverses

Réputations d'adresse IP

Description de la règle

Cette règle vous permet de décider de refuser ou non un achat provenant d’une adresse IP dont la réputation est dangereuse.

La règle va interroger la base de réputations d’adresses IP afin de connaître la réputation de l’adresse IP de l’acheteur et vérifier l’appartenance de cette réputation de l’adresse IP à la liste des réputations d’adresses IP indésirables que vous avez définie. Cette adresse IP provient :

  • de la détection automatique via le navigateur de l’acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

En l’absence d’une liste de réputations d’IP indésirables, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste des réputations d'adresse IP indésirables via l’onglet fraude du Portail Sogenactif
  • et transmettre l’adresse IP de l'acheteur dans la requête (champ customerI pAddress), si vous êtes sur Sogenactif Office Serveur .

Pour connaître les réputations d’adresses IP paramétrables, veuillez-vous référer à l’Annexe 3 : réputations d'adresse IP.

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
L’information n’est pas connue -- Neutre IP_REP=XXX*
La réputation de l'adresse IP appartient à la liste des réputations d'adresse IP indésirables 44 Négatif
La réputation de l'adresse IP n'appartient pas à la liste des réputations d'adresse IP indésirables -- Neutre

* XXX : réputation d'adresse IP (voir Annexe 3 : réputations d'adresse IP)

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive IpReputations .

  • Exemple en version POST :
      fraudData.bypassCtrlList=IpReputations
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>IpReputations</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["IpReputations"]
}
    

Carte en opposition

Description de la règle

Cette règle vous permet de décider de refuser ou non un achat provenant d’une carte en opposition.

La règle est exécutée sur toutes les transactions de paiement avec carte CB, Visa et MasterCard.

La règle vérifie si la carte est présente dans la base des cartes en opposition.

Le fichier des cartes en opposition est alimenté en se basant sur la liste des cartes de l'opposition du réseau CB. La mise à jour du fichier est effectuée plusieurs fois par jour.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Portail Sogenactif .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
L’accès au serveur oppotota a échoué -- Neutre --
La carte est en opposition 11 Négatif
La carte n'est pas en opposition -- Neutre

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive HotList .

  • Exemple en version POST :
      fraudData.bypassCtrlList=HotList
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>HotList</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["HotList"]
}
    

Carte virtuelle

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation payée par un porteur de carte virtuelle émise par une banque Française.

La règle est exécutée sur toutes les transactions de paiement carte.

La règle vérifie dans la base de données de plages porteuses si la carte est une carte virtuelle.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Portail Sogenactif .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
L'information n'est pas connue -- Neutre --
La carte est une carte virtuelle dynamique 07 Négatif
La carte n'est pas une carte virtuelle dynamique -- Neutre

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive ECard .

  • Exemple en version POST :
      fraudData.bypassCtrlList=ECard
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>ECard</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["ECard"]
}
    

Carte à autorisation systématique

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation payée par un porteur de carte à autorisation systématique.

La règle est exécutée sur toutes les transactions de paiement carte.

La règle vérifie dans la base de données de plages porteuses si la carte est une carte à autorisation systématique.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Portail Sogenactif .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
L'information n'est pas connue -- Neutre --
La carte est une carte à autorisation systématique 14 Négatif
La carte n'est pas une carte à autorisation systématique -- Neutre

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SystematicAuthorizationCard .

  • Exemple en version POST :
      fraudData.bypassCtrlList=SystematicAuthorizationCard
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>SystematicAuthorizationCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["SystematicAuthorizationCard"]
}
    

Carte commerciale (et pays de la carte)

Description de la règle

Cette règle vous permet de décider de refuser ou non une prestation en se basant sur le fait que la carte soit :

  • une carte commerciale ;
  • une carte commerciale appartenant à une liste de pays émetteurs autorisés ou interdits.

La règle est exécutée sur toutes les transactions de paiement avec une carte.

La règle va d’abord interroger une base de données des informations de cartes afin de vérifier l’appartenance de la carte à une plage de BIN correspond aux cartes commerciales afin de déterminer s’il s’agit d’une carte commerciale. Selon le contrôle demandé, le serveur vérifie si le pays d'émission de cette carte commerciale appartient à votre liste des pays autorisés/interdits.

En l’absence de la liste des pays d’émission de la carte commerciale autorisés ou interdits, le serveur vérifie simplement si la carte est une carte commerciale.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste des pays d’émission de la carte commerciale autorisés ou interdits (si vous souhaitez intercepter les cartes commerciales de certains pays). Pour cela, vous devez :
    • paramétrer la liste via l’onglet fraude du Portail Sogenactif ,
    • ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
L'information n'est pas connue -- Neutre CARD_COUNTRY=XXX*
La carte est une carte commerciale, et la liste des pays de carte commerciale autorisés/interdits n’est pas définie 18 Négatif CARD_COUNTRY=XXX*
Le pays de la carte est dans la liste des pays de carte commerciale interdits ou n'est pas dans la liste des pays de carte commerciale autorisés 43 Négatif
Le pays de la carte n'est pas dans la liste des pays de carte commerciale interdits ou est dans la liste des pays carte commerciale autorisés -- Neutre
La carte n’est pas une carte commerciale -- Neutre

* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

Vous pouvez envoyer, dans la requête de paiement, la liste de pays de la carte commerciale. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.

Choisissez le paramètre à surcharger...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...et envoyez la liste des pays dans le champ suivant :

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

Les 2 paramètres applicables à cette règle sont :

  • AllowedCommercialCardCountryList pour la liste des pays de carte commerciale autorisés ;

  • DeniedCommercialCardCountryList pour la liste des pays de carte commerciale interdits.

  • Exemple en version POST :
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedCommercialCardCountryList,riskManagementDynamicValue=(FRA,BEL)}
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCommercialCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedCommercialCardCountryList”,
                    “riskManagementDynamicValue”:“(FRA,BEL)”
          }
     ]
}
    

Pour les 2 méthodes, la liste envoyée doit contenir :

  • soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. Annexe 7 : liste des codes pays prédéfinis).

En mode par défaut, l’envoi des 2 listes (autorisée et interdite) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

En mode de configuration avancée, l’envoi de 2 listes négatives (désavantagée et non désavantagée) ou de 2 listes positives (avantagée ou non avantagée) dans la même requête est considéré comme une erreur, dans ce cas la règle n’est pas exécutée.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CorporateCard .

➤ Exemple en version POST :

      fraudData.bypassCtrlList=CorporateCard
    

➤ Exemple en version SOAP :

      <urn:fraudData>
     <urn:bypassCtrlList>CorporateCard</urn:bypassCtrlList>
</urn:fraudData>
    

Exemple en version JSON :

      "fraudData": {
   "bypassCtrlList": ["CorporateCard"]
}
    

Plage de montants

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat par le contrôle du montant.

La règle va vérifier si le montant de la transaction se trouve dans la plage de montant que vous souhaitez.

En l’absence de paramétrage des limites minimum et maximum du montant, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • et paramétrer le montant minimum et/ou le montant maximum via l’onglet fraude du Portail Sogenactif .

Paramètre Valeur minimale Valeur maximale
Montant minimum 0.01 en devise du commerçant 9999999
Montant maximum 0.01 en devise du commerçant 9999999
Attention: en mode de configuration avancée, il est possible de paramétrer deux plages de montants. L’une ayant une influence positive (GO) et l’autre une négative (NOGO) , contrairement au mode de configuration simple, qui ne comporte qu’une seule plage négative (NOGO) de montants.

Restitution du résultat

Mode par défaut :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le montant de la transaction est hors de la plage des montants souhaités 25 Négatif MIN=A:B;MAX=A:C*
Le montant de la transaction est dans la plage des montants souhaités -- Neutre

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le montant de la transaction est dans la plage des montants désavantagés 25 Négatif MIN=A:B;MAX=A:C*
Le montant de la transaction est hors des plages de montants avantagés et désavantagés -- Neutre
Le montant de la transaction est dans la plage des montants avantagés 25 Positif

Cette règle n’alimente pas le champ complementaryInfo .

__________

* A : montant de la transaction.

B : montant minimum accepté.

C : montant maximum accepté.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CapCollerAmount .

  • Exemple en version POST :
      fraudData.bypassCtrlList=CapCollarAmount
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>CapCollarAmount</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["CapCollarAmount"]
}
    

Carte réseau CB

Description de la règle

Cette règle vous permet de décider de refuser ou non un achat provenant d’une carte du réseau CB.

La règle est exécutée sur toutes les transactions de paiement avec carte.

Elle vérifie dans la base des plages porteuses si la carte fait partie du réseau Carte Bancaire.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Portail Sogenactif .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
Le BIN de la carte n’est pas connu -- Neutre --
La carte ne fait pas partie du réseau carte bancaire 19 Négatif
La carte fait partie du réseau carte bancaire -- Neutre

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CBScheme .

  • Exemple en version POST :
      fraudData.bypassCtrlList=CBScheme
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>CBScheme</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["CBScheme"]
}
    

Adresse e-mail gratuite

Description de la règle

Cette règle vous permet de mesurer le risque de la fraude d’un achat provenant d’un client dont l’adresse e-mail est gratuite.

La règle vérifie si l’adresse e-mail du client fait partie d’un domaine d’adresses e-mail gratuites.

Les adresses e-mail vérifiées sont :

  • l’adresse e-mail du client ;
  • l’adresse e-mail du porteur du moyen de paiement (il est possible que le client utilise le moyen de paiement d’un proche) ;
  • l’adresse e-mail du contact de la facturation ;
  • l’adresse e-mail du contact de la livraison.

Si une des adresses e-mail disponibles est présente dans la liste, un résultat négatif sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et transmettre au moins une adresse e-mail de l’acheteur dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Au moins une adresse e-mail est présente dans la liste des adresses e-mail gratuites 27 Négatif --
Aucune adresse e-mail n’est présente dans la liste des adresses e-mail gratuites -- Neutre
Aucune adresse e-mail n’a été transmise -- Neutre

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive FreeEmail .

  • Exemple en version POST :
      fraudData.bypassCtrlList=FreeEmail
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>FreeEmail</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["FreeEmail"]
}
    

Authentification 3-D Secure

Description de la règle

Cette règle vous permet de mesurer le risque sur une transaction avec authentification 3-D Secure en fonction du statut de 3-D Secure. Ici, l’authentification 3-D Secure inclut les programmes d’authentification 3-D Secure de Visa, SecureCode de MasterCard, SafeKey d’American Express, authentification de Bancontact/Mister Cash, etc.

La règle est exécutée sur toutes les transactions de paiement carte avec une authentification 3-D Secure.

Elle vérifie si le statut d’authentification du porteur appartient à une liste de statuts refusés.

En l’absence de liste de statuts refusés, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer la liste des statuts d’authentification 3-D Secure interdits via l’onglet fraude du Portail Sogenactif .

Veuillez vous référer à l'Annexe 5 : statuts d'authentification 3-D Secure.

Attention: en mode de configuration avancée, il est possible de paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO) . Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO) .

Restitution du résultat

Mode par défaut (configuration simple) :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement ne propose pas d’authentification 3-D Secure ou vous ne participez pas au programme d’authentification 3-D Secure) -- Neutre NOT_APPLICABLE
Le statut 3-D Secure est interdit 17 Négatif --
Le statut 3-D Secure n'est pas interdit -- Neutre

Cette règle n’alimente pas le champ complementaryInfo .

Mode de configuration avancée :

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement ne propose pas d’authentification 3-D Secure ou vous ne participez pas au programme d’authentification 3-D Secure) -- Neutre NOT_APPLICABLE
Le statut 3-D Secure est dans la liste des statuts désavantagés 17 Négatif --
Le statut 3-D Secure n'est pas dans les listes de statuts avantagés et désavantagés -- Neutre
Le statut 3-D Secure est dans la liste des statuts avantagés 17 Positif

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive 3DSStatus .

  • Exemple en version POST :
      fraudData.bypassCtrlList=3DSStatus
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>3DSStatus</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["3DSStatus"]
}
    

Syntaxe d'adresse e-mail

Description de la règle

Cette règle vous permet de mesurer le risque en fonction de la validité des syntaxes des adresses e-mail de la transaction.

La règle va vérifier si la syntaxe des adresses e-mail de la transaction est valide.

Les adresses e-mail vérifiées sont :

  • l’adresse e-mail du client ;
  • l’adresse e-mail du porteur du moyen de paiement (il est possible que le client utilise le moyen de paiement d’un proche) ;
  • l’adresse e-mail du contact de la facturation ;
  • l’adresse e-mail du contact de la livraison.

Si une des adresses e-mail présentées a une syntaxe incorrecte, la règle retourne un résultat négatif.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et transmettre au moins une adresse e-mail de l’acheteur dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
La syntaxe de l’adresse e-mail est erronée 46 Négatif --
La syntaxe de l’adresse e-mail est correcte -- Neutre
Aucune adresse e-mail n’a été transmise -- Neutre

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive EmailSyntax .

  • Exemple en version POST :
      fraudData.bypassCtrlList=EmailSyntax
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>EmailSyntax</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["EmailSyntax"]
}
    

Vérification d'adresse (InfoScore)

Description de la règle

Le contrôle d'adresse, délégué à InfoScore, sert à vérifier l'adresse de livraison soumise lors d’une transaction ELV. Il est effectué à l'aide de la base de données AZ Direct GmbH, ce qui en limite le fonctionnement aux adresses allemandes.

Le contrôle ne s’effectue que pour les paiements ELV et les adresses de livraisons en Allemagne ( countryCode valant « DEU »).

Le résultat de la vérification d'adresse est retourné par InfoScore sous la forme d'un indicateur. Pour connaître les indicateurs, veuillez consulter l'Annexe 6 : InfoScore adresse vérification indicateur.

À l'aide des réglages, vous pourrez accepter ou refuser certaines valeurs.

Par exemple, vous pourrez choisir de ne faire confiance qu'aux adresses avec des contrôles PPB et PHB positifs.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • avoir souscrit à l'option InfoScore ;
  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste des indicateurs autorisés/interdits via l’onglet fraude du Portail Sogenactif

  • et transmettre l'adresse postale de livraison de l'acheteur dans la requête.

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (InfoScore ID absent ou l’adresse de livraison n’est pas en Allemagne) -- Neutre NOT_APPLICABLE
Information non connue -- Neutre IS_INDIC=XXX*
Le type d’adresse retourné par InfoScore fait partie de la liste des types interdits par la règle ou ne fait pas partie de la liste des types autorisés 48 Négatif IS_INDIC=XXX*
Le type d’adresse retourné par InfoScore fait partie de la liste des types autorisés par la règle ou ne fait pas partie de la liste des types interdits -- Neutre

* XXX : indicateur retourné par InfoScore.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive AddressVerification .

  • Exemple en version POST :
      fraudData.bypassCtrlList=AddressVerification
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>AddressVerification</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["AddressVerification"]
}
    

Vérification de compte (InfoScore)

Description de la règle

La vérification de compte, déléguée à InfoScore, sert à vérifier le compte de débit utilisé lors d’une transaction ELV. Il est effectué à l'aide de la base de données Rücklastschriften-Präventions-Pool (RPP) d’InfoScore Consumer Data GmbH (ICD).

Le contrôle ne s’effectue que pour les paiements ELV.

Le pool de prévention de rejet des débits directs RPP est un ensemble de données interprofessionnelles qui contient des informations bancaires relatives à différents secteurs d'activité et industries. L'objectif de RPP est d'empêcher les problèmes de connexion lors de l'utilisation de la méthode de paiement « débit direct ».

De plus, la base de données RPP contient des informations sur les comptes dits « non consommateurs » dont les références peuvent être publiques (ex. : comptes d’associations, compte gouvernemental, sociétés…).

Lorsqu'un compte est identifié, les informations sont retournées dans la réponse d’InfoScore vers Sogenactif .

Le contrôle retournera une valeur négative si :

  • le compte est un compte « non consommateur » ;
  • le compte fait partie du programme PAP (Proprietary Account Protection) : liste de comptes dont les propriétaires ont interdit l’utilisation sur Internet ;
  • le compte fait partie de la liste KUNO (Kriminalitätsbekämpfung im unbaren Zahlungsverkehr unter Nutzung nichtpolizeilicher Organisationen) : liste de comptes bloqués en Allemagne pour diverses raisons.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • avoir souscrit à l'option InfoScore ;
  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer la liste des indicateurs autorisés/interdits via l’onglet fraude du Portail Sogenactif .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (InfoScore ID absent) -- Neutre NOT_APPLICABLE
Information non connue -- Neutre VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*
Le compte n’est pas un compte consommateur, ou se trouve dans les listes PAP ou KUNO 49 Négatif VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*
Le compte est un compte consommateur -- Neutre

* AAA : resultCode InfoScore (00 = le compte bancaire est valide).

BBB : valeur de l’indicateur InfoScore NCA.

CCC : valeur du RppContentCode pour InfoScore NCA KO.

DDD : valeur de l’indicateur InfoScore PAP.

EEE : valeur du RppContentCode pour InfoScore PAP KO.

FFF : valeur de l'indicateur InfoScore RPP.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive AddressVerification .

  • Exemple en version POST :
      fraudData.bypassCtrlList=AccountVerification
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>AccountVerification</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["AccountVerification"]
}
    

Date d'expiration de la carte

Description de la règle

Cette règle vous permet de détecter les paiements dont la carte arrive à expiration dans les prochains mois. Elle est notamment utile dans le cadre d'un paiement en plusieurs fois afin de s’assurer que la carte sera toujours valide lors des prochaines échéances du paiement.

La règle est exécutée sur toutes les transactions carte.

Elle vérifie si le nombre de mois avant expiration de la carte est supérieur au nombre de mois que vous avez indiqués.

En l’absence de paramétrage du nombre de mois minimum avant expiration, la règle considère que ce nombre est de zéro.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer le nombre minimum de mois avant expiration de la carte via l’onglet fraude du Portail Sogenactif .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
La durée de validité du moyen de paiement est inférieure à la durée souhaitée 23 Négatif EXPIRY=AAA:BBB*
la durée de validité du moyen de paiement est supérieure à la durée souhaitée -- Neutre

* AAA : date d'expiration de la carte au format MMYY.

BBB : deadline pour le contrôle au format MMYY.

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive ExpiryDate .

  • Exemple en version POST :
      fraudData.bypassCtrlList=ExpiryDate
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>ExpiryDate</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["ExpiryDate"]
}
    

Règles de listes

Généralités

Le moteur de gestion de la lutte contre la fraude permet de gérer plusieurs listes de données. Trois types différents de règles peuvent être appliqués à ces listes :

  • vérification dans une liste noire ;
  • vérification dans une liste grise ;
  • vérification dans une liste blanche.

La différence entre ces règles dépend du résultat de la règle ainsi que de la manière dont vous gérez la liste :

  • une liste noire est une liste du type NOGO utilisée pour des actions sévères, elle entraîne généralement un rejet des transactions ;
  • une liste grise est une liste du type NOGO utilisée pour des cas douteux nécessitant une attention particulière ;
  • une liste blanche est une liste du type GO utilisée pour porter une attention spéciale et positive à certains clients.

Voici les résultats possibles en fonction du type de règle :

Valeur de donnée présente Résultat liste noire
(type NOGO)
Résultat liste grise
(type NOGO)
Résultat liste blanche
(type GO)
NON Neutre Neutre Neutre
OUI Négatif Négatif Positif

D'une manière générale, les achats sur Internet présentent pour vous un risque de fraude plus élevé que lorsque la carte est présentée. Les commandes par téléphone/courrier/Internet sont des vecteurs majeurs de fraude si vous vendez et expédiez des produits. Si la carte n'est pas physiquement présente, vous devez compter sur le porteur de carte (ou quelqu'un qui affirme l'être) pour donner les informations de manière indirecte, que ce soit par courrier, téléphone ou Internet.

Il se peut que vous souhaitiez suivre les clients (ou des propriétés afférentes) avec lesquels vous avez eu une bonne ou une mauvaise expérience lors d'un précédent achat. Par exemple, si vous avez livré un produit à une adresse mais n'avez pas été réglé car la carte utilisée pour le paiement était frauduleuse, vous pouvez mettre ce numéro de carte en liste noire afin que la demande de paiement soit rejetée si cette carte est à nouveau utilisée sur votre boutique.

Autre exemple : vous pouvez ajouter un nom de client à une liste si vous pensez que ce client a des problèmes de solvabilité, par exemple si une tentative d'autorisation financière a été rejetée avec un code indiquant un « solde insuffisant » du compte. Dans ce cas, peut-être ne voulez-vous pas rejeter la transaction immédiatement mais être alerté si ce nom est utilisé à nouveau dans une transaction.

Vous pouvez aussi gérer ce nom dans ce que l'on appelle une liste grise. Vous pouvez ainsi recevoir une alerte si l'une des propriétés est utilisée de nouveau lors d'une transaction différente, et traiter la nouvelle transaction avec une attention particulière, effectuer une vérification manuelle, etc. Les listes grises sont également un moyen de gérer les propriétés (données transactionnelles) que l’on suppose liées à la fraude.

D'autre part, il se peut que vous ayez eu de mauvaises expériences avec certains clients, mais aussi des expériences très positives avec d'autres. Vous pouvez ainsi, par exemple, traiter certains clients comme des « VIP ». Les clients B2B peuvent également s'avérer suffisamment fiables. Les listes dites blanches représentent le moyen approprié de gérer ces clients.

Liste partagée

Par défaut, une boutique a sa propre liste pour chaque règle de type liste. Ces listes sont appelées « listes privées ».

Il est également possible de partager une liste pour plusieurs boutiques.

Une liste est partageable au niveau du groupe commercial.

5 listes partagées peuvent être créées par type de liste.

Toutes les boutiques attachées à cette liste partagée peuvent modifier les éléments de la liste.

L'élément ajouté par un utilisateur d’une boutique ne peut être modifié ou supprimé que par un utilisateur de cette boutique ou un administrateur, mais pas par les utilisateurs d’une autre boutique. Les éléments de la liste sont utilisés pour toutes les boutiques la partageant.

Pour mettre en place une liste partagée, vous devez contacter votre gestionnaire de compte pour la configuration. Cette dernière s’effectue en deux étapes :

  • tout d'abord créer une liste commune en choisissant son type (liste d’adresses e-mail, liste de numéros de carte, etc.) et sa couleur (noir, gris ou blanc) ;
  • puis associer la liste partagée aux boutiques.

Lors de l'exécution des contrôles antifraudes, si la règle appropriée est activée, la liste partagée sera appliquée à la place de la liste privée par défaut.

Adresses e-mail

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat lié à une adresse e-mail qui appartient à la liste noire ou grise des adresses e-mail.
  • et/ou de décider d'honorer ou non un achat lié à une adresse e-mail qui appartient à la liste blanche des adresses e-mail sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des adresses e-mail VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins une adresse e-mail transmise par vos soins.

La règle va vérifier l’appartenance de toutes les adresses e-mail disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les adresses e-mail vérifiées sont :

  • l'adresse e-mail du client ;
  • l’adresse e-mail du porteur du moyen de paiement (il est possible que le client/acheteur utilise le moyen de paiement d’un proche) ;
  • l’adresse e-mail du contact de la facturation ;
  • l’adresse e-mail du contact de la livraison.

Si une des adresses e-mail disponibles est présente dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste noire, grise et/ou blanche des adresses e-mail ;

  • et transmettre une ou plusieurs adresses e-mail précédemment citées dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Au moins une adresse e-mail fait partie de la liste Noire 31 Négatif --
Grise 32
Blanche AC Positif
Aucune adresse e-mail ne fait partie de la liste Noire -- Neutre
Grise
Blanche
Aucune adresse e-mail n’a été transmise Noire
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackEmail (liste noire), GreyEmail (liste grise) et/ou WhiteEmail (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackEmail
    

Liste grise :

      fraudData.bypassCtrlList=GreyEmail
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteEmail
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackEmail</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyEmail</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteEmail</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackEmail"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyEmail"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteEmail"]
}
    

Adresses IP

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat lié à une adresse IP qui appartient à la liste noire ou grise des adresses IP.
  • et/ou de décider d'honorer ou non un achat lié à une adresse IP qui appartient à la liste blanche des adresses IP, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des adresses IP VIP.

La règle va vérifier l’appartenance de l'adresse IP à la liste noire, grise et/ou blanche que vous avez définie(s). Cette adresse IP provient :

  • de la détection automatique via le navigateur de l'acheteur en Sogenactif Paypage  ;
  • ou du transfert que vous effectuez dans la requête en Sogenactif Office Serveur .

Si l'adresse IP est présente dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste noire, grise et/ou blanche des adresses IP ;

  • et transmettre l'adresse IP de l'acheteur dans la requête (champ customerIpAddress ), si vous êtes sur Sogenactif Office Serveur .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
L’adresse IP n’est pas renseignée (en Sogenactif Office Serveur ) Noire -- Neutre --
Grise
Blanche
L’adresse IP appartient à la liste Noire 37 Négatif
Grise 38
Blanche AE Positif
L’adresse IP n’appartient pas à la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackIp (liste noire), GreyIp (liste grise) et/ou WhiteIp (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackIp
    

Liste grise :

      fraudData.bypassCtrlList=GreyIp
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteIp
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackIp</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyIp</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteIp</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackIp"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyIp"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteIp"]
}
    

Codes postaux par pays

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat lié à un code postal qui appartient à la liste noire ou grise des codes postaux par pays.
  • et/ou de décider d'honorer ou non un achat lié à un code postal qui appartient à la liste blanche des codes postaux, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des codes postaux VIP.

Si la règle est présente dans votre profil, elle sera effectuée sur toutes les transactions de paiement avec au moins un code postal transmis par vos soins.

La règle va vérifier l’appartenance de tous les codes postaux disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les codes postaux vérifiés sont :

  • le code postal du contact de la facturation ;
  • le code postal du contact de la livraison.

Si un des codes postaux disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste noire, grise et/ou blanche des codes postaux ;

  • et transmettre un ou plusieurs codes postaux ci-dessus dans la requête (champs billingAddress.zipCode, deliveryAddress.zipCode ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Aucun code postal n'a été transmis Noire -- Neutre --
Grise
Blanche
Au moins un code postal fait partie de la liste Noire 39 Négatif
Grise 40
Blanche AG Positif
Aucun code postal ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackPostalCode (liste noire), GreyPostalCode (liste grise) et/ou WhitePostalCode (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackPostalCode
    

Liste grise :

      fraudData.bypassCtrlList=GreyPostalCode
    

Liste blanche :

      fraudData.bypassCtrlList=WhitePostalCode
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackPostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyPostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhitePostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackPostalCode"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyPostalCode"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhitePostalCode"]
}
    

Identifiants clients

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat lié à un identifiant client qui appartient à la liste noire ou grise des identifiants clients.
  • et/ou de décider d'honorer ou non un achat lié à un identifiant client qui appartient à la liste blanche identifiants clients, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des identifiants clients VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec un identifiant client soumis dans la requête/transmis par vos soins.

La règle va vérifier l’appartenance de l'identifiant client à la liste noire, grise et/ou blanche des identifiants clients que vous avez définie(s).

Si l'identifiant client est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste noire, grise et/ou blanche des identifiants clients ;

  • et transmettre l'identifiant client de l'acheteur dans la requête (champ customerId ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
L’identifiant client n’est pas fourni Noire -- Neutre --
Grise
Blanche
Au moins un identifiant client fait partie de la liste Noire 28 Négatif
Grise 29
Blanche AB Positif
L’identifiant client ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackCustomerId (liste noire), GreyCustomerId (liste grise) et/ou WhiteCustomerId (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackCustomerId
    

Liste grise :

      fraudData.bypassCtrlList=GreyCustomerId
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteCustomerId
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackCustomerId"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyCustomerId"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteCustomerId"]
}
    

Noms de clients

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat lié à un nom de client qui appartient à la liste noire ou grise des noms de clients.
  • et/ou de décider d'honorer ou non un achat lié à un nom de client qui appartient à la liste blanche des noms de clients, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des noms de clients VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins un nom de client transmis par vos soins.

La règle va vérifier l’appartenance de tous les noms disponibles à la liste noire, grise et/ou blanche des noms de clients que vous avez définie(s). Les noms vérifiés sont :

  • le nom du client ;
  • le nom du porteur du moyen de paiement (il est possible que le client/acheteur utilise le moyen de paiement d'un proche) ;
  • le nom du contact de la facturation ;
  • le nom du contact de la livraison.

Si un des noms disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste noire, grise et/ou blanche des noms de clients ;

  • et transmettre au moins un nom de client dans la requête (champs billingContact.lastName, customerContact.lastName, deliveryContact.lastName, holderContact.lastName ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Aucun nom de client n'a été transmis Noire -- Neutre --
Grise
Blanche
Au moins un nom de client fait partie de la liste Noire 35 Négatif
Grise 36
Blanche AF Positif
Aucun nom de client ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackCustomerName (liste noire), GreyCustomerName (liste grise) et/ou WhiteCustomerName (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackCustomerName
    

Liste grise :

      fraudData.bypassCtrlList=GreyCustomerName
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteCustomerName
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCustomerName</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCustomerName</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerName</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackCustomerName"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyCustomerName"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteCustomerName"]
}
    

Numéros de carte

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat provenant d'une carte qui appartient à votre liste noire ou grise .
  • et/ou de décider d'honorer ou non directement un achat provenant d'une carte qui appartient à votre liste blanche , sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste de cartes VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement par carte transmises par vos soins.

La règle va vérifier l’appartenance du numéro de carte soumis pour autorisation (si applicable) à la liste noire, grise et/ou blanche de vos numéros de carte.

Si le numéro de carte en question est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer la liste noire, grise et/ou blanche des numéros de carte ( cardNumber ).

La liste peut être paramétrée :

  • via l’onglet 'Fraude' et Sogenactif Gestion . Les données doivent être ajoutées par le biais d'un identifiant de la transaction. Dans ce dernier cas, la valeur de la donnée stockée pour la transaction liée à l’identifiant de la transaction sera ajoutée à la liste ;
  • et par le batch d’alimentation de Sogenactif Office Batch .

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) Noire -- Neutre --
Grise
Blanche
Le numéro de la carte fait partie de la liste Noire 50 Négatif
Grise 03
Blanche AA Positif
Le numéro de la carte ne fait pas partie de de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackCard (liste noire), GreyCard (liste grise) et/ou WhiteCard (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackCard
    

Liste grise :

      fraudData.bypassCtrlList=GreyCard
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteCard
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCard</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCard</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackCard"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyCard"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteCard"]
}
    

Numéros de téléphone

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat lié à un numéro de téléphone qui appartient à la liste noire ou grise des numéros de téléphone.
  • et/ou de décider d'honorer ou non un achat lié à un numéro de téléphone qui appartient à la liste blanche des numéros de téléphone, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des numéros de téléphone VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins un numéro de téléphone transmis par vos soins.

La règle va vérifier l’appartenance de tous les numéros de téléphone disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les numéros de téléphone vérifiés sont :

  • les numéros de téléphone fixe/portable du client ;
  • les numéros de téléphone fixe/portable du porteur du moyen de paiement (en effet, il est possible que le client/acheteur utilise le moyen de paiement d’un proche) ;
  • les numéros de téléphone fixe/portable du contact de la facturation ;
  • les numéros de téléphone fixe/portable du contact de la livraison.

Si un des numéros de téléphone disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif ,
  • paramétrer la liste noire, grise et/ou blanche des numéros de téléphone ;

  • et transmettre dans la requête un ou plusieurs des numéros de téléphone énumérés ci-dessus (champs billingContact.phone, customerContact.phone, deliveryContact.phone, holderContact.phone, billingContact.mobile, customerContact.mobile, deliveryContact.mobile, holderContact.mobile ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Aucun numéro de téléphone n’a été transmis Noire -- Neutre --
Grise
Blanche
Au moins un numéro de téléphone fait partie de la liste Noire 33 Négatif
Grise 34
Blanche AD Positif
Aucun numéro de téléphone ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackPhoneNumber (liste noire), GreyPhoneNumber (liste grise) et/ou WhitePhoneNumber (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackPhoneNumber
    

Liste grise :

      fraudData.bypassCtrlList=GreyPhoneNumber
    

Liste blanche :

      fraudData.bypassCtrlList=WhitePhoneNumber
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhitePhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackPhoneNumber"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyPhoneNumber"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhitePhoneNumber"]
}
    

Plages de BIN

Description de la règle

Cette règle vous permet :

  • de décider de refuser ou non un achat effectué avec une carte dont le BIN appartient à votre liste noire ou grise de BIN.
  • et/ou de décider d'honorer ou non directement un achat effectué avec une carte dont le BIN appartient à votre liste blanche de BIN, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste de plages de BIN VIP.

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement par carte transmises par vos soins.

La règle va vérifier l’appartenance du numéro de BIN de la carte à votre liste noire, grise et/ou blanche de plages de BIN.

Si le numéro BIN de la carte en question est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer la liste noire, grise et/ou blanche des numéros de BIN ( cardNumber ).

Note: veuillez consulter le glossaire pour plus d'informations sur les BIN.

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) Noire -- Neutre --
Grise
Blanche
Le numéro de BIN de la carte fait partie de la liste Noire 41 Négatif
Grise 08
Blanche AH Positif
Le numéro de BIN de la carte ne fait pas partie de de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackBinCard (liste noire), GreyBinCard (liste grise) et/ou WhiteBinCard (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackBinCard
    

Liste grise :

      fraudData.bypassCtrlList=GreyBinCard
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteBinCard
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackBinCard"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyBinCard"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteBinCard"]
}
    

BIC (Bank Identifier Code)

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat lié à un BIC (Bank Identifier Code) qui appartient à la liste noire, grise et/ou blanche de BIC, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste de BIC VIP).

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.

La règle va vérifier l’appartenance du BIC à la liste noire, grise et/ou blanche de BIC que vous avez définie(s).

Si le BIC est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Tip: vous pouvez transmettre le BIC dans la requête. Sinon il sera automatiquement retrouvé à partir de l’IBAN que vous devez obligatoirement transmettre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer la liste noire, grise et/ou blanche de BIC.

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Le BIC fait partie de la liste Noire 66 Négatif --
Grise 67
Blanche AI Positif
Le BIC ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackBic (liste noire), GreyBic (liste grise) et/ou WhiteBic (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackBic
    

Liste grise :

      fraudData.bypassCtrlList=GreyBic
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteBic
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackBic</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyBic</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteBic</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackBic"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyBic"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteBic"]
}
    

IBAN (International Bank Account Number)

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat lié à un IBAN (International Bank Account Number) qui appartient à la liste noire, grise et/ou blanche d'IBAN, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste d'IBAN VIP).

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.

La règle va vérifier l’appartenance de l'IBAN utilisé par le mandat SDD à la liste noire, grise et/ou blanche d'IBAN que vous avez définie(s).

Si l'IBAN est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer la liste noire, grise et/ou blanche d'IBAN.

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
L'IBAN fait partie de la liste Noire 68 Négatif --
Grise 59
Blanche AJ Positif
L'IBAN ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackIban (liste noire), GreyIban (liste grise) et/ou WhiteIban (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackIban
    

Liste grise :

      fraudData.bypassCtrlList=GreyIban
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteIban
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackIban</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyIban</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteIban</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackIban"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyIban"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteIban"]
}
    

Mandats

Description de la règle

Cette règle vous permet de mesurer le risque sur un achat lié à un mandat SDD qui appartient à la liste noire, grise et/ou blanche de mandats, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste de mandats VIP).

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.

La règle va vérifier l’appartenance du mandat, basé sur son RUM (Référence Unique de Mandat), à la liste noire, grise et/ou blanche de mandats que vous avez définie(s).

Si le mandat est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez, pour chaque liste :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et paramétrer la liste noire, grise et/ou blanche de mandats.

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Le RUM du mandat fait partie de la liste Noire 70 Négatif --
Grise 71
Blanche AK Positif
Le RUM du mandat ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

Cette règle n’alimente pas le champ complementaryInfo .

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackMandate (liste noire), GreyMandate (liste grise) et/ou WhiteMandate (liste blanche).

  • Exemple en version POST :

Liste noire :

      fraudData.bypassCtrlList=BlackMandate
    

Liste grise :

      fraudData.bypassCtrlList=GreyMandate
    

Liste blanche :

      fraudData.bypassCtrlList=WhiteMandate
    

  • Exemple en version SOAP :

Liste noire :

      <urn:fraudData>
     <urn:bypassCtrlList>BlackMandate</urn:bypassCtrlList>
</urn:fraudData>
    

Liste grise :

      <urn:fraudData>
     <urn:bypassCtrlList>GreyMandate</urn:bypassCtrlList>
</urn:fraudData>
    

Liste blanche :

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteMandate</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :

Liste noire :

      "fraudData": {
   "bypassCtrlList": ["BlackMandate"]
}
    

Liste grise :

      "fraudData": {
   "bypassCtrlList": ["GreyMandate"]
}
    

Liste blanche :

      "fraudData": {
   "bypassCtrlList": ["WhiteMandate"]
}
    

Règles de panier

Généralités

Le moteur de gestion de la lutte contre la fraude permet de prendre en compte la composition du panier de la transaction pour en mesurer le risque. Pour ce faire, il utilise des listes de produits à risque que vous définissez vous-même.

Un produit à risque est un produit que vous vendez et considèrez comme potentiellement associé à des transactions à risque selon certains critères qui vous appartiennent : catégorie ou type de produit, prix du produit, utilisation régulière d’un produit dans des transactions frauduleuses, etc.

Vous avez la possibilité de définir jusqu’à 3 listes de produits à risque pour votre boutique. Vous pouvez ainsi ajouter tout ou partie des produits que vous vendez dans une ou plusieurs listes selon le niveau de risque du produit.

Par exemple, vous pouvez choisir de créer les 3 listes de produits à risques suivantes :

  • une liste de produits à faible risque ;
  • une liste de produits à risque modéré ;
  • et une liste de produits à haut risque.

Les listes de produits à risque sont exploitées par des règles de détection de risque du contenu du panier du client qui effectue un achat sur votre site. Si ces règles sont activées, elles vont analyser le contenu du panier et le comparer aux listes de produits à risque que vous avez définies afin d'évaluer le risque de la transaction. Vous pouvez ainsi limiter l‘achat de certains produits à une certaine quantité ou un certain ratio du montant global.

IMPORTANT: les produits sont identifiés par le moteur de lutte contre la fraude sur la base de leur code produit, qui doit se trouver à la fois dans les listes de produits à risque et dans les données du panier de la transaction. Il est essentiel que ces codes concordent entre les listes et le panier.

Listes partagées

Par défaut, une boutique possède ses propres listes de produits à risque (jusqu'à 3 listes). Ces listes sont appelées « listes privées ».

Vous pouvez également réaliser des listes communes à plusieurs boutiques afin de n’administrer qu’un seul jeu de produits à risque pour les boutiques concernées. Ce sont des listes dites « partagées ».

Une liste est partageable au niveau du groupe commercial. Vous pouvez créer et associer aux boutiques 5 listes partagées de produits à risque. Toutes les boutiques associées à une liste partagée donnée peuvent modifier les éléments de la liste. Les éléments de la liste sont utilisés pour toutes les boutiques la partageant.

Pour mettre en place une liste partagée, vous devez contacter votre gestionnaire de compte pour la configuration. Cette dernière s’effectue en deux étapes :

  • tout d'abord créer une liste commune en choisissant son type (liste d’adresses e-mail, liste de numéros de carte, etc.) et sa couleur (noir, gris ou blanc) ;
  • puis associer la liste partagée aux boutiques.

L’association d’une boutique à une liste partagée se fait en utilisant une liste partagée existante au niveau du groupe commercial, dans l’écran de configuration des listes de produits de la boutique.

Lors de l'exécution des contrôles antifraudes, si la règle appropriée est activée et qu’elle est paramétrée pour utiliser la liste partagée, alors cette dernière sera utilisée.

Liste de produits à risque

Description de la règle

Cette règle vous permet de vérifier la présence ou non de produits à risque dans le panier du client.

La règle va interroger les listes de produits à risque définies par vos soins et paramétrées dans la règle afin de vérifier si l’un des produits du panier du client contient un produit que vous considérez comme potentiellement risqué.

Si la requête que vous envoyez ne contient pas de liste de produits à risque pour la boutique ou de contenu du panier, la règle retourne un résultat neutre.

Attention: cette règle ne peut pas être décisive afin de ne pas bloquer toutes les transactions d’une boutique. En effet les produits contenus dans les listes de produits à risque sont forcément des produits que vous vendez, tout comme les produits présents dans le panier.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du Portail Sogenactif ,
  • paramétrer au moins une liste de produits à risque via l’onglet fraude du Portail Sogenactif

  • et transmettre le contenu du panier du client dans la requête, notamment le code produit de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Au moins un produit du panier appartient à une liste de produits à risque 51 Négatif --
L'information n'est pas connue -- Neutre
Aucun produit du panier n’appartient à une liste de produits à risque -- Neutre

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive RiskyProductList .

  • Exemple en version POST :
      fraudData.bypassCtrlList=RiskyProductList
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductList</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["RiskyProductList"]
}
    

Quantité de produits à risque

Description de la règle

Cette règle vous permet de limiter dans le panier la quantité de produits appartenant à l’une de vos listes de produits à risque.

La règle va analyser le contenu du panier et vérifier que :

  • la quantité d’un même produit du panier du client appartenant à l’une de vos listes de produits à risque n’excède pas le seuil paramétré dans la règle ;
  • la quantité totale de tous les produits du panier du client appartenant à une même liste de produits à risque n’excède pas le seuil paramétré dans la règle.

Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du Portail Sogenactif ,
  • paramétrer au moins une liste de produits à risque via l’onglet fraude du Portail Sogenactif

  • et transmettre le contenu du panier du client dans la requête, notamment le code produit et la quantité de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Au moins un produit du panier appartenant à une liste de produits à risque a une quantité supérieure au seuil paramétré dans la règle
et/ou
la quantité totale des produits appartenant à une liste de produits à risque est supérieure au seuil paramétré dans la règle
52 Négatif MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*
L'information n'est pas connue -- Neutre --
Aucun produit du panier n’appartient à une liste de produits à risque
ou
Aucun produit du panier appartenant à une liste de produits à risque n’a une quantité supérieure au seuil paramétré dans la règle
-- Neutre MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*

*L : le nom de la liste de produits à risque concernée.

A : la quantité la plus grande d’un produit du panier appartenant à cette liste de produits à risque.

B : la quantité maximum acceptée pour un produit appartenant à cette liste de produits à risque.

C : la somme des quantités des produits du panier appartenant à cette liste de produits à risque.

D : la quantité maximum acceptée pour tous les produits du panier appartenant à cette liste de produits à risque.

Note: jusqu’à 3 listes de produits à risque peuvent être paramétrées pour cette règle. Les valeurs MAX_QUANTITY_PER_RISKY_PRODUCT et MAX_QUANTITY_PER_LIST sont restituées dans le champ complementaryInfo pour chacune de ces listes. Pour cette règle il est donc possible d’avoir ces valeurs jusqu’à 3 fois dans le champ complementaryInfo .

MAX_QUANTITY_PER_RISKY_PRODUCT=L1:A1:B1;MAX_QUANTITY_PER_LIST=L1:C1:D1; MAX_QUANTITY_PER_RISKY_PRODUCT=L2:A2:B2;MAX_QUANTITY_PER_LIST=L2:C2:D2; MAX_QUANTITY_PER_RISKY_PRODUCT=L3:A3:B3;MAX_QUANTITY_PER_LIST=L3:C3:D3

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive RiskyProductQuantity .

  • Exemple en version POST :
      fraudData.bypassCtrlList=RiskyProductQuantity
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductQuantity</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["RiskyProductQuantity"]
}
    

Ratio de produits à risque

Description de la règle

Cette règle vous permet de détecter un comportement anormal relatif au ratio entre le montant d’un ou de tous les produits appartenant à une liste de produits à risque et le montant total du panier du client.

La règle va analyser le contenu du panier et vérifier que :

  • le ratio entre le montant total (quantité x prix unitaire) d’un même produit du panier appartenant à une liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle ;
  • le ratio entre le montant total (quantité x prix unitaire) de tous les produits du panier appartenant à une même liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle.

Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du Portail Sogenactif ,
  • paramétrer au moins une liste de produits à risque via l’onglet fraude du Portail Sogenactif

  • et transmettre le contenu du panier du client dans la requête, notamment le code produit, le montant unitaire et la quantité de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le plus grand ratio entre le montant total pour au moins un produit appartenant à une liste de produits à risque et le montant total du panier est supérieur au seuil paramétré dans la règle
et/ou
le ratio entre le montant total de tous les produits appartenant à une liste de produits à risque et le montant total du panier est supérieur au seuil paramétré dans la règle
53 Négatif MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*
L'information n'est pas connue -- Neutre --
Aucun produit du panier n’appartient à une liste de produits à risque
ou
Le ratio entre le montant total pour un produit appartenant à une liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle et le ratio entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle
-- Neutre MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*

*L : le nom de la liste de produits à risque concernée.

A : le plus grand ratio entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.

B : le ratio maximum accepté entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.

C : le plus grand ratio entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.

D : le ratio maximum accepté entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.

Note: jusqu’à 3 listes de produits à risque peuvent être utilisées pour cette règle. Les valeurs MAX_RATIO_PER_RISKY_PRODUCT et MAX_QUANTITY_PER_LIST sont restituées dans le champ scoreInfo pour chacune de ces listes. Pour cette règle il est donc possible d’avoir ces valeurs jusqu’à 3 fois dans le champ scoreInfo .

MAX_RATIO_PER_RISKY_PRODUCT=L1:A1:B1;MAX_RATIO_PER_LIST=L1:C1:D1; MAX_RATIO_PER_RISKY_PRODUCT=L2:A2:B2;MAX_RATIO_PER_LIST=L2:C2:D2; MAX_RATIO_PER_RISKY_PRODUCT=L3:A3:B3;MAX_RATIO_PER_LIST=L3:C3:D3

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive RiskyProductRatio .

  • Exemple en version POST :
      fraudData.bypassCtrlList=RiskyProductRatio
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductRatio</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["RiskyProductRatio"]
}
    

Quantité de produits

Description de la règle

Cette règle vous permet de limiter la quantité d’un même produit dans le panier d’un client.

La règle va analyser le contenu du panier et vérifier que la quantité de chaque produit n’excède pas le seuil que vous avez paramétré dans la règle. Cette règle n’utilise pas de listes de produits à risque.

Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.

Conditions d'utilisation

Si vous désirez opter pour cette règle, vous devez :

  • activer la règle dans le profil via l’onglet fraude du Portail Sogenactif
  • et transmettre le contenu du panier du client dans la requête, notamment le code produit et la quantité de chaque produit du panier (champ ShoppingCartDetails ).

Restitution du résultat

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Au moins un produit du panier a une quantité supérieure au seuil paramétré dans la règle 54 Négatif PRODUCTQUANTITY =A:B*
L'information n'est pas connue -- Neutre PRODUCTQUANTITY =XXX:B*
Aucun produit du panier n’a une quantité supérieure au seuil paramétré dans la règle -- Neutre PRODUCTQUANTITY =A:B*

* A : la quantité du premier produit trouvé dont la quantité est supérieure au seuil défini dans la règle.

B : la quantité maximum de chaque produit acceptée dans le panier.

Surcharge dynamique

La surcharge dynamique de cette règle n'est pas disponible.

Débrayage dynamique

Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxQuantityPerProduct .

  • Exemple en version POST :
      fraudData.bypassCtrlList=MaxQuantityPerProduct
    

  • Exemple en version SOAP :
      <urn:fraudData>
     <urn:bypassCtrlList>MaxQuantityPerProduct</urn:bypassCtrlList>
</urn:fraudData>
    

  • Exemple en version JSON :
      "fraudData": {
   "bypassCtrlList": ["MaxQuantityPerProduct"]
}
    

Configurer des profils anti-fraude avec le Portail Sogenactif

Ce chapitre vous présente la marche à suivre pour configurer les profils de lutte contre la fraude dans votre portail.

Utiliser l'onglet Fraude

Cliquez sur l'onglet Fraude pour accéder à la page d'accueil de l'outil de gestion des profils antifraude.

Attention: si un message s'affiche et indique un problème de droits d'accès, veuillez vous rapprocher de votre support afin d'activer l'option de lutte contre la fraude sur votre boutique.

Vous pouvez sélectionner la langue de votre choix (EN, FR) dans la partie supérieure droite.

Liste des boutiques

Dans la partie supérieure de la page, vous pouvez retrouver la liste des boutiques auxquelles vous avez accès.

Cliquez sur l'icône pour déplier cette partie et sélectionner une autre boutique.

Note: lorsqu'une boutique est sélectionnée, cette partie est automatiquement repliée.

Utilisez le champ de saisie situé en haut de cette partie pour filtrer les boutiques selon tout ou partie de leur nom ou ID.

Cliquez sur l'une des boutiques pour la sélectionner et afficher ses profils.

Partie principale

Le menu en haut de cette partie vous permet d’accéder à l’administration des profils et des listes de la boutique en ligne sélectionnée.

Tip: à différents endroits de l’interface, cliquez sur les icônes pour accéder à des informations détaillées sur les éléments auxquels ils se rapportent.
Attention: gestion des droits

Les actions que vous pouvez effectuer dépendent du/des rôle(s) attribué(s) à votre profil Portail Sogenactif .

Pagination et sélection multiple

Pagination

À plusieurs endroits de l’interface, vous pourrez rencontrer des tables dont les éléments sont présentés sur plusieurs pages lorsque leur contenu l’impose. Des boutons apparaissent alors, permettant de naviguer entre les pages :

Sélection multiple

Lorsqu’il est possible de sélectionner les éléments d’une liste, une case à cocher dans l’entête de la liste vous permet de sélectionner ou de déselectionner l’ensemble des éléments de la liste d’un seul clic, y compris ceux présents sur d’éventuelles autres pages.

Lorsque de multiples élements sont sélectionnés, des boutons apparaissent en bas de table, permettant des actions sur l’ensemble de la sélection.

Administrer les profils antifraude

Dans la barre de menu, cliquez sur Gérer les profils pour accéder à cette section.

Liste des profils

La page d'accueil de cette section présente la liste des profils de la boutique :

Si vous avez souscrit à l'option permettant d’appliquer des contrôles antifraude avant l’authentification, une barre d’onglets permet de naviguer entre la liste des profils avant authentification et la liste des profils avant autorisation :

La colonne Statut live permet de constater l'état d'activation d'un profil.
profil désactivé profil activé

Un profil est en état désactivé :

  • s'il n'a jamais été publié ;
  • s'il a été manuellement désactivé ;
  • ou s’il a été automatiquement désactivé par l’activation d’un autre profil en conflit par rapport aux moyens de paiement attribués.
Tip: profil par défaut actif

Pour éviter que le profil du distributeur ne soit appliqué, il est préférable qu’il y ait toujours un profil par défaut actif.

La colonne Statut brouillon permet de connaître l'état de publication d'un profil :
Statut État de publication
Le profil a été créé mais n’a jamais été publié.
Le profil a été publié et est utilisé pour l’évaluation des transactions s’il est activé (cf. ci-dessus).
Le profil a été modifié depuis sa dernière publication. Il doit être republié pour que les modifications soient prises en compte pour l’évaluation des transactions.
Important : ceci n’affecte pas le fonctionnement de la version publiée du profil, qui continue de fonctionner de la même manière que précédemment.
Attention: version de travail et version publiée

Un profil est composé de deux entités : une version de travail et une version publiée.

La version de travail est celle que vous pouvez modifier et sauvegarder à loisir, sans effet sur les transactions de la boutique. Elle peut être considérée comme un brouillon de profil. A la création d’un nouveau profil, c’est la version de travail qui est en fait créée.

Lorsque vous êtes satisfait des modifications apportées sur la version de travail, vous pouvez la publier pour créer la version publiée. C’est cette version du profil qui est utilisée pour évaluer les transactions.

Un profil doit donc être à la fois actif et publié pour pouvoir être appliqué. Un profil actif mais ayant un statut « À republier » ne s'appliquera pas.

La colonne Moyens de paiement permet de connaître les moyens de paiement attribués à un profil.

Les profils peuvent être spécialisés pour des moyens de paiement particuliers. Cette colonne en récapitule la liste.

Les moyens de paiement sur fond coloré sont ceux attribués à la version publiée du profil.

Les moyens de paiement en couleur grise sont ceux présents uniquement dans la version de travail, et donc inactifs du point de vue de l’évaluation des transactions.

Dans cet exemple, Mastercard et Visa sont attribués au profil publié et  CB est uniquement dans la version de travail :

Vous pouvez cliquer sur l'intitulé des colonnes afin de trier la liste selon le critère concerné.

Cliquez sur l'un des profils pour consulter et éditer le détail du paramétrage du profil.

Cycle de vie des profils

Exemple de cycle de vie d'un profil :

Créer un profil

Cliquez sur le bouton pour créer un nouveau profil. Les options de création sont les suivantes :

  • Profil Go-No-Go (ou Go-No-Go+, selon votre offre)

    Si cette option est autorisée par le distributeur, sélectionnez le choix Profil Go-No-Go  (+) dans la liste du bouton-menu Créer un profil . Vous accédez alors à la page de création d’un nouveau profil.

ou

  • Choisissez Copier un existant pour créer un nouveau profil à partir d’un profil existant sur la boutique. Une fenêtre popup s'affiche et vous permet de choisir le profil à copier.

    Une fois le profil à copier choisi, vous accédez à la page de création du profil.

ou

  • À partir d'un modèle de profil

    De la même manière que pour la copie d’un profil existant, une fenêtre popup vous permet de choisir, dans une liste de modèles de profil disponibles, celui qui va servir de base au nouveau profil créé.

Vous accédez ensuite à la page de création du profil :

  • Nom du profil :

    Le nom du profil doit être unique pour une boutique donnée et peut contenir un maximum de 30 caractères parmi les suivants : A-Z, a-z, 0-9, _ (tiret bas) et espace.

  • Moyens de paiement :

    Vous pouvez décider si le profil doit s’appliquer à un ou plusieurs moyens de paiement particuliers. Cochez les cases des moyens de paiement souhaités. La liste des moyens de paiement disponibles dépend des moyens de paiement activés sur la boutique et configurés dans le Portail Sogenactif .

    Tip: profils par défaut

    si le profil doit prendre en charge tous les moyens de paiement, il s’agit alors d’un profil par défaut . Il est alors inutile de cocher quoi que ce soit.

    Un moyen de paiement apparaissant grisé et accompagné d’une balise vous avertit que ce moyen de paiement est déjà sélectionné dans un autre profil actif. Vous pouvez toutefois le cocher si tel est votre choix. Il sera alors enlevé de l’autre profil. Un message d’avertissement s'affiche au moment où vous cochez le moyen de paiement :

    Attention: un seul profil pour un moyen de paiement donné

    Il ne peut y avoir qu’un seul profil actif éligible à un moyen de paiement donné. L’interface de configuration garantit cela en supprimant automatiquement les moyens de paiement des autres profils si un conflit se pose avec un profil nouvellement édité. Au moment de sa publication, ce dernier aura donc l’entière responsabilité des moyens de paiement concernés.

  • Prise en compte des transactions refusées dans les règles d'encours

    Cochez cette option afin de prendre en compte les transactions refusées dans les compteurs (en plus des transactions acceptées).

  • Devise des paramètres

    Si une boutique possède des contrats sur des moyens de paiement dans de multiples devises, il lui est possible de choisir dans quelle devise est effectué le paramétrage des montants dans le détail des règles.

    IMPORTANT: toutes les transactions peuvent être évaluées par un profil, quelle que soit leur devise respective. En effet, ce paramètre n’indique en aucun cas que le profil ne s’applique qu’aux transactions dont le montant est exprimé dans la devise choisie.

    Dans le cas où la transaction est dans une devise différente de celle paramétrée dans le profil, une conversion de change est effectuée.

  • Règles du profil

    La section Gérer vos règles de la page de création du profil vous permet de choisir les règles à appliquer pour le profil. Pour plus de détails consultez le paragraphe 'Administrer les règles dans les profils'.

Le profil est enregistré lorsque l'utilisateur clique sur le bouton . À cet instant, le profil n'est pas encore activé. Vous devez ensuite le publier (voir le paragraphe 'Éditer et publier un profil').

Le bouton permet d'annuler la création du profil et de revenir à la liste des profils de la boutique.

Éditer et publier un profil

La page d'édition de profil est pratiquement identique à la page de création d'un profil. En mode édition, le nom du profil n'est pas modifiable.

  • Statut du profil

    La partie droite de la page donne des détails sur le statut du profil :

    On y retrouve le statut (voir le paragraphe 'Liste des profils'), la date de publication et la devise des paramètres. La date de modification correspond à la date de dernière sauvegarde de la version de travail.

  • Actions disponibles en mode édition
    Action Description
    Permet de sauvegarder les modifications effectuées sur la version de travail. La sauvegarde ne publie pas les modifications. Pour ce faire, il vous faudra utiliser le bouton « Publier » .
    Permet de restaurer un profil dont la version de travail a été modifée, dans l’état où il était lors de sa dernière publication.
    Cette action n’est disponible que si le profil a été publié et qu’il a été modifié depuis (son statut est alors « À republier » ).
    Permet de supprimer un profil non publié.
    Cette action n’est plus accessible de cette page si le profil a été publié. Il vous faudra consulter la version publiée du profil pour la supprimer.
    Permet de publier la version de travail du profil et donc de la rendre effective pour l’évaluation des transactions. La couleur orange vous indique que cette action aura un effet potentiel sur les transactions de la boutique.

    Cliquez sur pour revenir à la liste des profils.

    Cliquez sur pour consulter la version publiée du profil le cas échéant.

Consulter un profil publié

Vous pouvez consulter la version publiée d'un profil en cliquant sur le bouton dans la page d'édition d'un profil.

La page suivante s'affiche :

Cet écran vous permet de consulter les détails du profil publié et de ses règles.

  • Actions disponibles sur un profil publié
    Action Description
    Permet d’activer le profil publié et inactif.
    Ce profil devient alors effectif pour l’évaluation des transactions.
    Permet de désactiver le profil publié et actif.
    Ce profil n'est alors plus effectif pour l’évaluation des transactions.
    Permet de supprimer un profil publié.

    La couleur orange vous indique que cette action aura un effet potentiel sur les transactions à venir de la boutique.

    Le bouton vous permet de revenir à la version de travail du profil.

Activer et désactiver un profil

Pour activer ou désactiver un profil publié , vous devez vous rendre sur la page de consultation de sa version publiée :

  • choisissez le profil à activer ou à désactiver dans la liste des profils de la boutique ;
  • dans le détail du profil, cliquez sur  ;
  • enfin, cliquez sur les boutons ou selon l'état d'activation du profil.

Pour activer un profil non publié , il suffit de le publier.

Supprimer un profil

Pour supprimer un profil publié vous devez, comme pour l'activation et la désactivation, accéder à la page de consultation de la version publiée du profil (voir le paragraphe 'Activer et désactiver un profil').

Supprimez ensuite le profil en cliquant sur le bouton .

Pour supprimer un profil non publié, accédez à sa version de travail (voir le paragraphe 'Éditer et publier un profil') et cliquez sur le bouton .

Administrer les règles dans les profils

Ajouter ou supprimer une règle

Le bouton situé sur la page de la version de travail du profil (voir le paragraphe 'Éditer et publier un profil'), affiche une fenêtre popup qui vous permet d’activer les règles en mode décisif ou informatif ou de les désactiver :

Pour valider vos choix, cliquez sur Ok après avoir fait votre sélection.

Note: veuillez consulter la liste des règles pour plus d'informations.

Ordonner et paramétrer les règles

En cliquant sur les règles du profil, vous faites apparaître une série de boutons permettant d'effectuer certaines actions sur ces règles.

  • Actions disponibles :
    Action Description
    Ces boutons permettent d’ordonner le déroulement des règles.
    Ce bouton permet de modifier le contenu des règles configurables.
    Cliquez sur ce bouton pour supprimer une règle du profil sans passer par la fenêtre popup de sélection des règles.
    Ce bouton vous permet de passer une règle informative en mode décisif.
    Ce bouton vous permet de passer une règle décisive en mode informatif.

Veuillez poursuivre la lecture de cette documentation pour en savoir plus sur le paramétrage des règles.

Filtrer les règles par moyen de paiement

Certaines règles sont liées à un moyen de paiement (ex : SDD) ou un type de moyen de paiement (ex : carte) en particulier. Citons par exemple l’encours carte qui ne s’applique que pour une carte de paiement (CB, Visa, Mastercard) ou l’encours par IBAN qui ne s’applique que pour un paiement prélèvement SDD.

Lors du paramétrage du profil, les règles proposées sont filtrées en fonction des moyens de paiement auxquels vous avez souscrit. Ainsi, vous ne pourrez pas activer les règles dépendant de certains moyens de paiement ou types de moyen de paiement si vous n'avez pas souscrit à ceux-ci.

Lorsqu’une règle ne s’applique qu’à un certain moyen de paiement ou type de moyen de paiement, une étiquette est affichée à côté du nom de la règle pour le préciser :

Paramétrer les règles de géolocalisation : adresses et pays

Pays de la carte

Cette section permet de configurer la liste des pays autorisés ou interdits par la règle. Cette liste peut apparaître sur plusieurs pages. Le champ Résultat correspond au resultat de la règle pour le pays concerné.

Les boutons radio Statut permettent de préciser si la liste qui suit est une liste de pays autorisés ou interdits.

Le champ Pays de la carte permet d’ajouter un pays à la liste par saisie manuelle de son nom dans le champ (avec auto-complétion possible).

Le bouton ouvre une fenêtre popup permettant de sélectionner un ou plusieurs pays dans une liste :

Lorsque vous effectuez une saisie manuelle, la liste est filtrée en fonction de la saisie, ce qui vous permet de constater si le pays saisi s'y trouve déjà :

Le bouton vous permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager des pays (qui vont donc donner respectivement un résultat positif ou négatif) :

Vous pouvez exporter le contenu de la liste dans un fichier au format CSV en cliquant sur le bouton . Cette action génère un fichier qui va contenir tous les éléments de la liste. Ce fichier est automatiquement téléchargé par votre navigateur.

Reportez-vous à l'Annexe 11 : format de fichier d'export de liste, pour en savoir plus sur le contenu du fichier CSV.

Pays de la carte et de l'adresse IP

Cette section permet de configurer la liste des couples de pays autorisés ou interdits par la règle. Le champ Résultat correspond au résultat de la règle pour le pays concerné.

Les boutons radio Statut vous permettent de préciser si la liste qui suit est une liste de couple de pays autorisés ou interdits.

Le champ Pays de l’adresse IP vous permet de saisir manuellement le pays de l’adresse IP du couple à ajouter à la liste.

Si vous souhaitez préciser d’emblée une liste de pays d’adresses IP, cliquez sur le bouton  : une fenêtre popup s'affiche et vous permet de sélectionner les pays souhaités. Une fois la liste sélectionnée, la mention liste de pays apparaît dans la zone de saisie.

Le champ Pays de la carte permet de préciser le pays de la carte du couple à ajouter à la liste et fonctionne de la même manière que le champ Pays de l’adresse IP .

Lorsque vous avez saisi les pays manuellement ou via la fenêtre popup, cliquez sur le bouton pour ajouter le ou les couples sélectionnés à la liste du contrôle.

Vous pouvez également cliquer sur le bouton pour ajouter les couples et leurs réciproques à la liste. Par exemple, si vous sélectionnez pays de l’adresse IP = France et pays de la carte = Belgique, ce bouton ajoute les couples France/Belgique et Belgique/France à la liste des couples.

Lorsque vous effectuez une saisie manuelle, la liste est filtrée en fonction de la saisie, ce qui vous permet de constater si le couple saisi s'y trouve déjà. Cette liste peut apparaître sur plusieurs pages.

Le bouton Activer le mode avancé vous permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager des pays (qui vont donc donner respectivement un résultat positif ou négatif).

Vous pouvez exporter le contenu de la liste dans un fichier au format CSV en cliquant sur le bouton . Cette action génère un fichier qui va contenir tous les éléments de la liste. Ce fichier est automatiquement téléchargé par votre navigateur.

Reportez-vous à l'Annexe 11 : format de fichier d'export de liste, pour en savoir plus sur le contenu du fichier CSV.

Autres règles

Le paramétrage se fait de la même manière pour de nombreuses règles :

Vous voulez paramétrer la règle... Veuillez consulter le paramétrage de la règle...
  • Pays de livraison et de la carte
  • Pays de facturation et de la carte
  • Pays de livraison et de l'IBAN
  • Pays du numéro de tél. et de l'IBAN
  • Pays de l'adresse IP et de l'IBAN
Pays de la carte et de l'adresse IP
  • Pays de l'adresse IP
  • Pays de l'IBAN
Pays de la carte
  • Pays de livraison et de facturation
Cette règle ne nécessite pas de configuration particulière.
  • Codes postaux de livraison et de facturation
Cette règle ne nécessite pas de configuration particulière, mais vous ne pouvez pas l'ajouter sans (ou la positionner avant) la règle de vérification des pays de livraison et de facturation.

Paramétrer les règles d'encours

Encours carte

Les champs Période permettent de préciser les périodes sur lesquelles le cumul du nombre et le cumul des montants des transactions sont effectués pour la carte concernée. Vous pouvez préciser ces périodes en heures, jours ou semaines en cliquant sur les boutons .

Le champ Nombre maximum de transactions permet de préciser le nombre maximum de transactions autorisé sur la période.

Le champ Montant cumulé maximum permet de préciser le montant cumulé maximum des transactions sur la période. Un rappel de la devise d’expression du montant cumulé est affiché au début de ce champ.

Il n'est pas obligatoire de préciser à la fois un montant cumulé maximum et un nombre maximum de transactions. Un des deux suffit.

De la même manière, il n’est pas obligatoire de paramétrer le nombre maximum de transactions et le montant cumulé maximum. Le paramétrage d’un des deux suffit.

Nombre de clients par carte

Le champ Période permet de préciser la période sur laquelle le décompte du nombre de clients pour la carte concernée se fait. Il est possible de préciser cette période en heures, jours ou semaines à l'aide du bouton .

Encours partagé

Si l’offre distributeur permet les encours partagés, lorsque vous configurez un profil, une icône située à droite du nom de la règle vous informe si l’encours est partagé avec d’autres boutiques ou s’il est privé :

indique que l'encours est partagé.

indique que l'encours est privé.

Passez le curseur de votre souris au-dessus d'une icône pour obtenir plus d'informations :

Autres règles

Le paramétrage se fait de la même manière pour de nombreuses règles :

Vous voulez paramétrer la règle... Veuillez consulter le paramétrage de la règle...
  • Encours par adresse IP
  • Encours par identifiant client
  • Encours par mandat
  • Encours par IBAN
Encours carte
  • Nombre de cartes par client
  • Nombre de cartes par adresse IP
  • Nombre d'IBAN par adresse IP
  • Nombre d'adresses IP par IBAN
  • Nombre de clients par IBAN
  • Nombre d'IBAN par client
  • Nombre de mandats par adresse IP
Nombre de clients par carte

Paramétrer les règles diverses

Réputations d'adresse IP

Vous pouvez mettre à jour la liste des statuts d’adresse IP non autorisés  :

  • cliquez sur le bouton pour faire passer l'élément sélectionné de la colonne Disponible à la colonne Statuts d'adresse non autorisés  ;
  • ou cliquez sur le bouton pour retirer l'élément sélectionné de la liste des statuts d'adresse non autorisés .

Veuillez consulter l'Annexe 3 : réputations d'adresse IP, pour plus d'informations.

Plage de montants

Le champ Montant minimum permet de préciser le montant minimum autorisé pour une transaction. Un rappel de la devise d’expression du montant minimum est indiqué au début de ce champ.

Le champ Montant maximum permet de préciser le montant maximum autorisé pour une transaction.

Le bouton Activer le mode avancé permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager des plages de montants impliquant respectivement un résultat positif ou négatif. Le résultat est neutre si le montant n’est dans aucune des deux plages.

Adresse-e-mail-gratuite

Le champ Nom de domaine vous permet de saisir un nom de domaine pour l’ajouter à la liste des noms de domaine interdits.

Dans l’exemple ci-dessus, hotmail.com a été ajouté à la liste, ce qui signifie que les adresses e-mail en @hotmail.com seront interdites.

Vous pouvez utiliser un astérisque pour la dernière partie du nom de domaine afin de prendre en compte toutes les possibilités. Par exemple, vous pouvez ajouter hotmail.* à la liste afin de refuser les adresses en @hotmail.com, @hotmail.fr, @hotmail.be , etc.

Authentification 3-D Secure

La liste des statuts non autorisés se met à jour selon la même logique que pour les réputations d'adresse IP.

Cette liste ne présente que les statuts 3-D Secure ayant une pertinence en termes de filtrage par le contrôle de risque. Vous n’y retrouverez notamment pas les statuts SUCCESS, CANCEL ou BYPASS. Le distributeur peut imposer des règles d’acceptation de statuts 3-D Secure en amont des contrôles de lutte contre la fraude. Il est donc possible que des transactions ayant certains statuts de cette liste soient interrompues avant même qu’un contrôle de lutte contre la fraude soit effectué. Pour plus de détails sur les statuts 3-D Secure, reportez-vous à l’Annexe 5 : statuts d'authentification 3-D Secure.

Le bouton Activer le mode avancé vous permet de passer la règle en mode de configuration avancée. Ce mode vous donne la possibilité d’avantager ou de désavantager les statuts 3-D Secure (qui vont donc donner respectivement un résultat positif ou négatif). Vous pouvez obtenir un résultat neutre si le statut est dans la liste des statuts disponibles .

Date d'expiration de la carte

Le champ Période vous permet de préciser le nombre de mois avant expiration de la carte en dessous duquel la transaction sera refusée.

Autres règles

Le paramétrage se fait de la même manière pour de nombreuses règles :

Vous voulez paramétrer la règle... Veuillez consulter le paramétrage de la règle...
  • Carte commerciale (et pays de la carte)
Pays de la carte
Attention cependant, la règle Carte commerciale (et pays de la carte) n'est pas éligible au mode de configuration avancé.
  • Vérification d'adresse (InfoScore)
Authentification 3-D Secure
  • Carte en opposition
  • Carte virtuelle
  • Carte à autorisation systématique
  • Carte réseau CB
  • Syntaxe d'adresse e-mail
  • Vérification de compte (InfoScore)
Ces règles ne nécessitent pas de configuration particulière.

Paramétrer les règles de liste

Alimenter les listes

Les règles de liste ne nécessitent pas de configuration particulière.

Mais activer une règle de liste dans un profil ne suffit pas : vous devez aussi gérer la liste en elle-même. Vous disposez pour cela de trois possibilités :

  • ajouter des éléments dans la liste via Sogenactif Office Batch   ou
  • ajouter des éléments dans la liste via Sogenactif Office Serveur SOAP ou JSON  ou
  • utiliser l'onglet Alimenter les listes .

Note: les solutions utilisant Sogenactif Office Serveur SOAP, Sogenactif Office Serveur JSON ou Sogenactif Office Batch sont décrites dans les guides utilisateurs des applications correspondantes. Nous n'expliquerons dans cette documentation que la solution utilisant l'interface de lutte contre la fraude.

Pour alimenter les listes via le Portail Sogenactif , suivez cette procédure :

Cliquez sur l'onglet "Alimenter les listes".

En accédant à cette rubrique vous obtenez l'accès aux listes à votre disposition : celles-ci varient en fonction de l'offre à laquelle vous avez souscrit. Veuillez consulter la liste des règles pour connaître l'ensemble des règles de listes existantes.

Après avoir cliqué sur l'onglet approprié, vous pouvez choisir de gérer la liste noire, grise ou blanche en cliquant sur la flèche correspondante sur la droite :

Lors de la modification d'une liste, vous pouvez :

  • ajouter une valeur à la liste en précisant un motif d'ajout ;
  • effacer un élément de la liste ;
  • déplacer un élément d'une liste grise vers une liste noire.

Ajouter une valeur à une liste

Vous devez saisir dans le champ de données approprié la valeur que vous souhaitez ajouter à une liste :

En cliquant sur le bouton , une fenêtre popup apparaît et vous permet de sélectionner un motif d'ajout de la valeur.

Ajouter une valeur à la liste des numéros de cartes

La gestion des numéros de carte sur les listes noire, grise ou blanche est différente de la gestion des autres listes.

Vous pouvez ajouter un numéro de carte :

  • via la référence de transaction liée au numéro de carte ;
  • via le numéro de carte ;

Après avoir sélectionné le mode d’ajout via une liste déroulante, vous pouvez saisir le token, le numéro de carte ou la référence de transaction.

Vous pouvez ajouter des numéros de cartes par références de transactions, en utilisant des références de transactions (clé primaire Sogenactif  2.0), ou en utilisant des identifiants et dates de transactions (clé primaire Sogenactif  1.0).

L'ajout par token est uniquement disponible si vous possédez l'option associée.

Sélectionner un motif d'ajout d'élément à une liste

Après avoir cliqué sur le bouton , sélectionnez le motif dans la fenêtre popup et cliquez sur OK , l'élément est ajouté à la liste.

Ajouter un motif peut s'avérer pratique ultérieurement (par exemple pour ajouter un certain identifiant client à une liste blanche). Les motifs peuvent être sélectionnés parmi une liste prédéfinie en fonction du type approprié à la liste. Mais vous pouvez également décider de conserver la valeur par défaut « Non mentionné ».

Les motifs sont affichés à côté des éléments :

Ils sont identiques pour les listes noires et grises. Voici un récapitulatif de ces motifs :

Type de liste Motifs pour les listes blanches Motifs pour les listes noires et grises
Adresses e-mail
Non mentionné
VIP
Adresse e-mail approuvée
Client B2B
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
Adresse e-mail inconnue
Impayé
Débit impossible
Répudiation porteur
Tentative de paiement multiple
Adresses IP
Non mentionné
VIP
Client B2B
Adresse IP approuvée
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
Adresse IP inconnue
Impayé
Débit impossible
Répudiation porteur
Tentative de paiement multiple
Codes postaux
Non mentionné
Expérience positive
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Code postal inconnu
Suspicion générale
Identifiants client
Non mentionné
VIP
Client B2B
Client approuvé
Participant promotion
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
Impayé
Débit impossible
Répudiation porteur
Tentative de paiement multiple
Noms de clients
Non mentionné
VIP
Client B2B
Nom approuvé
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
Impayé
Débit impossible
Répudiation porteur
Tentative de paiement multiple
Numéros de carte
Non mentionné
VIP
Client B2B
Numéro de carte de confiance
Carte de voyage
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Carte perdue
Carte volée
Carte inconnue
Carte interdite
Impayé
Débit impossible
Répudiation porteur
Tentative de paiement multiple
Numéros de téléphone
Non mentionné
VIP
Client B2B
Numéro de téléphone approuvé
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
Numéro de téléphone inconnu
Impayé
Débit impossible
Répudiation porteur
Tentative de paiement multiple
Plages de BIN
Non mentionné
Plage de BIN approuvée
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
BIC
Non mentionné
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
IBAN
Non mentionné
VIP
Client B2B
IBAN approuvé
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
Tentative de paiement multiple
Débit impossible
Mandats
Non mentionné
VIP
Client B2B
ID de mandat approuvé
Non mentionné
Fraude suspectée
Expérience négative
Liste noire externe
Suspicion générale
Tentative de paiement multiple
Débit impossible

Exporter une liste

Il est possible d’exporter le contenu d’une liste dans un fichier au format CSV en cliquant sur le bouton . Un fichier contenant tous les éléments de la liste est alors généré et automatiquement téléchargé par votre navigateur.

Veuillez consulter l'Annexe 11 : format de fichier d'export de liste, pour en savoir plus sur le contenu du fichier CSV.

Supprimer une valeur de la liste

Vous pouvez également effacer des valeurs de la liste, par exemple si elles ne sont plus valables ou ont été ajoutées par erreur :

  • sélectionnez une ou plusieurs valeurs à effacer en cochant la case à côté de l'entrée appropriée ;
  • puis cliquez sur le bouton Supprimer les entrées sélectionnées .

Pour éviter qu'une valeur ne soit effacée par erreur, vous devez cliquer sur Confirmer dans la fenêtre de confirmation.

Déplacer une valeur

Une valeur peut être déplacée d'une liste grise vers une liste noire, par exemple si la gravité d'un cas augmente. Cela vous évite d'avoir à effacer une valeur de la liste grise et de devoir la saisir de nouveau dans la liste noire. Voici la procédure :

  • sélectionnez une ou plusieurs valeurs à déplacer en cochant les cases en regard des entrées désirées ;
  • puis déplacez-les en utilisant le bouton Déplacer l'élément sélectionné vers la liste noire .

Pour éviter qu'un élément ne soit effacé par erreur, vous devez cliquer sur Oui dans la fenêtre de confirmation.

Attention: une valeur ne peut appartenir qu'à une seule liste. Il n'est par exemple pas possible de placer la même valeur dans une liste grise et dans une liste noire.

Listes partagées

Une offre distributeur permettant les listes partagées donne la possibilité à une boutique de partager ses éléments avec d’autres boutiques appartenant au même groupe commercial. Il est toujours possible d’avoir une liste privée uniquement utilisée par une seule boutique.

  • La configuration des profils

Lorsque vous configurez un profil, des icônes situées à droite des noms de règles vous indiquent si la liste est partagée avec d'autres boutiques ou si elle est privée :

indique que la liste est partagée.

indique que la liste est privée.

Passez le curseur de votre souris au-dessus d'une icône pour obtenir plus d'informations :

  • Les listes elles-mêmes

Une boutique peut partager ses éléments avec d’autres boutiques appartenant au même groupe commercial. Il est toujours possible d’avoir une liste privée uniquement utilisée par une seule boutique.

Vous pouvez voir si une liste est privée ou partagée au-dessus du formulaire permettant d’ajouter un nouvel élément dans la liste :

indique que la liste est partagée.

indique que la liste est privée.

Quand la boutique sélectionnée partage une liste, la gestion des listes est identique à ce qui est décrit dans les sections précédentes. La seule différence est qu’une boutique ne peut supprimer uniquement que les éléments qu’elle a préalablement ajoutés. Il n’est pas possible de supprimer un élément ajouté par une autre boutique.

La boutique ayant ajouté un élément dans la liste est affichée dans la colonne  ID de boutique . Cette colonne est visible uniquement lorsque la liste est partagée :

Un système de « verrou » permet à plusieurs boutiques d’ajouter le même élément dans la liste. Chaque boutique ajoutant un élément ajoute un « verrou » sur cet élément. Si au moins un verrou existe sur un élément, il est dans la liste. Un élément est considéré comme absent de la liste lorsque chaque verrou sur cet élément est supprimé par la boutique l’ayant ajouté.

Listes volumineuses

Lorsqu’une liste blanche, grise ou noire devient trop volumineuse, les éléments de la liste affichés dans l’interface sont limités aux 600 premiers éléments trouvés.

Dans ce cas, un message d’alerte s'affiche au-dessus de la liste et une fonctionnalité de recherche s’active afin de vous permettre de retrouver les éléments présents dans la liste et non affichés dans l’interface :

Si vous sélectionnez Ajout d’élément , le formulaire vous permet d'ajouter de nouveaux éléments (voir les paragraphes 'Ajouter une valeur à une liste' et 'Ajouter une valeur à la liste des numéros de carte').

Si vous sélectionnez Recherche d’élément(s) , le formulaire vous permet d’effectuer une recherche à partir d’une valeur précise (recherche spécifique) ou partielle (filtrage). Cliquez sur le bouton pour rafraîchir la liste avec le ou les élément(s) présent(s) dans la liste et correspondant à la valeur saisie dans le champ de recherche :

Recherche d'un élément spécifique

Filtrage de la liste

Après avoir fait une ou plusieurs recherches successives, le bouton vous permet de revenir à l’affichage initial des 600 premiers éléments de la liste.

Paramétrer les règles panier

Administrer les listes de produits à risque

L'administration des listes de produits à risque s'effectue en cliquant sur l'onglet Listes de produits à risque :

Vous accédez à la page d'administration des listes de produits à risque :

Vous y retrouvez l'ensemble des listes de produits à risque déjà créées.

Cliquez sur pour modifier une liste ou sur pour la supprimer.

Créer une liste

Cliquez sur le bouton pour créer une nouvelle liste de produits à risque.

Vous disposez alors de deux possibilités :

  • Créer une nouvelle liste

Renseignez le nom de la nouvelle liste puis cliquez sur OK .

ou

  • Utiliser une liste partagée

Il vous suffit de sélectionner dans le menu déroulant la liste partagée à utiliser.

Les listes choisies et/ou créées sont ensuite visibles sur la page d’administration des listes de produits à risque : vous pouvez y effectuer des opérations sur chaque liste et sur la page de paramétrage de profil afin de vous permettre de choisir vos listes.

Exporter/importer une liste

Vous avez la possibilité d'exporter la liste au format Excel (.CSV) en cliquant sur le bouton . Le fichier généré contient tous les produits de la liste et est téléchargé automatiquement par votre navigateur.

Vous pouvez également importer une liste (fichier au format .CSV) en cliquant sur le bouton . Une fois l’import effectué, l’ensemble de la liste est mis à jour avec les produits contenus dans le fichier importé. Les produits ne se trouvant pas dans le fichier sont supprimés de la liste.

Veuillez consulter l'Annexe 11 : format de fichier d'export de liste, pour en savoir plus sur le contenu du fichier CSV.

Ajouter/modifier/supprimer un produit

Vous pouvez ajouter manuellement un produit à une liste en cliquant sur le bouton .

Pour ajouter un produit à une liste, vous devez remplir trois champs :

  • le code du produit ;
  • le libellé ;
  • la date de validité.

IMPORTANT: le code du produit est l’information utilisée pour retrouver les produits du panier. Il est donc important que le code concorde entre les listes de produits et les paniers des transactions.

Une fois ces champs remplis et validés, le produit est ajouté directement à la liste des produits à risque.

Cliquez sur l'icône pour modifier un produit, ou sur l'icône pour le supprimer.

Liste de produits à risque

Cette section vous permet de configurer la liste des produits à risque à utiliser. Les différentes listes affichées dans cette section sont celles qui ont été créées au préalable depuis l’onglet Alimenter les listes -> Listes de produits à risque.

Cochez les listes de produits à risque que vous souhaitez utiliser. Plusieurs listes peuvent être utilisées simultanément.

indique que la liste est partagée.

indique que la liste est privée.

Quantité de produits

Vous pouvez paramétrer la quantité maximale de produits dans un panier en saisissant manuellement la quantité désirée dans le champ ci-dessous :

Quantité de produits à risque

Les différentes listes affichées dans cette section sont celles qui ont été créées au préalable depuis l’onglet Alimenter les listes -> Listes de produits à risque .

Cochez les listes que vous souhaitez utiliser. Plusieurs listes peuvent être utilisées simultanément.

Pour chaque liste de produits, vous pouvez définir la quantité maximale par produit et la quantité maximale de tous les produits en saisissant manuellement ces quantités dans les deux champs numériques affichés sous chaque liste :

indique que la liste est partagée.

indique que la liste est privée.

Ratio de produits à risque

Cette règle se configure de la même manière que la règle 'Quantité de produits à risque', à l'exception des valeurs saisies qui sont des ratios et non des quantités.

Partager des listes

La page d'administration des listes partagées de produits à risque se présente comme suit :

On y retrouve les mêmes fonctionnalités que celles présentées dans le paragraphe 'Administrer des listes de produits à risque' : vous pouvez donc utiliser les listes créées à partir de cette page en vous rendant sur la page d’administration des listes de produits à risque.

Historisation des actions sur l'interface

Une historisation des modifications faites via l’interface est disponible dans l’onglet Historisation .

Vous pouvez y voir toutes les modifications faites sur vos profils, mais également les changements impactant votre lutte contre la fraude : la publication d’un modèle de profil ou l’association à un groupe/une liste partagé(e). Les modifications de contenu de vos listes marchandes (liste d’e-mail, de nom, etc.) ne sont pas sauvegardées.

Tableau des modifications

Lorsque vous arrivez sur la page des modifications, le tableau n’est pas filtré et contient toutes les modifications concernant la boutique ordonnées de la plus récente à la plus ancienne.

La partie supérieure du tableau vous permet de filtrer la liste des résultats selon 4 critères : une date minimum, une date maximum, un nom d’utilisateur ou un type d’historique (profil marchand, modèle de profil ou association de groupe).

Après avoir cliqué sur , l'application recharge le tableau avec les données filtrées.

Chaque ligne du tableau présente la date à laquelle l’action a été effectuée, l’utilisateur ayant effectué l’action, l’entité modifiée ainsi qu’une brève description de l’action.

Cliquez sur l'icône pour comparer l’état de l’objet avant et après modification.

Détail des modifications

Profil marchand et modèle de profil

Après avoir cliqué sur l’icône , une fenêtre popup apparaît et vous présente une comparaison entre le profil avant et après modification(s). Cette fenêtre n'affiche par défaut que les modifications mais vous pouvez afficher également les valeurs inchangées en cochant la case Afficher les valeurs inchangées (toutes les données du profil) .

La comparaison est composée de 3 parties :

  • informations générales sur le profil : nom, moyens de paiement, devise ;
  • liste des règles décisives ;
  • liste des règles informatives.

Modification sur une règle

La modification des règles suit un code couleurs :

Couleur Signification
Le nom de la règle est en rouge et le symbole la précède. La règle a été supprimée du profil.
Le nom de la règle est en vert et le symbole la précède. La règle a été ajoutée au profil.
Le nom de la règle est en orange et le symbole la précède. La règle a été déplacée dans le profil : cela signifie qu’elle a changé de mode (de décisive à informative et vice-versa) ou qu’elle est décisive et que son rang d’exécution a changé.
Le nom de la règle est en noir . Le contenu de la règle a changé.
Le nom de la règle est en gris . La règle n'a pas changé (uniquement visible lorsque la case correspondante est cochée).

Exemples :

Nom de la règle et couleur Signification
La règle n'a pas été modifiée.
La règle a été ajoutée en 2e position dans l'ordre d'exécution.
Le mode de la règle est passé de décisif à informatif.
La règle a été déplacée dans l'ordre d'exécution de la position 2 à la position 1.
Le mode de la règle a été modifié d'informatif à décisif avec un ordre d'exécution à 2.
La règle a été supprimée.
La règle n'a pas été déplacée mais le contenu de la règle a été modifié.

Modification sur une valeur

La modification des valeurs suit elle aussi un code couleurs :

Valeur Signification
Valeur en vert . Il s'agit d'une nouvelle valeur.
Valeur en rouge et barrée . Il s'agit d'une ancienne valeur.
Valeur en noir . La valeur est inchangée.

Dans le cas d'une modification, l'ancienne valeur en rouge sera suivie de la nouvelle valeur en vert.

Association de groupe/liste

Après avoir cliqué sur l’icône , une fenêtre popup apparaît et vous présente une comparaison entre le nouveau groupe (ou la nouvelle liste) auquel la boutique est rattachée, et l’ancien groupe (ou l'ancienne liste). Vous voyez donc l’ancien groupe en rouge barré et le nouveau groupe en vert  :

Annexes

Annexe 1 : désactivation dynamique de certaines règles du profil

Si vous souhaitez empêcher l’exécution d’une des règles de votre profil pour une transaction, vous devez envoyer l'élément correspondant à la règle dans l'élément fraudData de la demande de paiement.

fraudData.bypass3DS Désactiver l'authentification 3D
fraudData.bypassCtrlList Désactiver les règles standards
fraudData.bypassInfoList Obsolète

fraudData.bypass3DS

Valeur Description
ALL Ignorer la procédure 3DS (pour les paiements CB, VISA, MASTERCARD et AMEX)
MERCHANTWALLET Ignorer la procédure 3DS pour les paiements en 1 clic (pour les paiements CB, VISA, MASTERCARD et AMEX)

fraudData.bypassCtrlList

Valeur Description
AccountVerification Désactiver la règle Vérification de compte (InfoScore)
AddressVerification Désactiver la règle Vérification d’adresse (InfoScore)
BlackBic Désactiver la règle Liste noire de BIC
BlackBinCard Désactiver la règle Liste noire de plages de BIN
BlackCard Désactiver la règle Liste noire de numéros de carte
BlackCustomerId Désactiver la règle Liste noire d’identifiants de clients
BlackCustomerName Désactiver la règle Liste noire de noms de clients
BlackEmail Désactiver la règle Liste noire d’adresses e-mail
BlackIban Désactiver la règle Liste noire d’IBAN
BlackIp Désactiver la règle Liste noire d’adresses IP
BlackMandate Désactiver la règle Liste noire de mandats
BlackPhoneNumber Désactiver la règle Liste noire de numéros de téléphone
BlackPostalCode Désactiver la règle Liste noire de codes postaux
CapCollarAmount Désactiver la règle Plage de montants
CardCountry
ForeignBinCard (déprécié)
Désactiver la règle Pays de la carte
CBScheme Désactiver la règle Carte réseau CB
CommercialCard
CorporateCard (déprécié)
Désactiver la règle Carte commerciale (et pays de la carte)
EmailSyntax Désactiver la règle Syntaxe d’adresse e-mail
ECard Désactiver la règle Carte virtuelle
ExpiryDate Désactiver la règle Date d’expiration de la carte
FreeEmail Désactiver la règle Adresse e-mail gratuite
GreyBic Désactiver la règle Liste grise de BIC
GreyBinCard Désactiver la règle Liste grise de plages de BIN
GreyCard Désactiver la règle Liste grise de numéros de carte
GreyCustomerId Désactiver la règle Liste grise d’identifiants de clients
GreyCustomerName Désactiver la règle Liste grise de noms de clients
GreyEmail Désactiver la règle Liste grise d’adresses e-mail
GreyIban Désactiver la règle Liste grise d’IBAN
GreyIp Désactiver la règle Liste grise d’adresses IP
GreyMandate Désactiver la règle Liste grise de mandats
GreyPhoneNumber Désactiver la règle Liste grise de numéros de téléphone
GreyPostalCode Désactiver la règle Liste grise de codes postaux
HotList Désactiver la règle Carte en opposition
IbanCountry Désactiver la règle Pays de l’IBAN
IpCountry Désactiver la règle Pays de l’adresse IP
IpReputations Désactiver la règle Réputation d’adresse IP
MaxCardPerCustomerId Désactiver la règle Nombre de cartes par client
MaxCardPerIp Désactiver la règle Nombre de cartes par adresse IP
MaxCustidPerIban Désactiver la règle Nombre de clients par carte
MaxCustomerIdPerCard Désactiver la règle Nombre de clients par carte
MaxIbanPerCustid Désactiver la règle Nombre d’IBAN par client
MaxIbanPerIp Désactiver la règle Nombre d’IBAN par adresse IP
MaxCardPerIp Désactiver la règle Nombre de cartes par adresse IP
MaxIpPerIban Désactiver la règle Nombre d’adresses IP par IBAN
MaxMandatePerIp Désactiver la règle Nombre de mandats par adresse IP
MaxQuantityPerProduct Désactiver la règle Quantité de produits
RiskyProductList Désactiver la règle Liste de produits à risque
RiskyProductQuantity Désactiver la règle Quantité de produits à risque
RiskyProductRatio Désactiver la règle Ratio de produits à risque
SimilarityBillingCardCountry Désactiver la règle Pays de livraison et de la carte
SimilarityDeliveryBillingCountry Désactiver la règle Pays de livraison et de facturation
SimilarityDeliveryBillingPostalCode Désactiver la règle Codes postaux de livraison et de facturation
SimilarityDeliveryCardCountry Désactiver la règle Pays de livraison et de la carte
SimilarityDeliveryIbanCountry Désactiver la règle Pays de livraison et de l’IBAN
SimilarityIpCardCountry
SimilityIpCard (déprécié)
Désactiver la règle Pays de la carte et de l’adresse IP
SimilarityIpIbanCountry Désactiver la règle Pays de l’IBAN
SimilarityPhoneIbanCountry Désactiver la règle Pays du numéro de téléphone et de l’IBAN
SystematicAuthorizationCard Désactiver la règle Carte à autorisation systématique
VelocityCard Désactiver la règle Encours carte
VelocityCustomerId Désactiver la règle Encours par identifiant client
VelocityIban Désactiver la règle Encours par IBAN
VelocityIp Désactiver la règle Encours par adresses IP
VelocityMandate Désactiver la règle Encours par mandat
WhiteBic Désactiver la règle Liste blanche de BIC
WhiteBinCard Désactiver la règle Liste blanche de plages de BIN
WhiteCard Désactiver la règle Liste blanche de numéros de carte
WhiteCustomerId Désactiver la règle Liste blanche d’identifiants de clients
WhiteCustomerName Désactiver la règle Liste blanche de noms de clients
WhiteEmail Désactiver la règle Liste blanche d’adresses e-mail
WhiteIban Désactiver la règle Liste blanche d’IBAN
WhiteBinCard Désactiver la règle Liste blanche de plages de BIN
WhiteIp Désactiver la règle Liste blanche d’adresses IP
WhiteMandate Désactiver la règle Liste blanche de mandats
WhitePhoneNumber Désactiver la règle Liste blanche de numéros de téléphone
WhitePostalCode Désactiver la règle Liste blanche de codes postaux
3DSStatus Désactiver la règle Authentification 3-D Secure
All Désactiver tous les règles

Annexe 2 : complementary codes

Valeurs Règle Description
Empty Pas de contrôle effectué.
00 Tous Tous les contrôles auxquels vous avez adhéré se sont effectués avec succès.
02 Encours carte La carte utilisée a dépassé l’encours autorisé.
03 Liste grise de numéros de carte La carte utilisée appartient à votre « liste grise ».
06 Pays de la carte Mode simple : le code pays associé au numéro de carte n'appartient pas à la liste des pays que vous avez autorisés.
Mode avancé : le code pays associé au numéro de carte appartient à la liste des pays que vous avez désavantagés ou avantagés.
07 Carte virtuelle e-Carte détectée.
08 Liste grise de plages de BIN Le BIN de la carte utilisée appartient à une plage définie dans votre « liste grise ».
10 Pays de l’adresse IP Mode simple : Pays IP interdit.
Mode avancé : Pays IP désavantagé ou Pays IP avantagé.
11 Carte en opposition Carte en opposition.
12 Pays de la carte et de l’adresse IP Mode simple : combinaison pays carte/IP interdite.
Mode avancé : combinaison pays carte/IP désavantagée ou avantagée.
14 Carte à autorisation systématique Carte à autorisation systématique.
16 Encours par adresse IP En-cours IP KO.
17 Authentification 3-D Secure Mode simple : blocage relatif au statut de l'authentification 3D-Secure.
Mode avancé : blocage ou acceptation relative au statut de l'authentification 3D-Secure.
18 Carte commerciale (et pays de la carte) Le numéro de carte correspond à un numéro de carte commerciale.
19 Carte réseau CB Le numéro de carte n'appartient pas au réseau CB.
20 Encours par identifiant client En-cours client dépassé.
21 Nombre de clients par carte En-cours client par carte dépassé.
22 Nombre de cartes par client En-cours de carte par client dépassé.
23 Date d’expiration de la carte La date de fin de validité de la carte est proche.
25 Plage de montants Mode simple : le montant est en dehors de l'intervalle autorisé défini.
Mode avancé : le montant est dans l'intervalle désavantagé ou dans l’intervalle avantagé défini.
26 Codes postaux de livraison et de facturation Combinaison adresse de facturation/adresse de livraison interdite.
27 Adresse e-mail gratuite Au moins l'une des adresses e-mail fournies appartient à un service de courrier électronique gratuit.
28 Liste noire d’identifiants clients L'identifiant du client appartient à votre « liste noire ».
29 Liste grise d’identifiants clients L'identifiant du client appartient à votre « liste grise ».
30 Pays de livraison et de facturation Combinaison pays de facturation/pays de livraison interdite.
31 Liste noire d’adresses e-mails Au moins l'une des adresses e-mail fournies appartient à votre « liste noire ».
32 Liste grise d’adresses e-mails Au moins l'une des adresses e-mail fournies appartient à votre « liste grise ».
33 Liste noire de numéros de téléphone Au moins l'un des numéros de téléphone fournis appartient à votre « liste noire ».
34 Liste grise de numéros de téléphone Au moins l'un des numéros de téléphone fournis appartient à votre « liste grise ».
35 Liste noire de noms de clients Au moins l'un des noms de contact fournis appartient à votre « liste noire ».
36 Liste grise de noms de clients Au moins l'un des noms de contact fournis appartient à votre « liste grise ».
37 Liste noire d’adresses IP L'adresse IP de l'acheteur appartient à votre « liste noire ».
38 Liste grise d’adresses IP L'adresse IP de l'acheteur appartient à votre « liste grise ».
39 Liste noire de codes postaux par pays La combinaison pays/code postal appartient à la « liste noire » du commerçant
3L Garantie d'authentification Refus de la transaction en raison de non garantie de la transaction par une entité (l'acquéreur, le fournisseur de portefeuille, etc.)
40 Liste grise de codes postaux par pays La combinaison pays/code postal appartient à la « liste grise » du commerçant
41 Liste grise de plages de BIN Le BIN de la carte utilisée appartient à une plage définie dans la « liste grise » du commerçant
42 Pays de livraison et de la carte Mode simple : combinaison pays de la carte/pays de livraison interdite.
Mode avancé : combinaison pays de la carte/pays de livraison désavantagé ou avantagée.
43 Carte commerciale (et pays de la carte) Le numéro de carte correspond à un numéro de carte commerciale mais le pays d'émission de la carte ne correspond pas à un pays d'émission de carte commerciale
44 Réputations d’adresse IP L'adresse IP de l'acheteur est interdite
45 Nombre de cartes par adresse IP Le seuil du nombre de cartes différentes pour une même adresse IP est dépassé.
46 Syntaxe d'adresse e-mail Le format de l'adresse e-mail fournie n'est pas correct
47 Pays de facturation et de la carte Mode simple : Combinaison pays de la carte/pays de facturation interdite. Mode avancé : Combinaison pays de la carte/pays de facturation désavantagée ou avantagée.
48 Vérification d’adresse (InfoScore) Vérification de l'adresse de livraison fournie. A ce jour, les contrôles de l'adresse sont applicables dans le cas du moyen de paiement ELV (contrôles InfoScore)
49 Vérification de compte (InfoScore) Validation du compte bancaire fourni. A ce jour, les contrôles du compte bancaire sont applicables dans le cas du moyen de paiement ELV (contrôles InfoScore)
50 Liste noire de numéros de carte La carte utilisée appartient à la « liste noire » du commerçant
51 Liste de produits à risque Au moins l’un des produits du panier appartient à une liste de produits à risque
52 Quantité de produits à risque La quantité de produits à risque contenus dans le panier est dépassée
53 Ratio de produits à risque Le ratio prix de produits à risque/montant total contenu dans le panier est dépassée
54 Quantité de produits Le nombre de produits du panier a dépassé le seuil autorisé
55 Pays de l’IBAN Mode simple : Le code pays associé à l’IBAN n'appartient pas à la liste des pays autorisés par le commerçant. Mode avancé : Le code pays associé à l’IBAN appartient à la liste des pays désavantagés ou appartient à la liste des pays avantagés par le commerçant.
56 Pays de livraison et de l’IBAN Mode simple : Combinaison pays de livraison/IBAN interdite. Mode avancé : Combinaison pays de livraison/IBAN désavantagés ou avantagée.
57 Pays du numéro de telephone et de l’IBAN Mode simple : Combinaison pays du numéro de téléphone/IBAN interdite. Mode avancé : Combinaison pays du numéro de téléphone/IBAN désavantagés ou avantagée.
58 Pays de l’adresse IP et de l’IBAN Mode simple : Combinaison pays de l’IP/IBAN interdite. Mode avancé : Combinaison pays de l’IP/IBAN désavantagés ou avantagée.
59 Nombre d’IBAN par adresse IP Le seuil du nombre d’IBAN différents pour une même adresse IP est dépassé
60 Nombre d’adresses IP par IBAN Le seuil du nombre d’adresses IP différentes pour un même IBAN est dépassé
61 Nombre de clients par IBAN Le seuil du nombre de clients différents pour un même IBAN est dépassé
62 Nombre d’IBAN par client Le seuil du nombre d’IBAN différents pour un même client est dépassé
63 Nombre de mandats par adresse IP Le seuil du nombre de mandats différents pour une même adresse IP est dépassé.
64 Encours par mandat Le mandat utilisé a dépassé l’encours autorisé
65 Encours par IBAN L’IBAN utilisé a dépassé l’encours autorisé
66 Liste noire de BIC Le BIC utilisé appartient à la « liste noire » du commerçant
67 Liste grise de BIC Le BIC utilisé appartient à la « liste grise » du commerçant
68 Liste noire d’IBAN L’IBAN utilisé appartient à la « liste noire » du commerçant
69 Liste grise d’IBAN L’IBAN utilisé appartient à la « liste grise » du commerçant
70