WL SIPS DOCS

Release 24.1

aller directement au contenu

Rechercher par mots clés

Règles

Pour rechercher dans la page utiliser Ctrl+F sur votre clavier

Cette page liste les règles de lutte contre la fraude disponible avec notre solution Go-No-Go.

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.

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

La règle du pays émetteur de la carte vous permet de décider de refuser ou non une transaction en fonction du pays émetteur de la carte (pays de l'établissement bancaire qui a émis la carte).

La règle va interroger une base de données des plages porteuses afin de vérifier l’appartenance du pays à 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é.

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 émetteurs 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.
Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO). Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO). Un même pays ne peut se trouver que dans l’une des deux listes.
IMPORTANT: information sur les cartes American Express

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

Mode de configuration simple :

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

* XXX : code pays alphabétique ISO 3166 (cf. donnée countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX : code pays alphabétique ISO 3166 (cf. donnée countryList dans le dictionnaire des données)

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=allowedCardCountryList,riskManagementDynamicValue=FRA,BEL,GBR}            
<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:

fraudData.allowedCardCountryList=FRA,BEL,GBR            
<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. donnée countryList dans le dictionnaire des données) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. donnée areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=ForeignBinCard
<urn:fraudData>
     <urn:bypassCtrlList>ForeignBinCard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["ForeignBinCard"]
}

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

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.

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

Mode de configuration simple :

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

* XXX : code pays alphabétique ISO 3166 (cf. donnée countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX : code pays alphabétique ISO 3166 (cf. donnée countryList dans le dictionnaire des données)

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}            
<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 :

fraudData.allowedIpCountryList=FRA,BEL,GBR           
<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. champ countryList dans le dictionnaire des données) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=IpCountry
<urn:fraudData>
     <urn:bypassCtrlList>IpCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["IpCountry"]
}    

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays émetteur 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 émetteur de la carte et le pays de l'adresse IP.

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 émetteur 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.

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

Mode de configuration simple :

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

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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 émetteur de la carte et de l’adresse IP,
    • DeniedIpCardCountryCombiList pour les combinaisons interdites de pays émetteur 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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIpCardCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }           
<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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=SimilityIpCard            
<urn:fraudData>
     <urn:bypassCtrlList>SimilityIpCard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilityIpCard"]
}

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.

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

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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

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 :

fraudData.bypassCtrlList=SimilarityDeliveryBillingCountry          
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingCountry"]
}

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.

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

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

A, B : code postal

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

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 :

fraudData.bypassCtrlList=SimilarityDeliveryBillingPostalCode       
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingPostalCode</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingPostalCode"]
}

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays émetteur 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 émetteur 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 émetteur de la carte et le pays de livraison.

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 émetteur de la carte et de livraison 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).

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

Mode de configuration simple :

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

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedDeliveryCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}         
<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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=SimilarityDeliveryCardCountry           
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryCardCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryCardCountry"]
}

Cette règle vous permet de décider de refuser ou non une prestation en se basant sur la combinaison du pays émetteur 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 émetteur de la carte. Ensuite, cette règle vérifiera la présence de la combinaison du pays émetteur 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 émetteur de la carte et le pays de facturation.

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 émetteur de la carte et de facturation 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 émetteurs de la carte de facturation dans la requête (champs billingAddress.country et cardNumber).

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

Mode de configuration simple :

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

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedBillingCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}          
<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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=SimilarityBillingCardCountry           
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityBillingCardCountry"]
}

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

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

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

____________________

* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIbanCountryList,riskManagementDynamicValue=FRA,BEL,GBR}         
<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. champ countryList dans le dictionnaire des données), séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=IbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>IbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["IbanCountry"]
}

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.

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

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison 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 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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedDeliveryIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
<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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=SimilarityDeliveryIbanCountry         
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryIbanCountry"]
}

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.

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

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedPhoneIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }            
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedPhoneIbanCountryCombiList</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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=SimilarityPhoneIbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityPhoneIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityPhoneIbanCountry"]
}

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.

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.

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
<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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=SimilarityIpIbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityIpIbanCountry"]
}

La règle du pays d'émission de la carte vous permet de décider de refuser ou non une transaction en fonction du pays d’émission de la carte (pays dans lequel la carte a été émise).

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

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

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 d'émission de la carte autorisés ou interdits. Pour cela, vous devez :
    • paramétrer la liste des pays d'émission autorisés ou interdits via l’onglet fraude du Merchant Extranet,
    • ou surcharger dynamiquement la liste des pays d'émission autorisés ou interdits dans votre requête.
