Introduction
WL Sips 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 en plusieurs fois, …).
L'objectif de ce document est de décrire les règles antifraudes en mode Business Score, d'expliquer la manière de les mettre en oeuvre et de les configurer.
La terminologie Business Score correspond au calcul du score global du risque de la transaction par agrégation de la pondération de chaque règle antifraude. Vous déterminez en toute autonomie le profil des transactions que vous considérez « à risque ».
À 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 – Business Score » et souhaitent bénéficier d’un outil de lutte contre la fraude administré par eux-mêmes sur le Merchant Extranet.
Pour avoir une vue d’ensemble de la solution WL Sips, nous vous conseillons de consulter les documents suivants :
- Présentation fonctionnelle ;
- Guide de Configuration des fonctionnalités ;
- Glossaire.
Vue d'ensemble
Accéder au Merchant Extranet
Toutes les fonctionnalités de lutte contre la fraude décrites dans cette documentation sont gérées dans le Merchant Extranet.
Vous devez donc avoir souscrit à l’offre Business Score pour pouvoir accéder à ces fonctionnalités.
L’accès au Merchant Extranet se fait via l’URL suivante :
https://mex.fr.worldline.com/portal/home
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 Merchant Extranet' 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.
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 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.
Règle positive et règle négative
Règle positive
Une règle positive a pour objectif de détecter une condition favorable au niveau de l’acceptation de la transaction (exemple : identifiant client présent dans la liste blanche des clients).
Elle retourne un score d’une valeur supérieure ou égale à zéro en fonction du paramétrage de la règle si la condition est remplie, et elle ne retourne pas de score dans le cas contraire.
Actuellement les règles positives 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 négative
Une règle négative a pour objectif de détecter une condition défavorable au niveau de l’acceptation de la transaction (exemple : identifiant client présent dans la liste noire des clients).
Elle retourne un score d’une valeur inférieure ou égale à zéro en fonction du paramétrage de la règle si la condition est remplie, et elle ne retourne pas de score dans le cas contraire.
Les règles du type négatif 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.
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 ou négative.
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 et négative. 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 |
|
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 :
Plage négative :
|
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
WL Sips 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 3-D Secure pour les transactions considérées comme non risquées.

