WL SIPS DOCS

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.

Mode de configuration simple :

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

Mode de configuration avancée :

* XXX : code pays alphabétique ISO 3166 (cf. champ 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.

Mode de configuration simple :

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

Mode de configuration avancée :

* XXX : code pays alphabétique ISO 3166 (cf. champ 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.

Mode de configuration simple :

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

Mode de configuration avancée :

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

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

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

Mode de configuration simple :

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

Mode de configuration avancée :

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

Mode de configuration simple :

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

Mode de configuration avancée :

* 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"]
}

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.

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"]
}

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

Mode de configuration simple :

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

Mode de configuration avancée :

* XXX : code pays alphabétique ISO 3166 (cf. champ 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).

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 :

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

Mode de configuration avancée :

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

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 :

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

Mode de configuration avancée :

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

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

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

Mode de configuration avancée :

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

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

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.

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

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

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.

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

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

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

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

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 :

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

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

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 :

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

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

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 :

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.

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

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 :

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.

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

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 :

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.

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

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 :

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

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

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 :

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

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

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 :

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.

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

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

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

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

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

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.

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

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.

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

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.

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.

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

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.

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

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.

Mode par défaut :

Mode de configuration avancée :

__________

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

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

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.

Mode par défaut (configuration simple) :

Mode de configuration avancée :

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

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.

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

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

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.

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

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.

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

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.

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