Attention: en mode de configuration avancée, vous pouvez paramétrer deux listes. L’une ayant une influence positive (GO) et une négative (NOGO). Contrairement au mode de configuration simple, où il n’y a qu’une seule liste négative (NOGO). Un même pays d'émission ne peut se trouver que dans l’une des deux listes.
IMPORTANT: information sur les cartes American Express

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

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

Exemples :

fraudData.bypassCtrlList=CardIssuingCountry
<urn:fraudData>
     <urn:bypassCtrlList>CardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["CardIssuingCountry"]
}

Mode de configuration simple :

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

* XXX : code pays alphabétique ISO 3166 (cf. donnée countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX : code pays alphabétique ISO 3166 (cf. donnée countryList dans le dictionnaire des données)

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) :
    • AllowedCardIssuingCountryList pour la liste des pays autorisés,
    • DeniedCardIssuingCountryList pour la liste des pays interdits,
  • mode de configuration avancée :
    • NDeniedCardIssuingCountryList pour la liste des pays désavantagés,
    • NDeniedExceptCardIssuingCountryList pour la liste des pays non désavantagés,
    • PAllowedCardIssuingCountryList pour la liste des pays avantagés,
    • PAllowedExceptCardIssuingCountryList pour la liste des pays non avantagés.

Exemples :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedCardIssuingCountryList,riskManagementDynamicValue=FRA,BEL,GBR}            
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCardIssuingCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedCardIssuingCountryList",
                    "riskManagementDynamicValue":"FRA,BEL,GBR"
          }
     ]
}

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

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

  • fraudData.AllowedCardIssuingCountryList pour la liste des pays autorisés ;
  • fraudData.DeniedCardIssuingCountryList pour la liste des pays interdits.

Exemples:

fraudData.AllowedCardIssuingCountryList=FRA,BEL,GBR            
<urn:fraudData>
     <urn:AllowedCardIssuingCountryList>FRA,BEL,GBR</urn:AllowedCardIssuingCountryList>
</urn:fraudData>
"fraudData": {
   "AllowedCardIssuingCountryList": ["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. donnée countryList dans le dictionnaire des données) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. donnée areaList dans le dictionnaire des données).

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.

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 d'émission 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 d'émission de la carte dans la requête (champs billingAddress.country et cardNumber).

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

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

Exemples :

fraudData.bypassCtrlList=SimilarityBillingCardIssuingCountry           
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityBillingCardIssuingCountry"]
}

Cette règle vous permet de décider de refuser ou non une prestation en se basant sur la combinaison du pays d'émission 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 d'émission 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 d'émission de la carte et le pays de facturation.

Mode de configuration simple :

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

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de facturation et d'émission 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) :
    • AllowedBillingCardIssuingCountryCombiList pour les combinaisons autorisées de pays de facturation et de la carte,
    • DeniedBillingCardIssuingCountryCombiList pour les combinaisons interdites de pays de facturation et de la carte,
  • mode de configuration avancée :
    • NDeniedBillingCardIssuingCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptBillingCardIssuingCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedBillingCardIssuingCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptBillingCardIssuingCountryCombiList pour la liste des pays non avantagés.

Exemples :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedBillingCardIssuingCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}          
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedBillingCardIssuingCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedBillingCardIssuingCountryCombiList",
                    "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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 d'émission 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).

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

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

Exemples :

fraudData.bypassCtrlList=SimilarityShippingCardIssuingCountry           
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityShippingCardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityShippingCardIssuingCountry"]
}

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays d'émission 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 d'émission de la carte. Ensuite, cette règle vérifiera la présence de la combinaison du pays d'émission 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 d'émission de la carte et le pays de livraison.

Mode de configuration simple :

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

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et d'émission 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) :
    • AllowedDeliveryCardIssuingCountryCombiList pour les combinaisons autorisées de pays de livraison et de la carte,
    • DeniedDeliveryCardIssuingCountryCombiList pour les combinaisons interdites de pays de livraison et de la carte,
  • mode de configuration avancée :
    • NDeniedDeliveryCardIssuingCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptDeliveryCardIssuingCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedDeliveryCardIssuingCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptDeliveryCardIssuingCountryCombiList pour la liste des pays non avantagés.