Mode pré-autorisation
En mode pré-autorisation (le mode par défaut de contrôle de lutte contre la fraude de WL Sips), 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 | WL Sips / commerçant | Impacts sur l'acceptation |
---|---|---|
Profil informatif | WL Sips | Pas d’impact, WL Sips 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 | WL Sips | Si le résultat est négatif, la transaction est
refusée par WL Sips, il n’y a pas de demande
d’autorisation. Si le résultat est positif ou neutre,
WL Sips 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é à WL Sips la prise de
décision sur la fraude. Toutefois le commerçant peut analyser
le motif. |
|
Profil mixte | WL Sips | 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 WL Sips 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 | WL Sips / commerçant | Impacts sur l'acceptation |
---|---|---|
Profil décisif | WL Sips | Si le résultat est positif, WL Sips
débraye l’authentification 3-D Secure et poursuit le contrôle
pré-autorisation. Si le résultat est négatif ou neutre,
WL Sips 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. |
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 WL Sips. 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).
Il existe 3 types de profils antifraude :
- le profil « offre » du distributeur ;
- les modèles de profil ;
- les profils marchands.
Un profil « offre » distributeur est défini par le distributeur et administré par Worldline. Il définit le périmètre des règles disponibles et des configurations éventuellement imposées. Si une boutique n’a pas de profil adapté au moyen de paiement utilisé alors c’est le profil offre distributeur qui s’applique.
Les modèles de profil sont définis et administrés par WL Sips, ils sont utilisés comme modèle pour créer les profils marchands.
Les profils marchands sont définis par vous pour votre boutique et administrés par vous et/ou le distributeur (selon le choix du distributeur). Ils peuvent être créés à partir d’un profil modèle. Le terme « profil de boutique », parfois également utilisé dans ce document, est équivalent au profil marchand.
Dans la suite de ce document, lorsque la notion de « profil » est évoquée, il s'agit de profils marchands.
Le paramétrage des profils antifraude se fait l'onglet fraude du Merchant Extranet.
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.
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…).
Paramétrage pondéré ou décisif des règles
Illustration du poids du paramétrage :
Paramétrage pondéré
Lors de la définition d'un profil, vous devez choisir, activer et ordonner les règles parmi celles qui vous sont proposées dans votre offre.
À l'activation d'une règle, le poids associé à la règle est à choisir en fonction de son importance :
- les règles positives ont un poids allant de 0 (neutre) à +3 (importance forte) ;
- les règles négatives ont un poids allant de 0 (neutre) à -3 (importance forte).
Si la condition de la règle est remplie, le score obtenu est le poids que vous paramétrez lors de l'activation de la règle dans le profil. Dans le cas contraire, le score obtenu est de 0.
Exemple : une règle négative d'importance moyenne (-2) donnera un score de -2 si la condition est remplie.
Les règles particulièrement importantes à vos yeux peuvent être paramétrées en mode décisif (voir ci-dessous).
Paramétrage décisif
Si l’une des règles est déterminante pour vous, vous pouvez la paramétrer en décisif, ce qui vous permet de prendre une décision sur l’acceptation de la transaction sans tenir compte des autres règles :
- pour les règles positives, le poids est de +4 ;
- pour les règles négatives, le poids est de -4.
Si la condition de la règle décisionnelle est remplie, le résultat des contrôles antifraude est déterminé uniquement en fonction de cette règle, quel que soit le résultat des autres règles. Dans le cas contraire, le résultat des contrôles antifraude est déterminé en fonction du score global.
Définition des plages rouge, orange et verte
En mode Business Score, chaque règle active du profil utilisé évalue un aspect de la transaction et peut produire un score.
Les scores des règles sont ensuite additionnées pour former un score global (veuillez vous référer au calcul du score global pour connaître les détails du calcul). Ce dernier est alors comparé aux seuils orange et vert paramétrés dans le profil afin de prendre une décision quant à la poursuite de la transaction.
Le score global s'inscrit entre deux bornes :
- la borne min. qui est la valeur obtenue si toutes les règles négatives et aucune règle négative se déclenchent ( c.-à-d. la somme des scores des règles négatives) ;
- la borne max. qui est la valeur obtenue si toutes les règles positives et aucune règle négative se déclenchent (c.-à-d. la somme des scores des règles positives).
Lors de la définition du profil, vous devez donc définir les seuils orange et vert entre les deux bornes min. et max., qui délimiteront trois plages de résultats possibles pour le score. Ces plages sont chacune associées à une couleur : vert, orange et rouge (veuillez vous référer aux modes d'exécution et leurs impacts sur l'acceptation pour plus de détails sur les couleurs et leur effet sur les transactions) :
- le seuil orange définit la valeur à partir de laquelle la zone orange commence;
- le seuil vert définit la valeur à partir de laquelle la zone verte commence.
Exemple 1 :
La borne min. est placée à -12 et la borne max. est placée à 0. La plage s'entend donc de -12 à 0.
Le seuil orange est placé à -8. La zone rouge commence donc -12 et d’arrête à -7.
Le seuil vert est placé à -4. La zone orange commence donc à -8 et s’arrête à -5.
La zone verte commence à -4 et s’arrête à 0.
Exemple 2 :
La borne min. est placée à -12 et la borne max. est placée à 0. La plage s'entend donc de -12 à 0.
Le seuil orange et le seuil vert sont tous les placés à -6. Il n'y a donc pas de zone orange.
La zone rouge s'arrête à -7 et la zone verte commence à -6.
Exemple 3 :
Exemple : un profil antifraude est configuré avec trois règles :
- règle 1, négatif, score associé -3 ;
- règle 2, négatif, score associé -2 ;
- règle 3, positif, score associé +3.
Par conséquent, vous devez positionner les seuils orange et vert entre les valeurs -5 (la borne min.) et +3 (la borne max.).
Dans le cas présent :
- le seuil orange est -2 ;
- le seuil vert est +1 ;
- la plage rouge se situe entre le score -5 et -3 ;
- la plage orange se situe entre le score -2 et 0 ;
- la plage verte se situe entre le score +1 et +3.
Déroulement et résultat d'un profil antifraude
Lorsqu’une transaction doit être évaluée, le système de lutte contre la fraude commence par chercher, au sein du paramétrage de la boutique, le profil antifraude associé au moyen de paiement. Si un tel profil n’est pas trouvé, le système utilise le profil par défaut de la boutique.
Le profil antifraude est déroulé avant la demande d'autorisation.
Les règles du profil sont exécutées en parallèle à l’exception des règles paramétrées en décisif qui sont exécutées dans l’ordre que vous définissez. Vous avez toujours la possibilité de débrayer ou de changer le paramétrage d’une ou de plusieurs règles pour une transaction donnée.
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.
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.
Calcul du score global
Le score global, qui est le cumul des scores de toutes les règles, détermine le résultat des contrôles antifraude.
Pour un profil donné comportant n contrôles individuels :
- soit Rk le résultat du contrôle individuel indexé par k dans le
profil :
- 0 si non vérifié,
- 1 si vérifié,
- soit Pk le coefficient de pondération associé au contrôle individuel
indexé par k :
- 0 pour neutre,
- 1 pour faible,
- 2 pour moyen,
- 3 pour élevé,
- 4 pour décisif,
- soit Tk le caractère du contrôle individuel indexé par k :
- +1 si positif,
- -1 si négatif.
Le score global (S) de la transaction contrôlée avec ce profil s'obtiendra grâce à la formule suivante :
Résultat global
Le résultat final des contrôles antifraude de l'offre Business Score est représenté par une couleur. Il existe 5 couleurs.
Trois couleurs représentent le résultat obtenu à partir du score global :
- vert : le score global est supérieur ou égal au seuil vert du profil. Le résultat vert signifie que la transaction n'est pas risquée ;
- orange : le score global est supérieur ou égal au seuil orange du profil et inférieur au seuil vert. Le résultat orange signifie que la transaction est moyennement risquée ;
- rouge : le score global est inférieur au seuil orange du profil. Le résultat rouge signifie que la transaction est risquée.
Deux couleurs représentent un résultat obtenu par déclenchement d'une règle décisive :
- blanc : la condition d'une règle positive paramétrée en mode décisif est remplie, la règle a donné un résultat favorable. Le résultat blanc signifie que la transaction n'est pas risquée ;
- noir : la condition d'une règle négative paramétrée en mode décisif est remplie, la règle a donné un résultat défavorable. Le résultat noir signifie que la transaction est risquée.
Dans le cas où plusieurs règles décisives ont donné des résultats favorables et/ou défavorables, c'est la première règle exécutée de plus haute priorité qui fait foi. Ce qui signifie que l'ordre de définition des règles décisives dans le profil est important.
Il est important de comprendre que c'est la couleur qui décide si la transaction doit être honorée ou non :
- noir ou blanc : la décision est prise sans tenir compte du score global qui n'a qu'une valeur informative ;
- rouge, orange ou vert : la décision est prise à partir du score global de la transaction qui est comparé aux seuils orange et vert paramétrés.
Ainsi, il n'y a pas forcément de cohérence entre la couleur et le score global. Il est donc possible d'obtenir un résultat blanc avec un score global inférieur au seuil orange ou un résultat noir avec un score supérieur au seuil vert.
Exemple : profil paramétré avec 5 règles :
- règle 1 : liste blanche d'identifiants clients paramétrée en décisif (poids +4) ;
- règle 2 : liste noire de numéros de carte paramétrée en décisif (poids -4) ;
- règle 3 : encours par adresse IP (poids -3) ;
- règle 4 : pays de la carte (poids -2) ;
- règle 5 : pays de l'adresse IP (poids -2) ;
Seuil orange = 0, seuil vert = +2
Gestion du résultat orange
L’option CHALLENGE vous permet de mettre les transactions ORANGE en attente (état TO_CHALLENGE) pour vous permettre de vérifier le risque avant de poursuivre les autres étapes d’acceptation : validation, autorisation ou remise en banque.
Si vous ne possédez pas l'option CHALLENGE, la transaction est acceptée.
Vous disposez de X jours pour mesurer le risque de la fraude et valider ou refuser la transaction. X est la valeur maximale entre la validité de l’autorisation et le délai de capture (captureDay) que vous définissez lors du paiement (veuillez-vous reférer à l'exemple ci-dessous).
Pour mesurer le risque de la transaction, vous pouvez exploiter le champ scoreInfo qui contient le détail de l'exécution des règles : ce champ est retourné par WL Sips dans la réponse de paiement (Sips Paypage, Sips Office).
Deux opérations de caisse sont mises à votre disposition :
- acceptChallenge, pour accepter la transaction ;
- refuseChallenge, pour refuser la transaction (état REFUSED).
Ces deux opérations sont disponibles sur les interfaces suivantes :
- Sips Office (veuillez vous reportez aux documentations Sips Office SOAP, Sips Office JSON et Sips Office Batch) ;
- Sips Office Extranet ;
- Merchant Extranet ;
Les principales règles de gestion des opérations challenge :
- si la transaction est créée en mode VALIDATION, il est possible de combiner l'acceptation du challenge et la validation de la transaction en une seule étape ;
- une transaction dont le challenge est accepté poursuit son cycle de vie (remise, remboursement, etc.) ;
- une transaction dont le challenge est refusé arrive à la fin de son cycle de vie (état REFUSED) ;
- une transaction en état TO_CHALLENGE peut être annulée. Si aucune opération n'est effectuée sur la transaction dans le délai, la transaction expire ;
- la gestion du résultat orange est applicable uniquement pour les transactions CB, Visa, Mastercard et Amex.
Ci-dessous le cycle de vie d'une transaction avec la gestion du résultat orange :

En fonction du moment où le challenge est accepté, du captureDay, du captureMode et de la durée maximale de validité d’une autorisation, le jour de la remise en banque varie.
On distingue ici les cas d’utilisation en mode AUTHOR_CAPTURE et en mode VALIDATION.
Mode AUTHOR_CAPTURE
- Cas d'utilisation 1 :
- Le captureDay est inférieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté avant la fin du délai captureDay
- La remise en banque se fait comme prévu à la fin du délai captureDay
Exemple : captureDay à 3, durée de l’autorisation à 6. Le challenge est accepté à J+2 :
- Cas d'utilisation 2 :
- Le captureDay est inférieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté après la fin du délai captureDay
- La remise en banque se fait le soir de l’acceptation du challenge
Exemple : captureDay à 3, durée de l’autorisation à 6. Le challenge est accepté à J+4 :
- Cas d'utilisation 3 :
- Le captureDay est supérieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté après la fin de validité de la demande d'autorisation
- Une nouvelle demande d’autorisation a lieu et la remise en banque se fait en respectant le captureDay
Exemple : durée de l’autorisation à 6. Le challenge est accepté à J+7, captureDay à 10:
Mode VALIDATION
- Cas d'utilisation 1 :
- Le captureDay est inférieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté avant la fin du délai captureDay
- La validation est effectuée après acceptation du challenge et avant ou le même jour que le captureDay
- La remise en banque se fait le soir de la validation
Exemple : captureDay à 3, durée de l’autorisation à 6. Le challenge est accepté à J+2, la validation à J+3:
- Cas d'utilisation 2 :
- Le captureDay est supérieur à la limite de durée maximale de validité d’une autorisation
- Le challenge est accepté avant la fin du délai captureDay
- L’autorisation est jouée pendant l’opération de validation
- La remise en banque se fait le soir de l’acceptation du challenge avec une nouvelle demande d'autorisation
Exemple : captureDay à 7, durée de l’autorisation à 6. Le challenge est accepté à J+2, la validation à J+3:
Nous vous conseillons de faire la validation en même temps que l’acceptation du challenge en valorisant le champ validationIndicator dans la requête acceptChallenge à « Y ».
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 ci-dessous :
- scoreColor, le résultat des règles représenté par une couleur ;
- scoreValue, la valeur du score global ;
- scoreProfile, le profil antifraude exécuté ;
- preAuthorisationProfileValue, 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 ;
- scoreThreshold, les seuils paramétrés sur le profil ;
- scoreInfo, les informations détaillées des règles exécutées ;
- preAuthorisationRuleResultList, 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 :
- ruleCode, le code de la règle. Pour connaître les codes de règles, veuillez-vous référer à la liste des règles ;
- ruleType, le type de la règle. Pour connaître le type de chaque règle, veuillez vous référer à la liste des règles ;
- ruleWeight, le poids de la règle défini dans le profil :
- 0 : neutre,
- 1 : importance faible,
- 2 : importance moyenne,
- 3 : importance forte,
- 4 : décisive,
- ruleSetting, indique le type de configuration de la
règle :
- D : dynamique dans la transaction,
- S : statique dans la configuration commerçant,
- 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, le 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 (ex. donnée non renseignée),
- X : la règle n'est pas applicable à ce type de transaction,
- B : règle non exécutée car débrayée par le commerçant,
- 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 cette règle.
Pour connaître les informations détaillées de chaque règle, veuillez vous référer à la description et mise en oeuvre des règles.
Ces champs vous sont restitués sur les interfaces suivantes :
- les réponses automatique et manuelle de Sips Paypage ;
- la réponse des connecteurs WL Sips (services Checkout, CashManagement (duplication) et Diagnostic) ;
- le Merchant Extranet ;
- le journal des transactions à l'exception des champs scoreInfo et preAuthorisationRuleResultList.
Champ | Description |
---|---|
Résultat en vert / blanc | |
responseCode | Valorisé en fonction de la réponse d'autorisation |
acquirerResponseCode | Valorisé en fonction de la réponse d'autorisation |
scoreColor | WHITE/GREEN |
scoreValue | Valeur du score global |
scoreProfile | Nom du profil antifraude exécuté |
preAuthorisationProfileValue | Identifiant unique du profil exécuté |
scoreThreshold | Seuils paramétrés sur le profil |
scoreInfo | Valorisé en fonction des règles déroulées |
transactionStatus | Valorisé en fonction de la réponse d'autorisation et du mode de capture |
preAuthorisationRuleResultList | Liste du résultat détaillé de chaque règle exécutée |
Résultat en orange | |
responseCode | Valorisé en fonction de la réponse d'autorisation |
acquirerResponseCode | Valorisé en fonction de la réponse d'autorisation |
scoreColor | ORANGE |
scoreValue | Valeur du score global |
scoreProfile | Nom du profil antifraude exécuté |
preAuthorisationProfileValue | Identifiant unique du profil exécuté |
scoreThreshold | Seuils paramétrés sur le profil |
scoreInfo | Valorisé en fonction des règles déroulées |
transactionStatus | Valorisé en fonction de la réponse d'autorisation et de l'option challenge du commerçant |
preAuthorisationRuleResultList | Liste du résultat détaillé de chaque règle exécutée |
Résultat en rouge / noir | |
responseCode | Valorisé à 05 |
acquirerReponseCode | Non renseigné |
scoreColor | BLACK/RED |
scoreValue | Valeur du score global |
scoreProfile | Nom du profil antifraude exécuté |
preAuthorisationProfileValue | Identifiant unique du profil exécuté |
scoreThreshold | Seuils paramétrés sur le profil |
scoreInfo | Valorisé en fonction des règles déroulées |
TransactionStatus | REFUSED |
preAuthorisationRuleResultList | Liste du résultat détaillé de chaque règle exécutée |
Mode pré-authentification
Le résultat de l'exécution du profil de pré-authentification est restitué dans les champs ci-dessous :
- preAuthenticationColor, le résultat des règles représenté dans couleur ;
- preAuthenticationValue, la valeur du score global ;
- preAuthenticationThreshold, les seuils paramétrés sur le profil ;
- preAuthenticationInfo, les informations détaillées des règles exécutées ;
- preAuthenticationProfile, le nom du profil antifraude exécuté avant l'authentification ;
- preAuthorisationProfileValue, 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, 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 Sips Paypage ;
- la réponse des connecteurs Sips Office (services Checkout, CashManagement (duplication) et Diagnostic) ;
- le Merchant Extranet ;
- le journal des transactions à l'exception des champs preAuthenticationInfo et preAuthenticationRuleResultList.
Champ | Description |
---|---|
Résultat en vert / blanc | |
preAuthenticationColor | WHITE/GREEN |
preAuthenticationValue | Valeur du score global |
preAuthenticationThreshold | Seuils paramétrés sur le profil |
preAuthenticationInfo | Les informations détaillées des règles exécutées |
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 en orange / rouge / noir | |
preAuthenticationColor | BLACK/RED/ORANGE |
preAuthenticationValue | Valeur du score global |
preAuthenticationThreshold | Seuils paramétrés sur le profil |
preAuthenticationInfo | Informations détaillées des règles exécutées |
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 |
Limites d'utilisation
Moyens de paiement
L'offre globale WL Sips 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 antifraudes.
____________________
** 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…) et credit holder 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
Liste 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
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 Merchant Extranet,
- 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 Merchant Extranet,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CR;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte n’est pas connu | 0 | CR;N; CARD_COUNTRY=XXX* |
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 | 0 à -4 selon paramétrage | ||
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 | 0 |
* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CR;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte n’est pas connu | 0 | CR;N; CARD_COUNTRY=XXX* |
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 » ou est équivalent à votre pays | 0 à -4 selon paramétrage | ||
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 » | 0 | ||
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 » | 0 à +4 selon paramétrage |
* 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.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedCardCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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.
Exemples:
<urn:fraudData>
<urn:allowedCardCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
"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.
Exemples :
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 Sips 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 Sips Office.
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 Merchant Extranet.
- 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 Merchant Extranet,
- 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 Sips Office.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le pays de l'adresse IP n’est pas connu. | 0 | CY;N;IP_COUNTRY=XXX | 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. | 0 à -4 selon paramétrage | CY;N;IP_COUNTRY=XXX* | 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. | 0 |
* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | Scoreinfo | RuleDetailedInfo |
---|---|---|---|
Le pays de l'adresse IP n’est pas connu. | 0 | CY;N;IP_COUNTRY=XXX | 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 ». | 0 à -4 selon paramétrage | CY;N;IP_COUNTRY=XXX* | 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 ». | 0 | ||
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 ». | 0 à +4 selon paramétrage |
* 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.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedIpCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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.
Exemples :
<urn:fraudData>
<urn:allowedIpCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
"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.
Exemples :
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 Sips 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 Sips Office.
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 Merchant Extranet,
- 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 Merchant Extranet,
- 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 Sips Office.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | SI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). | 0 | SI;N; CARD_COUNTRY=XXX; IP_COUNTRY=YYY* |
CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY* |
La combinaison du pays de la carte et du pays de l'adresse IP est interdite. | 0 à -4 selon paramétrage | ||
La combinaison du pays de la carte et du pays de l'adresse IP est autorisée. | 0 |
* 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | SI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). | 0 | SI;N; CARD_COUNTRY=XXX; IP_COUNTRY=YYY* |
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 ». | 0 à -4 selon paramétrage | ||
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 ». | 0 | ||
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 ». | 0 à +4 selon paramétrage |
* 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.
Exemples :
<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>
"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.
Exemples :
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 Merchant Extranet
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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le pays de livraison ne correspond pas au pays de facturation | 0 à -4 selon paramétrage | SB;N; SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY* |
Le pays de livraison correspond au pays de facturation | 0 | ||
Non connaissance des pays | 0 |
* 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.
Exemples :
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 Merchant Extranet
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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le code postal de livraison ne correspond pas au code postal de facturation | 0 à -4 selon paramétrage | ZC;N; SHIP_COUNTRY=XXX; BILL_COUNTRY=YYY; SHIP_ZIP=A; BILL_ZIP=B* |
SHIP_COUNTRY=XXX*;
BILL_COUNTRY=YYY*; SHIP_ZIP=A*; BILL_ZIP=B* |
Le code postal de livraison correspond au code postal de facturation | 0 | ||
Non connaissance des codes postaux | 0 |
* 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.
Exemples :
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 Merchant Extranet,
- 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 Merchant Extranet,
- 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).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays de la carte est interdite. | 0 à -4 selon paramétrage | CS;N; SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
La combinaison du pays de livraison et du pays de la carte est autorisée. | 0 | ||
Non connaissance du pays de la carte ou du pays de livraison. | 0 |
* 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | 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 ». | 0 à -4 selon paramétrage | CS;N; SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
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 ». | 0 | ||
Non connaissance du pays de la carte ou du pays de livraison. | 0 | ||
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 ». | 0 à +4 selon paramétrage |
* 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.
Exemples :
<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>
"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.
Exemples :
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 Merchant Extranet,
- 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 Merchant Extranet,
- 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).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de facturation et du pays de la carte est interdite. | 0 à -4 selon paramétrage | CS;N; BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
La combinaison du pays de facturation et du pays de la carte est autorisée. | 0 | ||
Non connaissance du pays de la carte ou du pays de facturation. | 0 |
* 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | 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 » | 0 à -4 selon paramétrage | CS;N; BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
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 » | 0 | ||
Non connaissance du pays de la carte ou du pays de facturation. | 0 | ||
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 » | 0 à +4 selon paramétrage |
* 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.
Exemples :
<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>
"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.
Exemples :
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 Merchant Extranet,
- 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 Merchant Extranet,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | AC;N;NOT_APPLICABLE | 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 | 0 à -4 selon paramétrage | AC;N; IBAN_COUNTRY=XXX* |
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 | 0 |
* XXX : code pays alphabétique ISO 3166 (cf. Annexe 4 : codes pays alphabétiques ISO 3166)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | AC;N;NOT_APPLICABLE | 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 » | 0 à -4 selon paramétrage | AC;N; IBAN_COUNTRY=XXX* |
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 » | 0 | ||
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 » | 0 à +4 selon paramétrage |
* 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 :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedIbanCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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.
Exemples :
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 Merchant Extranet,
- 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 Merchant Extranet,
- 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).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | DI;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays de l'IBAN est interdite | 0 à -4 selon paramétrage | DI;N; SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
La combinaison du pays de livraison et du pays de l'IBAN est autorisée | 0 |
* 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | DI;N;NOT_APPLICABLE | 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 » | 0 à -4 selon paramétrage | DI;N; SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
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 » | 0 | ||
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 » | 0 à +4 selon paramétrage |
* 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.
Exemples :
<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>
"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.
Exemples :
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 Merchant Extranet,
- 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 Merchant Extranet,
- 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).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | PI;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est interdite | 0 à -4 selon paramétrage | PI;N; PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
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) | 0 | ||
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est autorisée | 0 |
* 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | PI;N;NOT_APPLICABLE | 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 » | 0 à -4 selon paramétrage | PI;N; PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
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) | 0 | ||
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 » | 0 | ||
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 » | 0 à +4 selon paramétrage |
* 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.
Exemples :
<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>
"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.
Exemples :
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 Sips 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 Sips Office. 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 Merchant Extranet,
- 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 Merchant Extranet,
- 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 Sips Office.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | IS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de l’adresse IP et du pays de l'IBAN est interdite | 0 à -4 selon paramétrage | IS;N; IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
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) | 0 | ||
La combinaison du pays de l’adresse IP et du pays de l'IBAN est autorisée | 0 |
* 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | IS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays 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 » | 0 à -4 selon paramétrage | IS;N; IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
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) | 0 | ||
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 » | 0 | ||
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 » | 0 à +4 selon paramétrage |
* 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.
Exemples :
<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>
"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.
Exemples :
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.
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 Merchant Extranet,
- 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 Merchant Extranet.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 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 : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de transactions | 1 transaction sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | SC;N;NOT_APPLICABLE | 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) | 0 à -4 selon paramétrage | SC;N;TRANS=A:B; CUMUL=C:D* |
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 | 0 |
*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.
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.
Exemples :
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
- paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 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 | ScoreValue | ScoreInfo | 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) | 0 à -4 selon paramétrage | VI;N;TRANS=A:B; CUMUL=C:D* |
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 | 0 | TRANS=A:B; CUMUL=C:D* |
|
L'adresse IP n'est pas renseignée (en Sips Office) | 0 |
*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.
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.
Exemples :
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 Merchant Extranet,
- paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Merchant Extranet
- 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 : 2376 heures En jours :
99 jours En semaines : 14 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
L’identifiant client n’est pas fourni | 0 | VC;N;TRANS=A:B; CUMUL=C:D* |
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) | 0 à -4 selon paramétrage | 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 | 0 |
*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.
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.
Exemples :
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 Merchant Extranet,
- paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du Merchant Extranet
- 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 : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de clients | 1 client sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | MD;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre de clients différents utilisant la même carte sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | MD;N;MAX=A:B* | 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 | 0 | ||
L'identifiant client n'est pas renseigné | 0 |
*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.
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.
Exemples :
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 Merchant Extranet,
- paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du Merchant Extranet,
- 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 : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de cartes | 1 carte sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | MR;N;NOT_APPLICABLE | 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 | 0 à -4 selon paramétrage | MR;N;MAX=A:B* | 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 | 0 | ||
L'identifiant client n'est pas renseigné | 0 |
*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.
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.
Exemples :
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
- paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de cartes | 1 carte sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | CI;N;NOT_APPLICABLE | 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 | 0 à -4 selon paramétrage | CI;N;MAX=A:B* | 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 | 0 | ||
L’adresse IP n’est pas renseignée (en Sips Office) | 0 |
*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.
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.
Exemples :
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
- paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal d'IBAN | 1 IBAN sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | II;N;NOT_APPLICABLE | 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 | 0 à -4 selon paramétrage | II;N;MAX=A:B* | MAX=A:B* |
L’adresse IP n’est pas renseignée (en Sips Office) | 0 | ||
Le nombre d’IBAN différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée | 0 |
*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.
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.
Exemples :
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
- paramétrer le nombre maximum d'adresses IP et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal d'adresses IP | 1 adresse IP sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | IJ;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre d’adresses IP différentes avec le même IBAN sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | IJ;N;MAX=A:B* | MAX=A:B* |
L’adresse IP n’est pas renseignée (en Sips Office) | 0 | ||
Le nombre d’adresses IP différentes avec le même IBAN sur la période est inférieur à la limite acceptée | 0 |
*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.
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.
Exemples :
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
- paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du Merchant Extranet
- 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 : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de clients | 1 client sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | CJ;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre de clients différents utilisant le même IBAN sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | CJ;N;MAX=A:B* | MAX=A:B* |
L’identifiant client n’est pas renseigné | 0 | ||
Le nombre de clients différents utilisant le même IBAN sur la période est inférieur à la limite acceptée | 0 |
*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.
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.
Exemples :
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 Merchant Extranet,
- paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du Merchant Extranet
- 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 : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal d'IBAN | 1 IBAN sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | IC;N;NOT_APPLICABLE | 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 | 0 à -4 selon paramétrage | IC;N;MAX=A:B* | MAX=A:B* |
L’identifiant client n’est pas renseigné | 0 | ||
Le nombre d’IBAN différents utilisés par le même client sur la période est inférieur à la limite acceptée | 0 |
*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.
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.
Exemples :
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
- paramétrer le nombre maximum de mandats et la durée du cumul également via l’onglet 'Fraude' du Merchant Extranet
- et transmettre l’adresse IP de l'acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de mandats | 1 mandat sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | MJ;N;NOT_APPLICABLE | 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 | 0 à -4 selon paramétrage | MJ;N;MAX=A:B* | MAX=A:B* |
L'adresse IP n’est pas renseignée | 0 | ||
Le nombre de mandats différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée | 0 |
*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.
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.
Exemples :
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 Merchant Extranet
- 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 Merchant Extranet
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | EM;N;NOT_APPLICABLE | 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) | 0 à -4 selon paramétrage | EM;N;TRANS=A:B; CUMUL=C:D* |
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 | 0 |
*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.
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.
Exemples :
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 Merchant Extranet
- 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 Merchant Extranet.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | EI;N;NOT_APPLICABLE | 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) | 0 à -4 selon paramétrage | EI;N;TRANS=A:B; CUMUL=C:D* |
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 | 0 |
*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.
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.
Exemples :
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
- paramétrer la liste des réputations d'adresse IP indésirables via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l'acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
L’information n’est pas connue | 0 | IR;N;U;IP_REP=XXX* | IP_REP=XXX* |
La réputation de l'adresse IP appartient à la liste des réputations d'adresse IP indésirables | 0 à -4 selon paramétrage | IR;N;Y;IP_REP=XXX* | |
La réputation de l'adresse IP n'appartient pas à la liste des réputations d'adresse IP indésirables | 0 | IR;N;N;IP_REP=XXX* |
* XXX : réputation d'adresse IP (voir Annexe 3 : réputations d’adresse IP)
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.
Exemples :
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 Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | OP;N;NOT_APPLICABLE | NOT_APPLICABLE |
L’accès au serveur oppotota a échoué | 0 | OP;N;U | -- |
La carte est en opposition | 0 à -4 selon paramétrage | OP;N;Y | |
La carte n'est pas en opposition | 0 | OP;N;N |
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.
Exemples :
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 Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | EC;N;NOT_APPLICABLE | NOT_APPLICABLE |
L'information n'est pas connue | 0 | EC;N;U | -- |
La carte est une carte virtuelle dynamique | 0 à -4 selon paramétrage | EC;N;Y | |
La carte n'est pas une carte virtuelle dynamique | 0 | EC;N;N |
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.
Exemples :
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 Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | SA;N;NOT_APPLICABLE | NOT_APPLICABLE |
L'information n'est pas connue | 0 | SA;N;U | -- |
La carte est une carte à autorisation systématique | 0 à -4 selon paramétrage | SA;N;Y | |
La carte n'est pas une carte à autorisation systématique | 0 | SA;N;N |
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.
Exemples :
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 Merchant Extranet,
- 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 Merchant Extranet,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CC;N;NOT_APPLICABLE | NOT_APPLICABLE |
L'information n'est pas connue | 0 | CC;N;U; CARD_COUNTRY=XXX |
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 | 0 à -4 selon paramétrage | CC;N;Y; CARD_COUNTRY=XXX* |
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 | 0 à -4 selon paramétrage | CC;N;Y; CARD_COUNTRY=XXX* |
|
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 | 0 | CC;N;N; CARD_COUNTRY=XXX* |
|
La carte n’est pas une carte commerciale | 0 | CC;N;N; CARD_COUNTRY=XXX* |
* XXX : code pays alphabétique 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 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.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedCommercialCardCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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.
Exemples :
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 Merchant Extranet,
- et paramétrer le montant minimum et/ou le montant maximum via l’onglet fraude du Merchant Extranet.
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 |
Restitution du résultat
Mode par défaut :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le montant de la transaction est hors de la plage des montants souhaités | 0 à -4 selon paramétrage | CA;N;MIN=A:B;MAX=A:C* | MIN=A:B;MAX=A:C* |
Le montant de la transaction est dans la plage des montants souhaités | 0 | CA;N;MIN=A:B;MAX=A:C* |
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le montant de la transaction est dans la plage des montants désavantagés | 0 à -4 selon paramétrage | CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=
A:C; POSITIVE_MIN= A:D; POSITIVE_MAX=A:E* |
NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D;POSITIVE_MAX=A:E |
Le montant de la transaction est hors des plages de montants avantagés et désavantagés | 0 | CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D; POSITIVE_MAX=A:E* |
|
Le montant de la transaction est dans la plage des montants avantagés | 0 à +4 selon paramétrage | CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D; POSITIVE_MAX=A:E* |
__________
* 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.
Exemples :
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 Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | NC;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le BIN de la carte n’est pas connu | 0 | NC;N;U | -- |
La carte ne fait pas partie du réseau carte bancaire | 0 à -4 selon paramétrage | NC;N;Y | |
La carte fait partie du réseau carte bancaire | 0 | NC;N;N |
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.
Exemples :
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 Merchant Extranet
- 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Au moins une adresse e-mail est présente dans la liste des adresses e-mail gratuites | 0 à -4 selon paramétrage | FE;N;Y | -- |
Aucune adresse e-mail n’est présente dans la liste des adresses e-mail gratuites | 0 | FE;N;U | |
Aucune adresse e-mail n’a été transmise | 0 | FE;N;N |
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.
Exemples :
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 Merchant Extranet
- et paramétrer la liste des statuts d’authentification 3-D Secure interdits via l’onglet fraude du Merchant Extranet.
Veuillez vous référer à l'Annexe 5 : statuts d'authentification 3-D Secure.
Restitution du résultat
Mode par défaut (configuration simple) :
Cas d'utilisation | ScoreValue | ScoreInfo | 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) | 0 | A3;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le statut 3-D Secure est interdit | 0 à -4 selon paramétrage | A3;N;Y | -- |
Le statut 3-D Secure n'est pas interdit | 0 | A3;N;N |
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | 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) | 0 | A3;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le statut 3-D Secure est dans la liste des statuts désavantagés | 0 à -4 selon paramétrage | A3;N;Y | -- |
Le statut 3-D Secure n'est pas dans les listes de statuts avantagés et désavantagés | 0 | A3;N;N | |
Le statut 3-D Secure est dans la liste des statuts avantagés | 0 à +4 selon paramétrage | A3;N;Y |
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.
Exemples :
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 Merchant Extranet
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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
La syntaxe de l’adresse e-mail est erronée | 0 à -4 selon paramétrage | ES;N | -- |
La syntaxe de l’adresse e-mail est correcte | 0 | ||
Aucune adresse e-mail n’a été transmise | 0 |
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.
Exemples :
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 Merchant Extranet,
paramétrer la liste des indicateurs autorisés/interdits via l’onglet fraude du Merchant Extranet
et transmettre l'adresse postale de livraison de l'acheteur dans la requête.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (InfoScore ID absent ou l’adresse de livraison n’est pas en Allemagne) | 0 | AV;N;NOT_APPLICABLE | NOT_APPLICABLE |
Information non connue | 0 | AV;N;U;IS_INDIC=XXX* | 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 | 0 à -4 selon paramétrage | AV;N;Y;IS_INDIC=XXX* | 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 | 0 | AV;N;N;IS_INDIC=XXX* |
* XXX : indicateur retourné par InfoScore.
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.
Exemples :
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 WL Sips.
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 Merchant Extranet
et paramétrer la liste des indicateurs autorisés/interdits via l’onglet fraude du Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (InfoScore ID absent) | 0 | BV;N;NOT_APPLICABLE | NOT_APPLICABLE |
Information non connue | 0 | BV;N;U;VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF* |
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 | 0 à -4 selon paramétrage | BV;N;Y;VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF* |
VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF* |
Le compte est un compte consommateur | 0 | BV;N;N;VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF* |
* 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.
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.
Exemples :
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 Merchant Extranet
et paramétrer le nombre minimum de mois avant expiration de la carte via l’onglet fraude du Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | PE;N;NOT_APPLICABLE | NOT_APPLICABLE |
La durée de validité du moyen de paiement est inférieure à la durée souhaitée | 0 à -4 selon paramétrage | PE;N;Y;EXPIRY=AAA:BBB* | EXPIRY=AAA:BBB* |
la durée de validité du moyen de paiement est supérieure à la durée souhaitée | 0 | PE;N;N;EXPIRY=AAA:BBB* |
* AAA : date d'expiration de la carte au format MMYY.
BBB : deadline pour le contrôle au format MMYY.
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.
Exemples :
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 négatif 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 négatif utilisée pour des cas douteux nécessitant une attention particulière ;
- une liste blanche est une liste du type positif 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 NÉGATIF) |
Résultat liste grise (type NÉGATIF) |
Résultat liste blanche (type POSITIF) |
---|---|---|---|
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 Merchant Extranet,
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 | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Au moins une adresse e-mail fait partie de la liste | Noire | 0 à -4 selon paramétrage | BM;N;Y | -- |
Grise | GM;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WM;P;Y | ||
Aucune adresse e-mail ne fait partie de la liste | Noire | 0 | BM;N;N | |
Grise | GM;N;N | |||
Blanche | WM;P;N | |||
Aucune adresse e-mail n’a été transmise | Noire | BM;N;U | ||
Grise | GM;N;N | |||
Blanche | WM;P;U |
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 Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
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 Merchant Extranet,
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 Sips Office.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
L’adresse IP n’est pas renseignée (en Sips Office) | Noire | 0 | BY;N;U | -- |
Grise | GY;N;U | |||
Blanche | WY;P;U | |||
L’adresse IP appartient à la liste | Noire | 0 à -4 selon paramétrage | BY;N;Y | |
Grise | GY;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WY;P;Y | ||
L’adresse IP n’appartient pas à la liste | Noire | 0 | BY;N;N | |
Grise | GY;N;N | |||
Blanche | WY;P;N |
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 Merchant Extranet,
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 | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Aucun code postal n'a été transmis | Noire | 0 | BZ;N;U | -- |
Grise | GZ;N;U | |||
Blanche | WZ;P;U | |||
Au moins un code postal fait partie de la liste | Noire | 0 à -4 selon paramétrage | BZ;N;Y | |
Grise | GZ;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WZ;P;Y | ||
Aucun code postal ne fait partie de la liste | Noire | 0 | BZ;N;N | |
Grise | GZ;N;N | |||
Blanche | WZ;P;N |
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 Merchant Extranet,
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 | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
L’identifiant client n’est pas fourni | Noire | 0 | BI;N;U | -- |
Grise | GI;N;U | |||
Blanche | WI;P;U | |||
Au moins un identifiant client fait partie de la liste | Noire | 0 à -4 selon paramétrage | BI;N;Y | |
Grise | GI;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WI;P;Y | ||
L’identifiant client ne fait pas partie de la liste | Noire | 0 | BI;N;N | |
Grise | GI;N;N | |||
Blanche | WI;P;N |
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 Merchant Extranet,
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 | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Aucun nom de client n'a été transmis | Noire | 0 | BN;N;U | -- |
Grise | GN;N;U | |||
Blanche | WN;P;U | |||
Au moins un nom de client fait partie de la liste | Noire | 0 à -4 selon paramétrage | BN;N;Y | |
Grise | GN;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WN;P;Y | ||
Aucun nom de client ne fait partie de la liste | Noire | 0 | BN;N;N | |
Grise | GN;N;N | |||
Blanche | WN;P;N |
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 Merchant Extranet
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 Sips Office Extranet. 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 Sips Office Batch.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | Noire | 0 | BC;N;U | -- |
Grise | GC;N;U | |||
Blanche | WC;P;U | |||
Le numéro de la carte fait partie de la liste | Noire | 0 à -4 selon paramétrage | BC;N;Y | |
Grise | GC;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WC;P;Y | ||
Le numéro de la carte ne fait pas partie de la liste | Noire | 0 | BC;N;N | |
Grise | GC;N;N | |||
Blanche | WC;P;N |
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 Merchant Extranet,
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 | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Aucun numéro de téléphone n’a été transmis | Noire | 0 | BP;N;U | -- |
Grise | GP;N;U | |||
Blanche | WP;P;U | |||
Au moins un numéro de téléphone fait partie de la liste | Noire | 0 à -4 selon paramétrage | BP;N;Y | |
Grise | GP;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WP;P;Y | ||
Aucun numéro de téléphone ne fait partie de la liste | Noire | 0 | BP;N;N | |
Grise | GP;N;N | |||
Blanche | WP;P;N |
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 Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche des numéros de BIN (cardNumber).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | Noire | 0 | BB;N;U | -- |
Grise | BR;N;U | |||
Blanche | WB;P;U | |||
Le numéro de BIN de la carte fait partie de la liste | Noire | 0 à -4 selon paramétrage | BB;N;Y | |
Grise | BR;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WB;P;Y | ||
Le numéro de BIN de la carte ne fait pas partie de de la liste | Noire | 0 | BB;N;N | |
Grise | BR;N;N | |||
Blanche | WB;P;N |
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é.
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 Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche de BIC.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Le BIC fait partie de la liste | Noire | 0 à -4 selon paramétrage | BE;N;Y | -- |
Grise | GM;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WE;P;Y | ||
Le BIC ne fait pas partie de la liste | Noire | 0 | BE;N;N | |
Grise | GM;N;N | |||
Blanche | WE;P;N |
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 Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche d'IBAN.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
L'IBAN fait partie de la liste | Noire | 0 à -4 selon paramétrage | BA;N;Y | -- |
Grise | GA;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WA;P;Y | ||
L'IBAN ne fait pas partie de la liste | Noire | 0 | BA;N;N | |
Grise | GA;N;N | |||
Blanche | WA;P;N |
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 Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche de mandats.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Le RUM du mandat fait partie de la liste | Noire | 0 à -4 selon paramétrage | TB;N;Y | -- |
Grise | TG;N;Y | |||
Blanche | 0 à +4 selon paramétrage | TW;P;Y | ||
Le RUM du mandat ne fait pas partie de la liste | Noire | 0 | TB;N;N | |
Grise | TG;N;N | |||
Blanche | TW;P;N |
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.
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.
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 Merchant Extranet,
paramétrer au moins une liste de produits à risque via l’onglet fraude du Merchant Extranet
- 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 | ScoreValue | ScoreInfo | Rule DetailedInfo |
---|---|---|---|
Au moins un produit du panier appartient à une liste de produits à risque | 0 à -3 selon paramétrage | RP;N;Y | -- |
L'information n'est pas connue | 0 | RP;N;U; | |
Aucun produit du panier n’appartient à une liste de produits à risque | 0 | RP;N;N |
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 Merchant Extranet,
paramétrer au moins une liste de produits à risque via l’onglet fraude du Merchant Extranet
- 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 | ScoreValue | ScoreInfo | 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. |
0 à -4 selon paramétrage | PQ;N;Y; MAX_QUANTITY_PER_ RISKY_PRODUCT=L:A:B; MAX_QUANTITY_PER_ LIST=L:C:D* |
MAX_QUANTITY _PER_RISKY
_PRODUCT=L:A:B; MAX_QUANTITY_PER_ LIST=L:C:D* |
L'information n'est pas connue | 0 | PQ;N;U | -- |
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 et la quantité totale
des produits appartenant à une liste de produits à risque est
inférieure ou égale au seuil paramétré dans la
règle. |
0 | PQ;N;N; MAX_QUANTITY_PER_ RISKY_PRODUCT=L:A:B;MAX_QUANTITY_PER_ LIST=L:C:D* |
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.
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 Merchant Extranet,
paramétrer au moins une liste de produits à risque via l’onglet fraude du Merchant Extranet
- 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 | ScoreValue | ScoreInfo | 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 |
0 à -4 selon paramétrage | PQ;N;Y; MAX_RATIO_PER_ RISKY_PRODUCT=L:A:B;MAX_RATIO_PER_ LIST=L:C:D* |
MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D* |
L'information n'est pas connue | 0 | PQ;N;U | -- |
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 |
0 | PQ;N;N; MAX_RATIO_PER_ RISKY_PRODUCT=L:A:B;MAX_RATIO_PER_ LIST=L:C:D* |
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.
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 Merchant Extranet
- 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 | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Au moins un produit du panier a une quantité supérieure au seuil paramétré dans la règle | 0 à -4 selon paramétrage | QP;N;Y; PRODUCTQUANTITY=A:B* |
PRODUCTQUANTITY =A:B* |
L'information n'est pas connue | 0 | QP;N;U; PRODUCTQUANTITY=XXX:B* |
PRODUCTQUANTITY =XXX:B* |
Aucun produit du panier n’a une quantité supérieure au seuil paramétré dans la règle | 0 | QP;N;N; PRODUCTQUANTITY=A:B* |
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 Merchant Extranet
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.
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.
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.

Les actions que vous pouvez effectuer dépendent du/des rôle(s) attribué(s) à votre profil Merchant Extranet.
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 :
![]() |
![]() |
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.
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.
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. |
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.
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

pour créer un nouveau profil. Les options de création sont les suivantes :
- Profil Business Score
Si cette option est autorisée par le distributeur, sélectionnez le choix Profil Business Score 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 où vous pouvez paramétrer les éléments suivants :
- 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.
- Seuils :
Vous pouvez configurer l’étendue des zones rouge, orange et verte à l’aide des deux curseurs de seuil. La valeur du seuil apparaît en dessous du curseur.
La couleur des curseurs rappelle la couleur de l’évaluation du risque si le score calculé atteint la valeur du seuil. Dans l’exemple ci-dessus, un score de -1 donnera la couleur verte et un score de -2, la couleur orange.Les bornes min et max du score sont recalculées dynamiquement en fonction des modifications apportées sur l’activation et le poids des règles. Par exemple, activer une règle avec un poids de -3 ajustera la valeur de la borne minimale de -3. Activer une règle avec un poids de +2 augmentera la valeur de la borne maximale de +2.
Si, suite à une modification des règles, un seuil a une valeur en dehors des bornes recalculées, sa valeur est ajustée automatiquement à la borne la plus proche et un message d’alerte est affiché : "Veuillez noter que les limites de seuil ont changé en raison de l’activité ou de la désactivation de certaines règles. Veuillez vérifier que les valeurs de seuil correspondent toujours à vos besoins"
Par exemple, si le seuil orange est positionné à -15 et que suite à une modification des règles, la borne minimale devient -10, le seuil orange sera ajusté automatiquement à -10.
Attention: vérifier les seuils après modification des règlesLorsqu’une règle est activée ou désactivée ou que son importance est modifiée, le maximum et le minimum du score évoluent en conséquence. Une fois les modifications sur les règles effectuées, il est donc nécessaire de réviser les seuils définissant les zones rouges, orange et vertes pour en ajuster les proportions au besoin.
- 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 contrats actifs sur la boutique et configurés dans le Merchant Extranet.
Note: profils par défautsi 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 :Ce moyen de paiement est déjà utilisé dans un autre profil. Choisir ce moyen de paiement l’enlèvera de l’autre profil.Note: 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.
Note: attentionToutes 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.