Exemples :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedDeliveryCardIssuingCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}         
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryCardIssuingCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedDeliveryCardIssuingCountryCombiList",
                    "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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 d'émission 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.

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

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

Exemples :

fraudData.bypassCtrlList=SimilarityIpCardIssuingCountry            
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpCardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityIpCardIssuingCountry"]
}

Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays d'émission 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.

Mode de configuration simple :

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

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

Mode de configuration avancée :

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

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

____________________

* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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) :
    • AllowedIpCardIssuingCountryCombiList pour les combinaisons autorisées de pays de la carte et de l’adresse IP,
    • DeniedIpCardIssuingCountryCombiList pour les combinaisons interdites de pays de la carte et de l’adresse IP,
  • mode de configuration avancée :
    • NDeniedIpCardIssuingCountryCombiList pour la liste des pays désavantagés,
    • NDeniedExceptIpCardIssuingCountryCombiList pour la liste des pays non désavantagés,
    • PAllowedIpCardIssuingCountryCombiList pour la liste des pays avantagés,
    • PAllowedExceptIpCardIssuingCountryCombiList pour la liste des pays non avantagés.

Exemples :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIpCardIssuingCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }           
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam> AllowedIpCardIssuingCountryCombiList </urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedIpCardIssuingCountryCombiList",
                    "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. champ countryList dans le dictionnaire des données) ;
  • soit d'une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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

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

Il existe deux manières de calculer les encours :

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

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

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

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

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

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 €

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

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=VelocityCard
<urn:fraudData>
     <urn:bypassCtrlList>VelocityCard</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["VelocityCard"]
}

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.

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 €

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

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=VelocityIp
<urn:fraudData>
     <urn:bypassCtrlList>VelocityIp</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["VelocityIp"]
}

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.

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 

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

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=VelocityCustomerId
<urn:fraudData>
     <urn:bypassCtrlList>VelocityCustomerId</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["VelocityCustomerId"]
}

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.

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=MaxCustomerIdPerCard
<urn:fraudData>
     <urn:bypassCtrlList>MaxCustomerIdPerCard</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["MaxCustomerIdPerCard"]
}

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.

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=MaxCardPerCustomerId
<urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerCustomerId</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["MaxCardPerCustomerId"]
}

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.

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=MaxCardPerIp
<urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerIp</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["MaxCardPerIp"]
}

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.

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=MaxIbanPerIp
<urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerIp</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["MaxIbanPerIp"]
}

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.

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=MaxIpPerIban
<urn:fraudData>
     <urn:bypassCtrlList>MaxIpPerIban</urn:bypassCtrlList>
</urn:fraudData>
fraudData": {
   "bypassCtrlList":["MaxIpPerIban"]
}

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.

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

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

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

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

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

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

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

Exemples :

fraudData.bypassCtrlList=MaxCustidPerIban
<urn:fraudData>
     <urn:bypassCtrlList>MaxCustidPerIban</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["MaxCustidPerIban"]
}

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.

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=MaxIbanPerCustid
<urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerCustid</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["MaxIbanPerCustid"]
}

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.

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=MaxMandatePerIp
<urn:fraudData>
     <urn:bypassCtrlList>MaxMandatePerIp</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["MaxMandatePerIp"]
}

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.

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 €

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

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=VelocityMandate
<urn:fraudData>
     <urn:bypassCtrlList>VelocityMandate</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["VelocityMandate"]
}

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.

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 €

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

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

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

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

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

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

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

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 :

fraudData.bypassCtrlList=VelocityIban
<urn:fraudData>
     <urn:bypassCtrlList>VelocityIban</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["VelocityIban"]
}

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.

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.

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 réputations d'adresse IP.

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

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

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

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

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 :

fraudData.bypassCtrlList=IpReputations
<urn:fraudData>
     <urn:bypassCtrlList>IpReputations</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["IpReputations"]
}

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.

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

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

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

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

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 :

fraudData.bypassCtrlList=HotList
<urn:fraudData>
     <urn:bypassCtrlList>HotList</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["HotList"]
}

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.

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

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

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

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

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 :

fraudData.bypassCtrlList=ECard
<urn:fraudData>
     <urn:bypassCtrlList>ECard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["ECard"]
}

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

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

La règle vérifie si la carte est une carte prépayée.

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

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

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

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

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

Exemples :

fraudData.bypassCtrlList=PrepaidCardForbidden
<urn:fraudData>
     <urn:bypassCtrlList>PrepaidCardForbidden</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["PrepaidCardForbidden"]
}

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.

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

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

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

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

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 :

fraudData.bypassCtrlList=SystematicAuthorizationCard
<urn:fraudData>
     <urn:bypassCtrlList>SystematicAuthorizationCard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SystematicAuthorizationCard"]
}

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 émetteur 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.

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

* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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

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 :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedCommercialCardCountryList,riskManagementDynamicValue=(FRA,BEL)}
<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.champ countryList dans le dictionnaire des données) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

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 :

fraudData.bypassCtrlList=CorporateCard
<urn:fraudData>
     <urn:bypassCtrlList>CorporateCard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["CorporateCard"]
}

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.

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
Attention: en mode de configuration avancée, il est possible de paramétrer deux plages de montants. L’une ayant une influence positive (GO) et l’autre une négative (NOGO), contrairement au mode de configuration simple, qui ne comporte qu’une seule plage négative (NOGO) de montants.

Mode par défaut :

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

Mode de configuration avancée :

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

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

__________

* A : montant de la transaction.

B : montant minimum accepté.

C : montant maximum accepté.

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

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 :

fraudData.bypassCtrlList=CapCollarAmount
<urn:fraudData>
     <urn:bypassCtrlList>CapCollarAmount</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["CapCollarAmount"]
}

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.

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

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

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

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

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 :

fraudData.bypassCtrlList=CBScheme
<urn:fraudData>
     <urn:bypassCtrlList>CBScheme</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["CBScheme"]
}

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

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

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

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

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 :

fraudData.bypassCtrlList=FreeEmail
<urn:fraudData>
     <urn:bypassCtrlList>FreeEmail</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["FreeEmail"]
}

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.

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 au champ holderAuthentStatus dans le dictionnaire des données.

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

Mode par défaut (configuration simple) :

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

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

Mode de configuration avancée :

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

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

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 :

fraudData.bypassCtrlList=3DSStatus
<urn:fraudData>
     <urn:bypassCtrlList>3DSStatus</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["3DSStatus"]
}

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.

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

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

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

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

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 :

fraudData.bypassCtrlList=EmailSyntax
<urn:fraudData>
     <urn:bypassCtrlList>EmailSyntax</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["EmailSyntax"]
}

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.

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.

Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) -- Neutre NOT_APPLICABLE
La durée de validité du moyen de paiement est inférieure à la durée souhaitée 23 Négatif EXPIRY=AAA:BBB*
la durée de validité du moyen de paiement est supérieure à la durée souhaitée -- Neutre

* AAA : date d'expiration de la carte au format MMYY.

BBB : deadline pour le contrôle au format MMYY.

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

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

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 :

fraudData.bypassCtrlList=ExpiryDate
<urn:fraudData>
     <urn:bypassCtrlList>ExpiryDate</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["ExpiryDate"]
}

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.

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

Exemples :

fraudData.bypassCtrlList=CommercialCardIssuingCountry
<urn:fraudData>
     <urn:bypassCtrlList>CommercialCardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["CommercialCardIssuingCountry"]
}

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 d'émission 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.

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

* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)

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

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 :

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

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

Exemples :

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedCommercialCardIssuingCountryList,riskManagementDynamicValue=(FRA,BEL)}
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCommercialCardIssuingCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedCommercialCardIssuingCountryList",
                    "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.champ countryList dans le dictionnaire des données) séparés par des virgules ;
  • soit une liste de codes pays prédéfinis (cf. champ areaList dans le dictionnaire des données).

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.

Le moteur de gestion de la lutte contre la fraude permet de gérer plusieurs listes de données. Trois types différents de règles peuvent être appliqués à ces listes :

  • vérification dans une liste noire ;
  • vérification dans une liste grise ;
  • vérification dans une liste blanche.

La différence entre ces règles dépend du résultat de la règle ainsi que de la manière dont vous gérez la liste :

  • une liste noire est une liste du type NOGO utilisée pour des actions sévères, elle entraîne généralement un rejet des transactions ;
  • une liste grise est une liste du type NOGO utilisée pour des cas douteux nécessitant une attention particulière ;
  • une liste blanche est une liste du type GO utilisée pour porter une attention spéciale et positive à certains clients.

Voici les résultats possibles en fonction du type de règle :

Valeur de donnée présente Résultat liste noire
(type NOGO)
Résultat liste grise
(type NOGO)
Résultat liste blanche
(type GO)
NON Neutre Neutre Neutre
OUI Négatif Négatif Positif