. À cet instant, le profil n'est pas encore activé. Vous devez ensuite le publier (voir le paragraphe Éditer et publier un profil).

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é

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
Activer et paramétrer une règle
Les règles sont regroupées par catégories. cliquez sur l'intitulé d'une catégorie pour la déployer et en consulter les règles.

indique que la règle est désactivée pour ce profil et n'a donc aucune influence sur les transactions. Cliquez sur cette icône pour activer la règle.

indique que la règle est active pour ce profil et sera donc utilisée pour l'évaluation des transactions lorsque le profil sera lui-même publié et actif. Cliquez sur cette icône pour désactiver la règle.

permet d'obtenir des détails sur la règle.
À côté de chaque règle, un menu déroulant permet d'en préciser l'importance.


pour en afficher le détail (consultez les chapitres suivants pour plus d'informations sur le paramétrage des règles).
Il est possible qu'une règle ne soit pas activable, désactivable ou configurable en conséquence des choix du distributeur ou de contraintes autres.
Ordonner les règles décisives

. Les règles décisives que vous avez activées apparaissent alors dans une fenêtre pop-up :


et

pour réordonner la liste.
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 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 score 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).

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à :

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) :

. 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 9 : 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.

: 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.

pour ajouter le ou les couples sélectionnés à la liste du contrôle.

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).