D'une manière générale, les achats sur Internet présentent pour vous un risque de fraude plus élevé que lorsque la carte est présentée. Les commandes par téléphone/courrier/Internet sont des vecteurs majeurs de fraude si vous vendez et expédiez des produits. Si la carte n'est pas physiquement présente, vous devez compter sur le porteur de carte (ou quelqu'un qui affirme l'être) pour donner les informations de manière indirecte, que ce soit par courrier, téléphone ou Internet.

Il se peut que vous souhaitiez suivre les clients (ou des propriétés afférentes) avec lesquels vous avez eu une bonne ou une mauvaise expérience lors d'un précédent achat. Par exemple, si vous avez livré un produit à une adresse mais n'avez pas été réglé car la carte utilisée pour le paiement était frauduleuse, vous pouvez mettre ce numéro de carte en liste noire afin que la demande de paiement soit rejetée si cette carte est à nouveau utilisée sur votre boutique.

Autre exemple : vous pouvez ajouter un nom de client à une liste si vous pensez que ce client a des problèmes de solvabilité, par exemple si une tentative d'autorisation financière a été rejetée avec un code indiquant un « solde insuffisant » du compte. Dans ce cas, peut-être ne voulez-vous pas rejeter la transaction immédiatement mais être alerté si ce nom est utilisé à nouveau dans une transaction.

Vous pouvez aussi gérer ce nom dans ce que l'on appelle une liste grise. Vous pouvez ainsi recevoir une alerte si l'une des propriétés est utilisée de nouveau lors d'une transaction différente, et traiter la nouvelle transaction avec une attention particulière, effectuer une vérification manuelle, etc. Les listes grises sont également un moyen de gérer les propriétés (données transactionnelles) que l’on suppose liées à la fraude.

D'autre part, il se peut que vous ayez eu de mauvaises expériences avec certains clients, mais aussi des expériences très positives avec d'autres. Vous pouvez ainsi, par exemple, traiter certains clients comme des « VIP ». Les clients B2B peuvent également s'avérer suffisamment fiables. Les listes dites blanches représentent le moyen approprié de gérer ces clients.

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.

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

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).
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Au moins une adresse e-mail fait partie de la liste Noire 31 Négatif --
Grise 32
Blanche AC Positif
Aucune adresse e-mail ne fait partie de la liste Noire -- Neutre
Grise
Blanche
Aucune adresse e-mail n’a été transmise Noire
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteEmail
<urn:fraudData>
     <urn:bypassCtrlList>WhiteEmail</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteEmail"]
}

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

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.
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
L’adresse IP n’est pas renseignée (en Sips Office) Noire -- Neutre --
Grise
Blanche
L’adresse IP appartient à la liste Noire 37 Négatif
Grise 38
Blanche AE Positif
L’adresse IP n’appartient pas à la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteIp
<urn:fraudData>
     <urn:bypassCtrlList>WhiteIp</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteIp"]
}

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

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).
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Aucun code postal n'a été transmis Noire -- Neutre --
Grise
Blanche
Au moins un code postal fait partie de la liste Noire 39 Négatif
Grise 40
Blanche AG Positif
Aucun code postal ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhitePostalCode
<urn:fraudData>
     <urn:bypassCtrlList>WhitePostalCode</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhitePostalCode"]
}

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

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).
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
L’identifiant client n’est pas fourni Noire -- Neutre --
Grise
Blanche
Au moins un identifiant client fait partie de la liste Noire 28 Négatif
Grise 29
Blanche AB Positif
L’identifiant client ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteCustomerId
<urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerId</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteCustomerId"]
}

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

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).
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Aucun nom de client n'a été transmis Noire -- Neutre --
Grise
Blanche
Au moins un nom de client fait partie de la liste Noire 35 Négatif
Grise 36
Blanche AF Positif
Aucun nom de client ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteCustomerName
<urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerName</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteCustomerName"]
}

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

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.
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) Noire -- Neutre --
Grise
Blanche
Le numéro de la carte fait partie de la liste Noire 50 Négatif
Grise 03
Blanche AA Positif
Le numéro de la carte ne fait pas partie de de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteCard
<urn:fraudData>
     <urn:bypassCtrlList>WhiteCard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteCard"]
}

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

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).
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Aucun numéro de téléphone n’a été transmis Noire -- Neutre --
Grise
Blanche
Au moins un numéro de téléphone fait partie de la liste Noire 33 Négatif
Grise 34
Blanche AD Positif
Aucun numéro de téléphone ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhitePhoneNumber
<urn:fraudData>
     <urn:bypassCtrlList>WhitePhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhitePhoneNumber"]
}

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

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

Note: veuillez consulter le glossaire pour plus d'informations sur les BIN.
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) Noire -- Neutre --
Grise
Blanche
Le numéro de BIN de la carte fait partie de la liste Noire 41 Négatif
Grise 08
Blanche AH Positif
Le numéro de BIN de la carte ne fait pas partie de de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteBinCard
<urn:fraudData>
     <urn:bypassCtrlList>WhiteBinCard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteBinCard"]
}

Cette règle vous permet de mesurer le risque sur un achat lié à un BIC (Bank Identifier Code) qui appartient à la liste noire, grise et/ou blanche de BIC, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste de BIC VIP).

Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.

La règle va vérifier l’appartenance du BIC à la liste noire, grise et/ou blanche de BIC que vous avez définie(s).

Si le BIC est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.

Tip: vous pouvez transmettre le BIC dans la requête. Sinon il sera automatiquement retrouvé à partir de l’IBAN que vous devez obligatoirement transmettre.

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.

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Le BIC fait partie de la liste Noire 66 Négatif --
Grise 67
Blanche AI Positif
Le BIC ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteBic
<urn:fraudData>
     <urn:bypassCtrlList>WhiteBic</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteBic"]
}

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

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.

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
L'IBAN fait partie de la liste Noire 68 Négatif --
Grise 59
Blanche AJ Positif
L'IBAN ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteIban
<urn:fraudData>
     <urn:bypassCtrlList>WhiteIban</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteIban"]
}

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

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.

Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Le RUM du mandat fait partie de la liste Noire 70 Négatif --
Grise 71
Blanche AK Positif
Le RUM du mandat ne fait pas partie de la liste Noire -- Neutre
Grise
Blanche

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

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

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 pour une liste blanche :

fraudData.bypassCtrlList=WhiteMandate
<urn:fraudData>
     <urn:bypassCtrlList>WhiteMandate</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["WhiteMandate"]
}

Le moteur de gestion de la lutte contre la fraude permet de prendre en compte la composition du panier de la transaction pour en mesurer le risque. Pour ce faire, il utilise des listes de produits à risque que vous définissez vous-même.

Un produit à risque est un produit que vous vendez et considèrez comme potentiellement associé à des transactions à risque selon certains critères qui vous appartiennent : catégorie ou type de produit, prix du produit, utilisation régulière d’un produit dans des transactions frauduleuses, etc.

Vous avez la possibilité de définir jusqu’à 3 listes de produits à risque pour votre boutique. Vous pouvez ainsi ajouter tout ou partie des produits que vous vendez dans une ou plusieurs listes selon le niveau de risque du produit.

Par exemple, vous pouvez choisir de créer les 3 listes de produits à risques suivantes :

  • une liste de produits à faible risque ;
  • une liste de produits à risque modéré ;
  • et une liste de produits à haut risque.

Les listes de produits à risque sont exploitées par des règles de détection de risque du contenu du panier du client qui effectue un achat sur votre site. Si ces règles sont activées, elles vont analyser le contenu du panier et le comparer aux listes de produits à risque que vous avez définies afin d'évaluer le risque de la transaction. Vous pouvez ainsi limiter l‘achat de certains produits à une certaine quantité ou un certain ratio du montant global.

IMPORTANT: les produits sont identifiés par le moteur de lutte contre la fraude sur la base de leur code produit, qui doit se trouver à la fois dans les listes de produits à risque et dans les données du panier de la transaction. Il est essentiel que ces codes concordent entre les listes et le panier.

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.

Cette règle vous permet de vérifier la présence ou non de produits à risque dans le panier du client.

La règle va interroger les listes de produits à risque définies par vos soins et paramétrées dans la règle afin de vérifier si l’un des produits du panier du client contient un produit que vous considérez comme potentiellement risqué.

Si la requête que vous envoyez ne contient pas de liste de produits à risque pour la boutique ou de contenu du panier, la règle retourne un résultat neutre.