. 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 9 : 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 la carte et de l'adresse IP |
|
Pays de la carte |
|
Cette règle ne nécessite pas de configuration particulière. |
|
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 carte |
|
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... |
---|---|
|
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é. |
|
Authentification 3-D Secure |
|
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 Sips Office Batch ou
- ajouter des éléments dans la liste via Sips Office SOAP ou JSON ou
- utiliser l'onglet Alimenter les listes.
Pour alimenter les listes via le Merchant Extranet, 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 ;
- via le token de la 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 WL Sips 2.0), ou en utilisant des identifiants et dates de transactions (clé primaire WL Sips 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
. 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 9 : 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.
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
. Le fichier généré contient tous les produits de la liste et est téléchargé automatiquement par votre navigateur.
. 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 9 : 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é.
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
, 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 toutes les règles |
Annexe 2 : couleurs
Valeurs | Description |
---|---|
Empty | Aucun contrôle. |
BLACK | Couleur du score noire. |
GREEN | Couleur du score verte. |
ORANGE | Couleur du score orange. |
RED | Couleur du score rouge. |
WHITE | Couleur du score blanche. |
Annexe 3 : réputations d'adresse IP
Une adresse IP peut avoir une ou plusieurs de ces réputations si elle a déjà été récemment concernée par l’un des cas suivants :
Adresse IP utilisée pour : | Description |
---|---|
Botnets | Les botnets sont des virus qui infectent un grand nombre de
machines afin de :
|
Déni de service | Une attaque par déni de service est une attaque
informatique ayant pour but de rendre indisponible un service,
d'empêcher les utilisateurs légitimes d'un service de l'utiliser.
Il peut s'agir de :
|
Phishing | Le Phishing consiste, pour les fraudeurs, à récupérer des informations confidentielles (financières, d'identification sur le système de votre entreprise etc.) grâce à un spam qui met en oeuvre une copie miroir frauduleuse et piégée d'une page réelle. |
Proxy anonymes | Un Proxy anonyme permet de naviguer anonymement. En général, c'est un serveur/proxy qui masque les informations personnelles (adresse IP, système d'exploitation, navigateur...) aux sites visités. |
Scanners | Permet de savoir si plusieurs machines ont la même adresse IP car ils appartiennent au même réseau. |
Source de Spam | Il s'agit en général d'envois d’e-mail en grande quantité effectués à des fins publicitaires. |
Attaques web | Les vulnérabilités des applications web peuvent être
catégorisées de la manière suivante :
|
Sources infectées | Adresses IP émettant des requêtes HTTP avec un indice de réputation faible ou qui sont des sites malveillants connus. |
Exploits Windows | Adresses IP ayant exploité des trous de sécurité contre les ressources Windows en utilisant des navigateurs, des programmes, des fichiers téléchargés, des scripts ou des vulnérabilités du système d'exploitation. |
Annexe 4 : codes pays alphabétiques ISO 3166
ABW | Aruba | AFG | Afghanistan | AGO | Angola |
AIA | Anguilla | ALB | Albanie | AND | Andorre |
ANT | Antilles Néerlandaises | ARE | Emirats arabes unis | ARG | Argentine |
ARM | Arménie | ASM | Samoa américaines | ATA | Antarctique |
ATF | Terres australes françaises | ATG | Antigua et Barbuda | AUS | Australie |
AUT | Autriche | AZE | Azerbaïdjan | BDI | Burundi |
BEL | Belgique | BEN | Bénin | BFA | Burkina faso |
BGD | Bangladesh | BGR | Bulgarie | BHR | Bahreïn |
BHS | The Bahamas | BIH | Bosnie Herzégovine | BLR | Bélarus |
BLZ | Belize | BMU | Bermudes | BOL | Bolivie |
BRA | Brésil | BRB | Barbade | BRN | Brunéi Darussalam |
BTN | Bhoutan | BVT | Bouvet, île | BWA | Botswana |
CAF | Centrafricaine, République | CAN | Canada | CCK | Cocos (Keeling), îles |
CHE | Suisse | CHL | Chili | CHN | Chine |
CIV | Côte d'Ivoire | CMR | Cameroun | COG | Congo |
COK | Cook, îles | COL | Colombie | COM | Comores |
CPV | Cap-Vert | CRI | Costa rica | CUB | Cuba |
CXR | Christmas, îles | CYM | Caïmanes, îles | CYP | Chypre |
CZE | Tchèque, république | DEU | Allemagne | DJI | Djibouti |
DMA | Dominique | DNK | Danemark | DOM | Dominicaine, république |
DZA | Algérie | ECU | Equateur | EGY | Egypte |
ERI | Erythrée | ESH | Sahara occidental | ESP | Espagne |
EST | Estonie | ETH | Ethiopie | FIN | Finlande |
FJI | Fidji | FLK | Falkland, îles (Malouines) | FRA | France |
FRO | Féroé, îles | FSM | Micronésie, Etats fédérés de | ATM | Gabon |
GBR | Royaume-uni | GEO | Géorgie | GHA | Ghana |
GIB | Gibraltar | GIN | Guinée | GLP | Guadeloupe |
GMB | Gambie | GNB | Guinée-Bissau | GNQ | Guinée équatoriale |
GRC | Grèce | GRD | Grenade | GRL | Groenland |
GTM | Guatemala | GUF | Guyane française | GUM | Guam |
GUY | Guyana | HKG | Hong-kong | HMD | Heard, île et McDonald, îles |
HND | Honduras | HRV | Croatie (nom local: Hrvatska) | HTI | Haïti |
HUN | Hongrie | IDN | Indonésie | IND | Inde |
IOT | Océan indien, Territoire britannique de l' | IRL | Irlande | IRN | Iran, république islamique d' |
IRQ | Iraq | ISL | Islande | ISR | Israël |
ITA | Italie | JAM | Jamaïque | JOR | Jordanie |
JPN | Japon | KAZ | Kazakhstan | KEN | Kenya |
KGZ | Kirghizistan | KHM | Cambodge | KIR | Kiribati |
KNA | Saint Kitts and Nevis | KOR | Corée, République de | KWT | Koweït |
LAO | Lao, République démocratique populaire | LBN | Liban | LBR | Libéria |
LBY | Libyenne, Jamahiriya arabe | LCA | Saint Lucia | LIE | Liechtenstein |
LKA | Sri Lanka | LSO | Lesotho | LTU | Lituanie |
LUX | Luxembourg | LVA | Lettonie | MAC | Macao |
MAR | Maroc | MCO | Monaco | MDA | Moldova, République de |
MDG | Madagascar | MDV | Maldives | MEX | Mexique |
MHL | Marshall, îles | MKD | Macédoine, l'ex-république yougoslave de | MLI | Mali |
MLT | Malte | MMR | Myanmar | MNG | Mongolie |
MNP | Mariannes du nord, îles | MOZ | Mozambique | MRT | Mauritanie |
MSR | Montserrat | MTQ | Martinique | MUS | Maurice |
MWI | Malawi | MYS | Malaisie | MYT | Mayotte |
NAM | Namibie | NCL | Nouvelle-Calédonie | NER | Niger |
NFK | Norfolk, île | NGA | Nigéria | NIC | Nicaragua |
NIU | Niué | NLD | Pays-bas | NOR | Norvège |
NPL | Népal | NRU | Nauru | NZL | Nouvelle-Zélande |
OMN | Oman | PAK | Pakistan | PAN | Panama |
PCN | Pitcairn | PER | Pérou | PHL | Philippines |
PLW | Palaos | PNG | Papouasie-Nouvelle-Guinée | POL | Pologne |
PRI | Porto Rico | PRK | Corée, République populaire démocratique de | PRT | Portugal |
PRY | Paraguay | PYF | Polynésie française | QAT | Qatar |
REU | Réunion | ROM | Roumanie | RUS | Russie, Fédération de |
RWA | Rwanda | SAU | Arabie saoudite | SDN | Soudan |
SEN | Sénégal | SGP | Singapour | SGS | Géorgie du sud et les îles Sandwich du sud |
SHN | Sainte-Hélène | SJM | Svalbard et île Jan Mayen | SLB | Salomon, îles |
SLE | Sierra leone | SLV | El Salvador | SMR | Saint-Marin |
SOM | Somalie | SPM | Saint-Pierre-et-Miquelon | STP | Sao Tomé-et-Principe |
SUR | Suriname | SVK | Slovaquie | SVN | Slovénie |
SWE | Suède | SWZ | Eswatini (anciennement Swaziland) | SYC | Seychelles |
SYR | Syrienne, république arabe | TCA | Turks et Caïques, îles | TCD | Tchad |
TGO | Togo | THA | Thaïlande | TJK | Tajikistan |
TKL | Tokelau | TKM | Turkménistan | TLS | Timor-Leste |
TON | Tonga | TTO | Trinité-et-Tobago | TUN | Tunisie |
TUR | Turquie | TUV | Tuvalu | TWN | Taïwan, Province de Chine |
TZA | Tanzanie, République-unie de | UGA | Ouganda | UKR | Ukraine |
UMI | Iles mineures éloignées des Etats-Unis | URY | Uruguay | USA | Etats-Unis |
UZB | Ouzbékistan | VAT | Saint-Siège (Etat de la cité du Vatican) | VCT | Saint Vincent et les Grenadines |
VEN | Vénézuéla | VGB | Iles Vierges britanniques | VIR | Iles Vierges des Etats-Unis |
VNM | Viet Nam | VUT | Vanuatu | WLF | Wallis et Futuna |
WSM | Samoa | YEM | Yémen | YUG | Yougoslavie |
ZAF | Afrique du Sud | ZAR | Zaïre | ZMB | Zambia |
ZWE | Zimbabwe |
Annexe 5 : statuts d'authentification 3-D Secure
Valeur | Description |
---|---|
ATTEMPT | Vous et le porteur de la carte êtes inscrits au programme d'authentification mais l’acheteur n’a pas eu à s’authentifier (le serveur de contrôle d’accès de la banque qui a émis la carte n’implémente que la génération d’une preuve de tentative d’authentification). |
BYPASS | À partir de certains critères que vous avez définis, le contrôle du programme d'authentification n'a pas été réalisé. |
ERROR | Vous participez au programme d'authentification mais le serveur WL Sips a rencontré un problème technique durant le processus d’authentification (lors de la vérification de l’inscription de la carte au programme 3-D Secure ou de l’authentification du porteur). |
FAILURE | Vous et le porteur de la carte êtes inscrits au programme d'authentification mais l’acheteur n’a pas réussi à s’authentifier (mauvais mot de passe). |
NO_AUTHENT | Vous ne participez pas au programme d'authentification. |
NOT_ENROLLED | Vous participez au programme d'authentification mais la carte du porteur n’est pas enrôlée. |
NOT_PARTICIPATING | L’acheteur ne s’est pas authentifié pour une des raisons
suivantes :
|
SUCCESS | Vous et le porteur de la carte êtes inscrits au programme d'authentification et le porteur s’est authentifié correctement. |
Annexe 6 : InfoScore adresse vérification indicateur
Valeur | Description |
---|---|
PPB | La personne est connue à l'adresse indiquée. |
PHB | La personne ne peut être confirmée à l'adresse indiquée mais le foyer y est connu. |
PAB | L'adresse est correctement formatée et le bâtiment est connu d’AZ, mais le foyer ainsi que la personne sont inconnues d'AZ à l'adresse indiquée. |
PUZ | La personne est connue mais ne peut plus recevoir de courrier à l'adresse indiquée, la personne ayant déménagé à une nouvelle adresse connue d'AZ. |
PNZ | La personne est connue mais ne peut probablement plus recevoir de courrier à l'adresse indiquée. |
PPV | La personne est connue à l'adresse indiquée mais est décédée. |
PUG | Le format de l'adresse est correct, mais elle ne correspond ni une personne, ni à un foyer ou ni à un bâtiment. |
PPF | L'adresse postale est incorrecte et ne peut être vérifiée plus avant. |
PXX | Erreur technique. |
Annexe 7 : liste des codes pays prédéfinis
Clé | Commentaire Valeurs |
---|---|
#EEA | Les états membres de l’espace économique européen (Espace économique européen) |
AUT, BEL, BGR, CYP, CZE, DEU, DNK, ESP, EST, FIN, FRA, GBR, GRC, HRV, HUN, IRL, ISL, ITA, LIE, LTU, LUX, LVA, MLT, NLD, NOR, POL, PRT, ROM, SVK, SVN, SWE | |
#EFTA | Les états membres de la zone de libre échange (Association européenne de libre-échange) |
ISL, LIE, NOR, CHE | |
#FRJEL | Liste des pays autorisés pour les jeux en ligne français |
AUT, BEL, BGR, CYP, CZE, DEU, DNK, ESP, EST, FIN, FRA, GBR, GRC, HRV, HUN, IRL, ISL, ITA, LTU, LUX, LVA, MLT, NLD, NOR, POL, PRT, ROM, SVK, SVN, SWE | |
#UE | Les 28 états membres de l’Union Européenne |
DEU, AUT, BEL, BGR, CYP, CZE, DNK, ESP, EST, FIN, FRA, GBR, GRC, HRV, HUN, IRL, ITA, LTU, LUX, LVA, MLT, NLD, POL, PRT, ROM, SVK, SVN, SWE | |
#ZEURO | Les états membres de la zone Euro (EMU : Union économique et monétaire) |
AUT, BEL, CYP, DEU, ESP, EST, FIN, FRA, GRC, IRL, ITA, LVA, LTU, LUX, MLT, NLD, PRT, SVK, SVN |
Annexe 8 : correspondances entre moyens de paiement et règles antifraudes
Paylib et Masterpass sont des portefeuilles numériques. De ce fait vous devez vous référer aux types de moyens de paiement contenus dans le portefeuille pour savoir si ceux-ci sont éligibles aux contrôles de lutte contre la fraude de WL Sips.
Mode pré-autorisation
Légende des tableaux :
1 astérisque (*) signifie que l'application de la règle dépend des informations carte fourni par votre acquéreur.
2 astérisques (**) signifient que l'application de la règle dépend de l'information que vous soumettez dans la requête de paiement.
Pour les règles combinatoires comme Pays de la carte et de l’adresse IP, Pays de livraison et de la carte et Pays de facturation et de la carte, l'application dépend à la fois du référentiel carte et de l'information que vous soumettez dans la requête de paiement.
Règles de géolocalisation |
---|
![]() |
Règles d'encours |
---|
![]() |
Règles diverses |
---|
![]() |
Règles de listes |
---|
![]() |
Règles de panier |
---|
![]() |
Mode pré-authentification
Le mode pré-authentification est applicable uniquement pour les transactions carte (sauf portes feuilles numériques Paylib et MasterPass).
Légende des tableaux :
1 astérisque (*) signifie que l'application de la règle dépend des informations carte fourni par votre acquéreur.
2 astérisques (**) signifient que l'application de la règle dépend de l'information que vous soumettez dans la requête de paiement.
Pour les règles combinatoires comme Pays de la carte et de l’adresse IP, Pays de livraison et de la carte et Pays de facturation et de la carte, l'application dépend à la fois du référentiel carte et de l'information que vous soumettez dans la requête de paiement.
Règles de géolocalisation |
---|
![]() |
Règles d'encours |
---|
![]() |
Règles diverses |
---|
![]() |
Règles de liste |
---|
![]() |
![]() |
Règles de panier |
---|
![]() |
Annexe 9 : format de fichier d'export de liste
Fichier CSV de listes configurées dans les profils
Les fichiers générés par l’export de listes configurées dans les profils sont au format CSV dont le séparateur est le point-virgule « ; ».
Par défaut le fichier porte un nom dont le format est le suivant : <type de liste>_list.csv (ex : country_list.csv).
La première ligne du fichier correspond à l’en-tête des colonnes.
Chaque autre ligne du fichier correspond à un élément contenu dans la liste.
Quel que soit le type de liste, le contenu du fichier est le même.
Liste de pays simple
Les fichiers contenant une liste de pays (obtenu avec une règle comme « pays de la carte », « pays de l’adresse IP », etc.) sont constitués de 1 colonne :
- COUNTRY : le code pays ISO-3166.
Exemple :
Soit la liste dans la configuration de la règle « pays de la carte » d'un profil :
Pays |
---|
FRA |
DEU |
BEL |
Le fichier sera alors le suivant :
country_list.csv
COUNTRY;
FRA;
DEU;
BEL;
Liste de couples de pays
Les fichiers contenant une liste de couples de pays (obtenu avec une règle comme « pays de la carte et de l’adresse IP », « carte commerciale », etc.) sont constitués de 2 colonnes :
- COUNTRY1 : le code pays ISO-3166
- COUNTRY2 : le code pays ISO-3166
Exemple :
Soit la liste dans la configuration de la règle « pays de la carte et de l'adresse IP » dans un profil :
Pays 1 | Pays 2 |
---|---|
FRA | FRA |
DEU | FRA |
BEL | FRA |
Le fichier sera alors le suivant :
country_list.csv
COUNTRY1;COUNTRY2;
FRA;FRA;
DEU;FRA;
BEL;FRA;
Liste de domaines d'adresses e-mail
Les fichiers contenant une liste de domaines d'adresses e-mail (obtenu avec la règle « adresse e-mail ») sont constitués de 1 colonne :
- DOMAIN : le domaine web d'une adresse e-mail gratuite.
Exemple :
Soit la liste dans la configuration de la règle « adresse e-mail gratuite » d'un profil :
Domaine |
---|
domaine1.com |
domaine2.com |
domaine3.com |
Le fichier sera alors le suivant :
domain_list.csv
DOMAIN;
domaine1.com;
domaine2.com;
domaine3.com;
Fichier CSV de listes noires, grises et blanches
Les fichiers générés par l’export de liste grise, blanche ou noire sont au format CSV dont le séparateur est le point-virgule « ; ».
Par défaut le fichier porte un nom dont le format est le suivant :
<identifiant de boutique>_<couleur de la liste>_<type de liste>.csv (ex : 200007755500002_GREY_PAN.csv).
La première ligne du fichier correspond à l’en-tête des colonnes.
Chaque autre ligne du fichier correspond à un élément contenu dans la liste.
Quel que soit le type de liste, le contenu du fichier est le même, exception faite des listes de numéros de cartes dont le format est plus spécifique.
Liste de numéros de carte
Les fichiers contenant des listes de numéros de cartes sont constitués de 5 colonnes :
- TRANSACTION_REF où TRANSACTION_ID : la référence ou l’identifiant de la transaction, selon le mode de la boutique ;
- TRANSACTION_DATE : la date de la transaction au format AAAA-MM-JJ ;
- MASKED_PAN : le numéro de carte masqué ;
- REASON : le code raison de l’ajout de la carte dans la liste ;
- SHOP_ID : l’identifiant de la boutique à l’origine de l’ajout de l’élément dans la liste.
Exemple :
Soit la liste noire de numéros de carte de la boutique 201000770050003 suivante :
Réf/ID de transaction | Date | Numéro de carte | Raison | Boutique |
---|---|---|---|---|
915 | 2016-12-21 | 6703##########15 | fraud | 201000770050003 |
1546 | 2016-12-21 | 6703##########46 | fraud | 201000770050003 |
2530 | 2016-12-21 | 6703##########30 | fraud | 201000770050003 |
2735 | 2016-12-21 | 6703##########35 | fraud | 201000770050003 |
Le fichier sera alors le suivant :
201000770050003_BLACK_PAN.csv
TRANSACTION_REF;TRANSACTION_DATE;MASKED_PAN;REASON;SHOP_ID;
915;2016-12-21;6703##########15;fraud;201000770050003;
1546;2016-12-21;6703##########46;fraud;201000770050003;
2530;2016-12-21;6703##########30;fraud;201000770050003;
2735;2016-12-21;6703##########35;fraud;201000770050003;
Autres listes
Hormis les fichiers contenant des listes de numéros de cartes, tous les fichiers contenant des listes sont constitués de 3 colonnes :
- ITEM : correspond à la valeur de l’élément en liste (e-mail, identifiant client, adresse IP, etc.) ;
- REASON : le code raison de l’ajout de l’élément dans la liste ;
- SHOP_ID : l’identifiant de la boutique à l’origine de l’ajout de l’élément dans la liste.
Exemple :
Soit la liste noire d’identifiants de client de la boutique 201000770050003 suivante :
Élément | Raison | Boutique |
---|---|---|
123456 | fraudSuspicion | 201000770050003 |
987654 | negativeExperience | 201000770050003 |
456789 | notSpecified | 201000770050003 |
654321 | fraud | 201000770050003 |
Alors le fichier sera le suivant :
201000770050003_BLACK_CUSTOMER.csv
ITEM;REASON;SHOP_ID;
123456;fraudSuspicion;201000770050003;
987654;negativeExperience;201000770050003;
456789;notSpecified;201000770050003;
654321;fraud;201000770050003;
Fichier CSV de listes de produits à risque
Les fichiers générés par l’export de liste de produits à risque sont au format CSV dont le séparateur est le point-virgule « ; ».
Par défaut le fichier porte un nom dont le format est le suivant : <identifiant de boutique>_<nom de la liste>.csv (ex : 200007755500002_Ma_liste_de_produits.csv).
Chaque ligne du fichier correspond à un élément contenu dans la liste et comporte 3 colonnes :
- code produit ;
- libellé ;
- date de validité.
Exemple :
Si un fichier contient la liste suivante :
Code du produit | Libellé | Date de validité |
---|---|---|
A858F | Produit 1 | 29/10/2016 |
F85F4 | Produit 2 | 31/10/2016 |
Le fichier CSV correspondant sera :
A858F;Produit 1;29/10/2016
F85F4;Produit 2;31/10/2016