Attention: cette règle ne peut pas être décisive afin de ne pas bloquer toutes les transactions d’une boutique. En effet les produits contenus dans les listes de produits à risque sont forcément des produits que vous vendez, tout comme les produits présents dans le panier.

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 ShoppingCartDetail).
Cas d'utilisation Complementary Code Résultat de la règle Rule DetailedInfo
Au moins un produit du panier appartient à une liste de produits à risque 51 Négatif --
L'information n'est pas connue -- Neutre
Aucun produit du panier n’appartient à une liste de produits à risque -- Neutre

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

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.

Exemples :

fraudData.bypassCtrlList=RiskyProductList
<urn:fraudData>
     <urn:bypassCtrlList>RiskyProductList</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["RiskyProductList"]
}

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.

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 ShoppingCartDetail).
Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Au moins un produit du panier appartenant à une liste de produits à risque a une quantité supérieure au seuil paramétré dans la règle
et/ou
la quantité totale des produits appartenant à une liste de produits à risque est supérieure au seuil paramétré dans la règle
52 Négatif MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*
L'information n'est pas connue -- Neutre --
Aucun produit du panier n’appartient à une liste de produits à risque
ou
Aucun produit du panier appartenant à une liste de produits à risque n’a une quantité supérieure au seuil paramétré dans la règle
-- Neutre MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*

*L : le nom de la liste de produits à risque concernée.

A : la quantité la plus grande d’un produit du panier appartenant à cette liste de produits à risque.

B : la quantité maximum acceptée pour un produit appartenant à cette liste de produits à risque.

C : la somme des quantités des produits du panier appartenant à cette liste de produits à risque.

D : la quantité maximum acceptée pour tous les produits du panier appartenant à cette liste de produits à risque.

Note: jusqu’à 3 listes de produits à risque peuvent être paramétrées pour cette règle. Les valeurs MAX_QUANTITY_PER_RISKY_PRODUCT et MAX_QUANTITY_PER_LIST sont restituées dans le champ complementaryInfo pour chacune de ces listes. Pour cette règle il est donc possible d’avoir ces valeurs jusqu’à 3 fois dans le champ complementaryInfo.

MAX_QUANTITY_PER_RISKY_PRODUCT=L1:A1:B1;MAX_QUANTITY_PER_LIST=L1:C1:D1; MAX_QUANTITY_PER_RISKY_PRODUCT=L2:A2:B2;MAX_QUANTITY_PER_LIST=L2:C2:D2; MAX_QUANTITY_PER_RISKY_PRODUCT=L3:A3:B3;MAX_QUANTITY_PER_LIST=L3:C3:D3

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

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.

Exemples :

fraudData.bypassCtrlList=RiskyProductQuantity
<urn:fraudData>
     <urn:bypassCtrlList>RiskyProductQuantity</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["RiskyProductQuantity"]
}

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.

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 ShoppingCartDetail).
Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Le plus grand ratio entre le montant total pour au moins un produit appartenant à une liste de produits à risque et le montant total du panier est supérieur au seuil paramétré dans la règle
et/ou
le ratio entre le montant total de tous les produits appartenant à une liste de produits à risque et le montant total du panier est supérieur au seuil paramétré dans la règle
53 Négatif MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*
L'information n'est pas connue -- Neutre --
Aucun produit du panier n’appartient à une liste de produits à risque
ou
Le ratio entre le montant total pour un produit appartenant à une liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle et le ratio entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle
-- Neutre MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*

*L : le nom de la liste de produits à risque concernée.

A : le plus grand ratio entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.

B : le ratio maximum accepté entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.

C : le plus grand ratio entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.

D : le ratio maximum accepté entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.

Note: jusqu’à 3 listes de produits à risque peuvent être utilisées pour cette règle. Les valeurs MAX_RATIO_PER_RISKY_PRODUCT et MAX_QUANTITY_PER_LIST sont restituées dans le champ scoreInfo pour chacune de ces listes. Pour cette règle il est donc possible d’avoir ces valeurs jusqu’à 3 fois dans le champ scoreInfo.

MAX_RATIO_PER_RISKY_PRODUCT=L1:A1:B1;MAX_RATIO_PER_LIST=L1:C1:D1; MAX_RATIO_PER_RISKY_PRODUCT=L2:A2:B2;MAX_RATIO_PER_LIST=L2:C2:D2; MAX_RATIO_PER_RISKY_PRODUCT=L3:A3:B3;MAX_RATIO_PER_LIST=L3:C3:D3

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

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.

Exemples :

fraudData.bypassCtrlList=RiskyProductRatio
<urn:fraudData>
     <urn:bypassCtrlList>RiskyProductRatio</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["RiskyProductRatio"]
}

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.

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 ShoppingCartDetail).
Cas d'utilisation Complementary Code Résultat de la règle RuleDetailedInfo
Au moins un produit du panier a une quantité supérieure au seuil paramétré dans la règle 54 Négatif PRODUCTQUANTITY =A:B*
L'information n'est pas connue -- Neutre PRODUCTQUANTITY =XXX:B*
Aucun produit du panier n’a une quantité supérieure au seuil paramétré dans la règle -- Neutre PRODUCTQUANTITY =A:B*

* A : la quantité du premier produit trouvé dont la quantité est supérieure au seuil défini dans la règle.

B : la quantité maximum de chaque produit acceptée dans le panier.

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

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.

Exemples :

fraudData.bypassCtrlList=MaxQuantityPerProduct
<urn:fraudData>
     <urn:bypassCtrlList>MaxQuantityPerProduct</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["MaxQuantityPerProduct"]
}

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 (consulter le dictionnaire des données pour connaître les valeurs possibles pour chaque champ).

fraudData.bypassCtrlList Désactiver les règles standards
fraudData.bypassInfoList Obsolète

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 :
  • relayer du spam pour du commerce illégal ou pour de la manipulation d'information (par exemple des cours de bourse) ;
  • réaliser des opérations de phising ;
  • identifier et infecter d’autres machines par diffusion de virus et de programmes malveillants (malwares) ;
  • participer à des attaques groupées (DDoS) ;
  • générer de façon abusive des clics sur un lien publicitaire au sein d’une page web ;
  • capturer de l’information sur les machines compromises (vol puis revente d'information) ;
  • exploiter la puissance de calcul des machines ou effectuer des opérations de calcul distribué notamment pour cassage de mots de passe ;
  • mener des opérations de commerce illicite en gérant l'accès à des sites de ventes de produits interdits ou de contrefaçons via des techniques de fast-flux, simple ou double-flux ou RockPhish.
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 :
  • l’inondation d’un réseau afin d'empêcher son fonctionnement ;
  • la perturbation des connexions entre deux machines, empêchant l'accès à un service particulier ;
  • l'obstruction d'accès à un service à une personne en particulier ;
  • également le fait d'envoyer des milliards d'octets à une box internet.
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 :
  • vulnérabilités du serveur web. Ce type de cas est de plus en plus rare car au fur et à mesure des années les principaux développeurs de serveurs web ont renforcé leur sécurisation ;
  • manipulation des URL, consistant à modifier manuellement les paramètres des URL afin de modifier le comportement attendu du serveur web ;
  • exploitation des faiblesses des identifiants de session et des mécanismes d'authentification ;
  • injection de code HTML et Cross-Site Scripting ;
  • injection de commandes SQL.
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.

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 émetteur de la carte et de l’adresse IP, Pays émetteur de la carte et pays de livraison et Pays de facturation et pays émetteur 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. Image trop complexe à décrire. Merci de contacter le support


Règles d'encours. Image trop complexe à décrire. Merci de contacter le support


Règles diverses. Image trop complexe à décrire. Merci de contacter le support


Règles de liste. Image trop complexe à décrire. Merci de contacter le support


Règles panier. Image trop complexe à décrire. Merci de contacter le support

Le mode pré-authentification est applicable uniquement pour les transactions carte (sauf portes feuilles numériques).

Légende des images :

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 émetteur de la carte et de l’adresse IP, Pays émetteur de la carte et de livraison et Pays émetteur de la carte et de facturation, 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. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com


Règles d'encours. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com


Règles diverses. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com


Règles de liste. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com


Règles panier. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com

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.

Les fichiers contenant une liste de pays (obtenu avec une règle comme « pays émetteur 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 émetteur de la carte » d'un profil :

Pays
FRA
DEU
BEL

Le fichier sera alors le suivant :

country_list.csv

COUNTRY;
FRA;
DEU;
BEL;

Les fichiers contenant une liste de couples de pays (obtenu avec une règle comme « pays émetteur 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 émetteur 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;

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;

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.

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;

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;

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

Ce site utilise des traceurs pour améliorer votre expérience de navigation, effectuer des analyses et des recherches sur votre utilisation du site web de documentation WL Sips.
En fermant ce bandeau vous refusez notre utilisation des traceurs sur votre appareil.

Paramètres