Liste des règles
Les règles peuvent être paramétrées en combinant les modes décisif ou informatif d'une part et les modes pré-autorisation ou pré-authentification d'autre part.
Règles de géolocalisation : adresse et pays
Pays émetteur de la carte
Description de la règle
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é.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- et paramétrer la liste des pays é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.
Notre module de fraude a pour référence la base CIS (Card Info Service), qui contient des informations sur les plages de BIN. Or ce référentiel ne contient pas la nationalité des cartes American Express. Il nous est donc impossible, via le module de fraude, de bloquer les cartes American Express via la règle « Pays émetteur de la carte ».
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CR;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte n’est pas connu | 0 | CR;N; CARD_COUNTRY=XXX* |
CARD_COUNTRY=XXX* |
Le pays de la carte est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés ou n’est pas équivalent au pays du marchand | 0 à -4 selon paramétrage | ||
Le pays de la carte est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits ou est différent du pays du marchand | 0 |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CR;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte n’est pas connu | 0 | CR;N; CARD_COUNTRY=XXX* |
CARD_COUNTRY=XXX* |
Le pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » ou est équivalent à votre pays | 0 à -4 selon paramétrage | ||
Le pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
Le pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous avez la possibilité de fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Il existe 2 méthodes pour surcharger dynamiquement les paramètres de la règle.
MÉTHODE 1 :
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedCardCountryList pour la liste des pays autorisés,
- DeniedCardCountryList pour la liste des pays interdits,
- mode de configuration avancée :
- NDeniedCardCountryList pour la liste des pays désavantagés,
- NDeniedExceptCardCountryList pour la liste des pays non désavantagés,
- PAllowedCardCountryList pour la liste des pays avantagés,
- PAllowedExceptCardCountryList pour la liste des pays non avantagés.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedCardCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
"riskManagementDynamicSettingList":[
{
"riskManagementDynamicParam":"AllowedCardCountryList",
"riskManagementDynamicValue":"FRA,BEL,GBR"
}
]
}
MÉTHODE 2 (dépréciée) :
La liste des pays carte est transmise dans le champ du connecteur :
- fraudData.allowedCardCountryList pour la liste des pays autorisés ;
- fraudData.deniedCardCountryList pour la liste des pays interdits.
Exemples:
<urn:fraudData>
<urn:allowedCardCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
"fraudData": {
"allowedCardCountryList": ["FRA", "BEL", "GBR"]
}
Pour les 2 méthodes, la liste envoyée doit contenir :
- soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. 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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive ForeignBinCard.
Exemples :
Pays de l'adresse IP
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en fonction du pays affecté à l’adresse IP de l’acheteur.
La règle va vérifier l’appartenance du pays de l’adresse IP à une liste de pays autorisés ou interdits. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage. Dans ce cas-là, une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre code pays comme le seul autorisé.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l'onglet 'Fraude' du Merchant Extranet.
- paramétrer la liste des pays de l'adresse IP autorisés ou interdits.
Pour cela, vous devez :
- paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du Merchant Extranet,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
et transmettre l'adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le pays de l'adresse IP n’est pas connu. | 0 | CY;N;IP_COUNTRY=XXX | IP_COUNTRY=XXX |
Le pays de l'adresse IP est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés. | 0 à -4 selon paramétrage | CY;N;IP_COUNTRY=XXX* | IP_COUNTRY=XXX* |
Le pays de l'adresse IP est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits. | 0 |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | Scoreinfo | RuleDetailedInfo |
---|---|---|---|
Le pays de l'adresse IP n’est pas connu. | 0 | CY;N;IP_COUNTRY=XXX | IP_COUNTRY=XXX |
Le pays de l'adresse IP est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». | 0 à -4 selon paramétrage | CY;N;IP_COUNTRY=XXX* | IP_COUNTRY=XXX* |
Le pays de l'adresse IP est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». | 0 | ||
Le pays de l'adresse IP est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». | 0 à +4 selon paramétrage |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous avez la possibilité de fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Il existe 2 méthodes pour surcharger dynamiquement les paramètres de la règle.
MÉTHODE 1 :
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedIpCountryList pour la liste des pays autorisés,
- DeniedIpCountryList pour la liste des pays interdits,
- mode de configuration avancée :
- NDeniedIpCountryList pour la liste des pays désavantagés,
- NDeniedExceptIpCountryList pour la liste des pays non désavantagés,
- PAllowedIpCountryList pour la liste des pays avantagés,
- PAllowedExceptIpCountryList pour la liste des pays non avantagés.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedIpCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
"riskManagementDynamicSettingList":[
{
"riskManagementDynamicParam":"AllowedIpCountryList",
"riskManagementDynamicValue”:“FRA,BEL,GBR"
}
]
}
MÉTHODE 2 (dépréciée) :
La liste des pays de l'adresse IP est transmise dans le champ du connecteur :
- fraudData.allowedIpCountryList pour la liste des pays autorisés ;
- fraudData.deniedIpCountryList pour la liste des pays interdits.
Exemples :
<urn:fraudData>
<urn:allowedIpCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
"fraudData": {
"allowedIpCountryList": ["FRA", "BEL", "GBR"]
}
Pour les 2 méthodes, la liste envoyée doit contenir :
- soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. 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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive IpCountry.
Exemples :
Pays émetteur de la carte et de l'adresse IP
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays é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.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer la liste des combinaisons pays é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.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | SI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). | 0 | SI;N; CARD_COUNTRY=XXX; IP_COUNTRY=YYY* |
CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY* |
La combinaison du pays de la carte et du pays de l'adresse IP est interdite. | 0 à -4 selon paramétrage | ||
La combinaison du pays de la carte et du pays de l'adresse IP est autorisée. | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | SI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). | 0 | SI;N; CARD_COUNTRY=XXX; IP_COUNTRY=YYY* |
CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY* |
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». | 0 à -4 selon paramétrage | ||
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». | 0 | ||
La combinaison du pays de la carte et du pays de l'adresse IP est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous avez la possibilité d'envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedIpCardCountryCombiList pour les combinaisons autorisées de pays é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 :
<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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilityIpCard.
Exemples :
Pays de livraison et de facturation
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en vérifiant que le pays de livraison et le pays de facturation sont identiques.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et transmettre le pays de livraison et de facturation dans la requête (champs billingAddress.country et deliveryAddress.country).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le pays de livraison ne correspond pas au pays de facturation | 0 à -4 selon paramétrage | SB;N; SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY* |
Le pays de livraison correspond au pays de facturation | 0 | ||
Non connaissance des pays | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryBillingCountry.
Exemples :
Codes postaux de livraison et de facturation
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en vérifiant que le code postal de livraison et le code postal de facturation sont identiques.
Vous ne pouvez activer cette règle que si vous avez aussi activé la règle de comparaison des pays de livraison et de facturation. En effet, il n’est pas pertinent de comparer des codes postaux si les pays ne sont pas identiques.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- avoir déjà la règle « Pays de livraison et de facturation » activée ;
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et transmettre le code postal de livraison et de facturation dans la requête (champs billingAddress.zipCode et deliveryAddress.zipCode).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le code postal de livraison ne correspond pas au code postal de facturation | 0 à -4 selon paramétrage | ZC;N; SHIP_COUNTRY=XXX; BILL_COUNTRY=YYY; SHIP_ZIP=A; BILL_ZIP=B* |
SHIP_COUNTRY=XXX*;
BILL_COUNTRY=YYY*; SHIP_ZIP=A*; BILL_ZIP=B* |
Le code postal de livraison correspond au code postal de facturation | 0 | ||
Non connaissance des codes postaux | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
A, B : code postal
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryBillingPostalCode.
Exemples :
Pays émetteur de la carte et de livraison
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays é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.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer les combinaisons de pays é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).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays de la carte est interdite. | 0 à -4 selon paramétrage | CS;N; SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
La combinaison du pays de livraison et du pays de la carte est autorisée. | 0 | ||
Non connaissance du pays de la carte ou du pays de livraison. | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». | 0 à -4 selon paramétrage | CS;N; SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». | 0 | ||
Non connaissance du pays de la carte ou du pays de livraison. | 0 | ||
La combinaison du pays de livraison et du pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedDeliveryCardCountryCombiList pour les combinaisons autorisées de pays de livraison et de la carte,
- DeniedDeliveryCardCountryCombiList pour les combinaisons interdites de pays de livraison et de la carte,
- mode de configuration avancée :
- NDeniedDeliveryCardCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptDeliveryCardCountryCombiList pour la liste des pays non désavantagés,
- PAllowedDeliveryCardCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptDeliveryCardCountryCombiList pour la liste des pays non avantagés.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedDeliveryCardCountryCombiList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
"riskManagementDynamicSettingList":[
{
"riskManagementDynamicParam":"AllowedDeliveryCardCountryCombiList",
"riskManagementDynamicValue":"(FRA,#ZEURO),(#ZEURO,FRA)"
}
]
}
Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :
- soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. 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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryCardCountry.
Exemples :
Pays émetteur de la carte et de facturation
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en se basant sur la combinaison du pays é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.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer les combinaisons de pays é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).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de facturation et du pays de la carte est interdite. | 0 à -4 selon paramétrage | CS;N; BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
La combinaison du pays de facturation et du pays de la carte est autorisée. | 0 | ||
Non connaissance du pays de la carte ou du pays de facturation. | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » | 0 à -4 selon paramétrage | CS;N; BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY* |
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
Non connaissance du pays de la carte ou du pays de facturation. | 0 | ||
La combinaison du pays de facturation et du pays de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons de pays de facturation et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedBillingCardCountryCombiList pour les combinaisons autorisées de pays de facturation et de la carte,
- DeniedBillingCardCountryCombiList pour les combinaisons interdites de pays de facturation et de la carte,
- mode de configuration avancée :
- NDeniedBillingCardCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptBillingCardCountryCombiList pour la liste des pays non désavantagés,
- PAllowedBillingCardCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptBillingCardCountryCombiList pour la liste des pays non avantagés.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedBillingCardCountryCombiList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
"riskManagementDynamicSettingList":[
{
"riskManagementDynamicParam":"AllowedBillingCardCountryCombiList",
"riskManagementDynamicValue":"(FRA,#ZEURO),(#ZEURO,FRA)"
}
]
}
Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :
- soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. 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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityBillingCardCountry.
Exemples :
Pays de l'IBAN
Description de la règle
La règle du pays de l’IBAN vous permet de mesurer le risque sur un achat en fonction du pays d’émission de l’IBAN du client.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.
La règle va analyser le numéro de l’IBAN pour en extraire le pays et vérifier l’appartenance de celui-ci à une liste de pays autorisés ou interdits.
En l’absence de liste de pays autorisés ou interdits, le contrôle considère votre pays comme le seul autorisé.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profilvia l’onglet fraude du Merchant Extranet,
- et paramétrer la liste des pays d'IBAN autorisés ou interdits. Pour
cela, vous devez :
- paramétrer la liste des pays autorisés ou interdits via l’onglet fraude du Merchant Extranet,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | AC;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de l’IBAN est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés ou est différent de votre pays | 0 à -4 selon paramétrage | AC;N; IBAN_COUNTRY=XXX* |
IBAN_COUNTRY=XXX* |
Le pays de l’IBAN est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits ou est équivalent à votre pays | 0 |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | AC;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays de l’IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » | 0 à -4 selon paramétrage | AC;N; IBAN_COUNTRY=XXX* |
IBAN_COUNTRY=XXX* |
Le pays de l’IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
Le pays de l’IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous pouvez fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedIbanCountryList pour la liste des pays autorisés,
- DeniedIbanCountryList pour la liste des pays interdits,
- mode de configuration avancée :
- NDeniedIbanCountryList pour la liste des pays désavantagés,
- NDeniedExceptIbanCountryList pour la liste des pays non désavantagés,
- PAllowedIbanCountryList pour la liste des pays avantagés,
- PAllowedExceptIbanCountryList pour la liste des pays non avantagés.
Exemple :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedIbanCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
"riskManagementDynamicSettingList":[
{
"riskManagementDynamicParam":"AllowedIbanCountryList",
"riskManagementDynamicValue":"FRA,BEL,GBR"
}
]
}
La liste envoyée doit contenir :
- soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf. 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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive IbanCountry.
Exemples :
Pays de livraison et de l'IBAN
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays de livraison et du pays de l’IBAN du client.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.
Elle va vérifier la présence de la combinaison du pays de livraison et du pays de l’IBAN dans la liste des combinaisons autorisées ou interdites.
En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de livraison et le pays de l’IBAN.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer les combinaisons de pays de livraison et de pays de
l'IBAN autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Merchant Extranet,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre le pays de livraison dans la requête (champ deliveryAddress.country).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | DI;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays de l'IBAN est interdite | 0 à -4 selon paramétrage | DI;N; SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
La combinaison du pays de livraison et du pays de l'IBAN est autorisée | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | DI;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » | 0 à -4 selon paramétrage | DI;N; SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays de livraison et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
La combinaison du pays de livraison et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
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 :
<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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityDeliveryIbanCountry.
Exemples :
Pays du numéro de téléphone et de l'IBAN
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays du numéro de téléphone portable du client et du pays de l’IBAN du client.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.
La règle va vérifier la présence de la combinaison du pays du numéro de téléphone portable du client et du pays de l’IBAN dans la liste des combinaisons autorisées ou interdites.
Le pays du numéro de téléphone est obtenu en analysant l’indicatif de celui-ci. Si l’indicatif n’est pas spécifié, le pays ne pourra être récupéré.
En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays du numéro de téléphone portable du client et le pays de l’IBAN.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer les combinaisons de pays de numéro de téléphone et de
pays de l'IBAN autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Merchant Extranet,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre le numéro de téléphone portable du client dans la requête (avec indicatif ; champ mobile dans un ou plusieurs groupes d’informations de contact : billingContact, customerContact, deliveryContact, holderContact).
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | PI;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est interdite | 0 à -4 selon paramétrage | PI;N; PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays du numéro de téléphone portable du client et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est autorisée | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | PI;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » | 0 à -4 selon paramétrage | PI;N; PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays du numéro de téléphone portable du client et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
La combinaison du pays du numéro de téléphone portable du client et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons du pays du numéro de téléphone portable du client et pays de l’IBAN. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les 2 paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedPhoneIbanCountryCombiList pour les combinaisons autorisées de pays du numéro de téléphone portable du client et de l’IBAN,
- DeniedPhoneIbanCountryCombiList pour les combinaisons interdites de pays du numéro de téléphone portable du client et de l’IBAN,
- mode de configuration avancée :
- NDeniedPhoneIbanCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptPhoneIbanCountryCombiList pour la liste des pays non désavantagés,
- PAllowedPhoneIbanCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptPhoneIbanCountryCombiList pour la liste des pays non avantagés.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityPhoneIbanCountry.
Exemples :
Pays de l'adresse IP et de l'IBAN
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat en se basant sur la combinaison du pays de l’adresse IP du client et du pays de l’IBAN du client.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD.
Elle va vérifier l’appartenance de la combinaison du pays de l’adresse IP et du pays de l’IBAN à une liste de combinaisons de pays autorisés ou interdits.
Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage. Dans ce cas-là, Une incertitude peut persister sur le pays de l'internaute essentiellement due à l'attribution dynamique d'adresses IP par certains providers ou aux adresses IP dynamiques ;
- ou du transfert que vous effectuez dans la requête en Sips Office. En l’absence de liste de combinaisons autorisées ou interdites, la règle vérifiera la concordance entre le pays de l’adresse IP du client et le pays de l’IBAN.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer les combinaisons de pays d'adresse IP et de pays de
l'IBAN autorisés ou interdits. Pour cela, vous devez :
- paramétrer les combinaisons autorisées ou interdites via l’onglet fraude du Merchant Extranet,
- ou surcharger dynamiquement les combinaisons autorisées ou interdites dans votre requête.
et transmettre l'adresse IP de l'acheteur dans la requête, si vous êtes sur Sips Office.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | IS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de l’adresse IP et du pays de l'IBAN est interdite | 0 à -4 selon paramétrage | IS;N; IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays de l’adresse IP et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
La combinaison du pays de l’adresse IP et du pays de l'IBAN est autorisée | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas SDD) | 0 | IS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » | 0 à -4 selon paramétrage | IS;N; IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY* |
Le pays de l'adresse IP et/ou le pays de l'IBAN n’est/ne sont pas connu(s) | 0 | ||
La combinaison du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
La combinaison du pays de l'adresse IP et du pays de l'IBAN est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous pouvez envoyer, dans la requête de paiement, la liste de combinaisons du pays de l’adresse IP et pays de l’IBAN. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les 2 paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- AllowedIpIbanCountryCombiList pour les combinaisons autorisées de pays d’adresse IP et de l’IBAN,
- DeniedIpIbanCountryCombiList pour les combinaisons interdites de pays d’adresse IP et de l’IBAN,
- mode de configuration avancée :
- NDeniedIpIbanCountryCombiList pour la liste des pays désavantagés,
- NDeniedExceptIpIbanCountryCombiList pour la liste des pays non désavantagés,
- PAllowedIpIbanCountryCombiList pour la liste des pays avantagés,
- PAllowedExceptIpIbanCountryCombiList pour la liste des pays non avantagés.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedIpIbanCountryCombiList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>>>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
"riskManagementDynamicSettingList":[
{
"riskManagementDynamicParam":"AllowedIpIbanCountryCombiList",
"riskManagementDynamicValue":"(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)"
}
]
}
Pour les 2 méthodes, la liste envoyée doit contenir des couples séparés par des virgules et constitués :
- soit de codes pays au format des codes pays alphabétiques ISO 3166 (cf. 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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityIpIbanCountry.
Exemples :
Pays d'émission de la carte
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- et paramétrer la liste des pays 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.
Notre module de fraude a pour référence la base CIS (Card Info Service), qui contient des informations sur les plages de BIN. Or ce référentiel ne contient pas la nationalité des cartes American Express. Il nous est donc impossible, via le module de fraude, de bloquer les cartes American Express via la règle « Pays d'émission de la carte ».
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CardIssuingCountry.
Exemples :
Description de la règle
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é.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CR;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays d'émission de la carte n’est pas connu | 0 | CR;N; CARD_ISSUING_COUNTRY=XXX* |
CARD_ISSUING_COUNTRY=XXX* |
Le pays d'émission de la carte est dans la liste des pays interdits ou n’est pas dans la liste des pays autorisés ou n’est pas équivalent au pays du marchand | 0 à -4 selon paramétrage | ||
Le pays d'émission de la carte est dans la liste des pays autorisés ou n’est pas dans la liste des pays interdits ou est différent du pays du marchand | 0 |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CR;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays d'émission de la carte n’est pas connu | 0 | CR;N; CARD_ISSUING_COUNTRY=XXX* |
CARD_ISSUING_COUNTRY=XXX* |
Le pays d'émission de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » ou est équivalent à votre pays | 0 à -4 selon paramétrage | ||
Le pays d'émission de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
Le pays d'émission de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX : code pays alphabétique ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous avez la possibilité de fournir dynamiquement dans la requête une liste des pays autorisés ou une liste des pays interdits. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Il existe 2 méthodes pour surcharger dynamiquement les paramètres de la règle.
MÉTHODE 1 :
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- 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 :
<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:
<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.
Pays d'émission de la carte et de facturation
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer les combinaisons de pays de facturation et 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).
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityBillingCardIssuingCountry.
Exemples :
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en se basant sur la combinaison du pays 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.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de facturation et du pays d'émission de la carte est interdite. | 0 à -4 selon paramétrage | CS;N; BILL_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
BILL_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
La combinaison du pays de facturation et du pays d'émission de la carte est autorisée. | 0 | ||
Non connaissance du pays d'émission de la carte ou du pays de facturation. | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de facturation et du pays d'émission de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés » | 0 à -4 selon paramétrage | CS;N; BILL_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
BILL_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
La combinaison du pays de facturation et du pays d'émission de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés » | 0 | ||
Non connaissance du pays d'émission de la carte ou du pays de facturation. | 0 | ||
La combinaison du pays de facturation et du pays d'émission de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés » | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
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 :
<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.
Pays d'émission de la carte et de livraison
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer les combinaisons de pays de livraison et 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).
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilarityShippingCardIssuingCountry.
Exemples :
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays 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.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays d'émission de la carte est interdite. | 0 à -4 selon paramétrage | CS;N; SHIP_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
La combinaison du pays de livraison et du pays d'émission de la carte est autorisée. | 0 | ||
Non connaissance du pays d'émission de la carte ou du pays de livraison. | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | CS;N;NOT_APPLICABLE | NOT_APPLICABLE |
La combinaison du pays de livraison et du pays d'émission de la carte est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». | 0 à -4 selon paramétrage | CS;N; SHIP_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
SHIP_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY* |
La combinaison du pays de livraison et du pays d'émission de la carte est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». | 0 | ||
Non connaissance du pays d'émission de la carte ou du pays de livraison. | 0 | ||
La combinaison du pays de livraison et du pays d'émission de la carte est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
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 :
<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.
Pays d'émission de la carte et de l'adresse IP
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer la liste des combinaisons pays 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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SimilityIpCard.
Exemples :
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en vous basant sur la combinaison du pays 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.
Restitution du résultat
Mode de configuration simple :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | SI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays d'émission de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). | 0 | SI;N; CARD_ISSUING_COUNTRY=XXX; IP_COUNTRY=YYY* |
CARD_ISSUING_COUNTRY=XXX* ; IP_COUNTRY=YYY* |
La combinaison du pays d'émission de la carte et du pays de l'adresse IP est interdite. | 0 à -4 selon paramétrage | ||
La combinaison du pays d'émission de la carte et du pays de l'adresse IP est autorisée. | 0 |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n'est pas une carte) | 0 | SI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le pays d'émission de la carte et/ou le pays de l'adresse IP n’est/ne sont pas connu(s). | 0 | SI;N; CARD_ISSUING_COUNTRY=XXX; IP_COUNTRY=YYY* |
CARD_ISSUING_COUNTRY=XXX* ; IP_COUNTRY=YYY* |
La combinaison du pays d'émission de la carte et du pays de l'adresse IP est dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays non désavantagés ». | 0 à -4 selon paramétrage | ||
La combinaison du pays d'émission de la carte et du pays de l'adresse IP est dans la liste des « pays non désavantagés » ou n’est pas dans la liste des « pays désavantagés » ou n’est pas dans la liste des « pays avantagés » ou est dans la liste des « pays non avantagés ». | 0 | ||
La combinaison du pays d'émission de la carte et du pays de l'adresse IP est dans la liste des « pays avantagés » ou n’est pas dans la liste des « pays non avantagés ». | 0 à +4 selon paramétrage |
* XXX, YYY : codes pays alphabétiques ISO 3166 (cf. champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous avez la possibilité d'envoyer, dans la requête de paiement, la liste de combinaisons de pays de livraison et de la carte. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les paramètres applicables à cette règle sont :
- mode par défaut (configuration simple) :
- 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 :
<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.
Règles d'encours (vélocité)
Les règles d’encours calculent le cumul du montant ou de la quantité pour un aspect de la transaction sur une période (quelquefois deux) et le comparent à un seuil à ne pas dépasser. Ils vous permettent de superviser les activités d'un client, d’une adresse IP, d’une carte, etc.
Par exemple, des règles d’encours peuvent se déclencher si le montant cumulé dépensé sur une carte particulière dépasse 1 500€ sur les dernières 24 h ou si un client a passé plus de 10 transactions sur la semaine écoulée.
Il existe deux manières de calculer les encours :
- par défaut, les encours sont calculés en prenant en compte les transactions d’une seule boutique ;
- vous pouvez également calculer les encours en cumulant les activités de plusieurs boutiques. Un tel encours est dit « partagé ». Les encours partagés élargissent le périmètre de la surveillance.
Pour mettre en place un encours partagé, vous devez contacter votre gestionnaire de compte pour la configuration. Deux étapes sont à respecter :
- tout d'abord créer un encours partagé en choisissant son type (encours par carte, encours par adresse IP, etc.) ;
- puis associer l’encours partagé aux boutiques.
Lors de l'exécution d’un contrôle de lutte contre la fraude, si la règle d’encours partagé est active dans le profil de la boutique, les activités seront calculées et ajoutées avec les activités des autres boutiques du groupe.
5 encours partagés peuvent être mis en place par type de règle d’encours et par groupe commercial.
Encours carte
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant cumulé des transactions) de la carte.
La règle est exécutée sur toutes les transactions de paiement effectuées avec une carte. Le calcul de l’encours prend en compte les transactions qui ont été acceptées au préalable sur les périodes indiquées. Il est aussi possible d'ajouter les transactions refusées à ce calcul.
La règle contrôle l’activité d’une carte sur deux périodes distinctes. Vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions, ainsi que les périodes respectives, lors du paramétrage du profil.
Exemple
Le tableau suivant décrit l'évolution de l'historique de la carte de paiement dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour la même carte, pour un montant total de 500 € et par mois (30 j) :
Date de la transaction | Détails du paiement | Résultat de la règle | Encours par carte (nombre de
transactions) |
Encours par carte (montant cumulé) |
État de l'historique (30 derniers jours) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Montant :
100 € Carte : CB1 |
OK | 1 | 100 € | TR1 01/10/2018 CB1 100 € |
07/10/2018 | Transaction TR2 Montant :
400 € Carte : CB2 |
OK | 1 | 400 € | TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2
400 € |
10/10/2018 | Transaction TR3 Montant :
400 € Carte : CB2 |
KO | 2 | 800 € (> 500) |
TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2 400 €
OK TR3 10/10/2018 CB2 400 € |
12/10/2018 | Transaction TR4 Montant :
200 € Carte : CB1 |
OK | 2 | 300 € | TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2
400 € OK TR3 10/10/2018 CB2 400 € KO TR4
12/10/2018 CB1 200 € |
15/10/2018 | Transaction TR5 Montant :
100 € Carte : CB1 |
KO | 3 (> 2) |
400 € | TR1 01/10/2018 CB1 100 € OK TR2 07/10/2018 CB2
400 € TR3 10/10/2018 CB2 400 € KO TR4
12/10/2018 CB1 200 € OK TR5 15/10/2018 CB1
100 € |
02/11/2018 (> 30j) |
Transaction TR6 Montant :
300 € Carte : CB1 |
OK | 1 | 300 € | TR6 02/11/2018 CB1 300 € |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- et paramétrer le nombre de transactions effectuées et/ou le montant cumulé, ainsi que les périodes respectives, via l’onglet fraude du Merchant Extranet.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Montant cumulé maximal | 0.01 sur la période en devise du commerçant | 9999999 |
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de transactions | 1 transaction sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | SC;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cette carte sur la période dépasse(nt) la/les limite(s) acceptée(s) | 0 à -4 selon paramétrage | SC;N;TRANS=A:B; CUMUL=C:D* |
TRANS=A:B; CUMUL=C:D* |
Le nombre des transactions effectuées et la somme des montants cumulés avec cette carte sur la période sont inférieurs aux limites acceptées | 0 |
*A : le nombre de transactions effectuées avec cette carte sur la période.
B : le nombre maximum de transactions acceptées avec une carte sur la période.
C : la somme des montants cumulés sur la période avec cette carte.
D : la somme maximum des montants cumulés acceptés avec une carte sur la période.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityCard.
Exemples :
Limites d'utilisation
Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.
Lors de la validation, l’annulation et le remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.
Encours par adresse IP
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre des transactions et/ou le montant cumulé des transactions) d’un client à partir d’une adresse IP sur une période.
La règle est exécutée sur toutes les transactions de paiement. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir d’une adresse IP sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
Exemple
Le tableau suivant décrit l'évolution de l'historique d'adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour la même IP, pour un montant total de 500 € et par mois (30 j) :
Date de la transaction | Détails du paiement | Résultat de la règle | Encours par adresse IP (nombre de
transactions) |
Encours par adresse IP (montant cumulé) |
État de l'historique (30 derniers jours) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Montant : 100 € IP :
105.24.68.102 |
OK | 1 | 100 € | TR1 01/10/2018 105.24.68.102 100 € |
07/10/2018 | Transaction TR2 Montant : 400 € IP :
254.24.78.175 |
OK | 1 | 400 € | TR1 01/10/2018 105.24.68.102 100 € OK TR2 07/10/2018
254.24.78.175 400 € |
10/10/2018 | Transaction TR3 Montant : 400 € IP :
254.24.78.175 |
KO | 2 | 800 € (> 500) |
TR1 01/10/2018 105.24.68.102 100 € OK TR2
07/10/2018 254.24.78.175 400 € OK TR3 10/10/2018
254.24.78.175 400 € |
12/10/2018 | Transaction TR4 Montant : 200 € IP :
105.24.68.102 |
OK | 2 | 300 € | TR1 01/10/2018 105.24.68.102 100 € OK TR2
07/10/2018 254.24.78.175 400 € OK TR3 10/10/2018
254.24.78.175 400 € KO TR4 12/10/2018 105.24.68.102
200 € |
15/10/2018 | Transaction TR5 Montant : 100 € IP :
105.24.68.102 |
KO | 3 (> 2) |
400 € | TR1 01/10/2018 105.24.68.102 100 € OK TR2
07/10/2018 254.24.78.175 400 € OK TR3 10/10/2018
254.24.78.175 400 € KO TR4 12/10/2018 105.24.68.102
200 € OK TR5 15/10/2018 105.24.68.102
100 € |
02/11/2018 (> 30j) |
Transaction TR6 Montant : 300 € IP :
105.24.68.102 |
OK | 1 | 300 € | TR6 02/11/2018 105.24.68.102 300 € |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Montant cumulé maximal | 0.01 sur la période en devise du commerçant | 9999999 |
Nombre maximal de transactions | 1 transaction sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cette adresse IP sur la période dépasse(nt) la/les limite(s) acceptée(s) | 0 à -4 selon paramétrage | VI;N;TRANS=A:B; CUMUL=C:D* |
NOT_APPLICABLE |
Le nombre des transactions effectuées et la somme des montants cumulés avec cette adresse IP sur la période sont inférieurs aux limites acceptées | 0 | TRANS=A:B; CUMUL=C:D* |
|
L'adresse IP n'est pas renseignée (en Sips Office) | 0 |
*A : le nombre de transactions effectuées avec cette adresse IP sur la période.
B : le nombre maximum de transactions acceptées avec une adresse IP sur la période.
C : la somme des montants cumulés sur la période avec cette adresse IP.
D : la somme maximum des montants cumulés acceptés avec une adresse IP sur la période.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityIp.
Exemples :
Limites d'utilisation
L'historique d'adresse IP n'est pas mis à jour lors des opérations de remboursement, d'annulation ou de validation, qu'elles soient partielles ou totales.
Encours par identifiant client
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre des transactions et/ou le montant cumulé des transactions) d’un client à partir de son identifiant client sur une période donnée.
La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’identifiant client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir d’un identifiant client sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période.
Exemple
Le tableau suivant décrit l'évolution de l'historique d'ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois maximum pour le même client, pour un montant maximum de 500 € et par mois (30 j) :
Date de la transaction | Détails du paiement | Résultat de la règle | Encours par client (nombre de
transactions) |
Encours par client (montant cumulé) |
État de l'historique (30 derniers jours) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Montant :
100 € CustomerID : cust1 |
OK | 1 | 100 € | TR1 01/10/2018 cust1 100 € |
07/10/2018 | Transaction TR2 Montant :
400 € CustomerID : cust2 |
OK | 1 | 400 € | TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018 cust2
400 € |
10/10/2018 | Transaction TR3 Montant :
400 € CustomerID : cust2 |
KO | 2 | 800 € (> 500) |
TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018 cust2
400 € OK TR3 10/10/2018 cust2
400 € |
12/10/2018 | Transaction TR4 Montant :
200 € CustomerID : cust1 |
OK | 2 | 300 € | TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018
cust2 400 € OK TR3 10/10/2018 cust2 400 €
KO TR4 12/10/2018 cust1 200 € |
15/10/2018 | Transaction TR5 Montant :
100 € CustomerID : cust1 |
KO | 3 (> 2) |
400 € | TR1 01/10/2018 cust1 100 € OK TR2 07/10/2018
cust2 400 € OK TR3 10/10/2018 cust2 400 €
KO TR4 12/10/2018 cust1 200 € OK TR5
15/10/2018 cust1 100 € |
02/11/2018 (> 30j) |
Transaction TR6 Montant :
300 € CustomerID : cust1 |
OK | 1 | 300 € | TR6 02/11/2018 cust1 300 € |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId).
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Montant cumulé maximal | 0.01 sur la période en devise du commerçant | 9999999 |
Nombre maximal de transactions | 1 transaction sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
L’identifiant client n’est pas fourni | 0 | VC;N;TRANS=A:B; CUMUL=C:D* |
NOT_APPLICABLE |
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cet identifiant client sur la période dépasse(nt) la/les limite(s) acceptée(s) | 0 à -4 selon paramétrage | TRANS=A:B; CUMUL=C:D* |
|
Le nombre des transactions effectuées et la somme des montants cumulés avec cet identifiant client sur la période sont inférieures aux limites acceptées | 0 |
*A : le nombre de transactions effectuées avec cet identifiant client sur la période.
B : le nombre maximum de transactions acceptées avec un identifiant client sur la période.
C : la somme des montants cumulés sur la période avec cet identifiant client.
D : la somme maximum des montants cumulés acceptés avec un identifiant client sur la période.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityCustomerId.
Exemples :
Limites d'utilisation
Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.
Lors de la validation, l’annulation et le remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.
Nombre de clients par carte
Description de la règle
Cette règle vous permet de vérifier qu’une carte donnée n’est pas utilisée par un nombre trop élevé de clients différents sur une période.
La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’identifiant client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir du numéro de carte et de l’identifiant du client sur une période donnée.
Exemple
Le tableau suivant décrit l'évolution de l'historique d'ID client/carte dans le cas où vous avez choisi de limiter les achats sur votre site à 3 clients par mois (30 j) avec la même carte :
Date de la transaction | Détails du paiement | Résultat de la règle | Clients/carte | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 CustomerID :
cust1 Carte : CB1 |
OK | 1 | TR1 01/10/2018 cust1 CB1 |
07/10/2018 | Transaction TR2 CustomerID :
cust2 Carte : CB2 |
OK | 2 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 |
12/10/2018 | Transaction TR3 CustomerID :
cust3 Carte : CB1 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 OK TR3 12/10/2018 cust3
CB1 |
20/10/2018 | Transaction TR4 CustomerID :
cust4 Carte : CB1 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 OK TR3 12/10/2018 cust3 CB1
OK TR4 20/10/2018 cust4 CB1 |
25/10/2018 | Transaction TR5 CustomerID :
cust4 Carte : CB2 |
OK | 1 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust2 CB1
OK TR3 12/10/2018 cust3 CB1 OK TR4 20/10/2018
cust4 CB1 KO TR5 25/10/2018 cust4 CB2 |
27/10/2018 | Transaction TR6 CustomerID :
cust1 Carte : CB1 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 OK TR3 12/10/2018 cust3 CB1
OK TR4 20/10/2018 cust4 CB1 KO TR5
25/10/2018 cust4 CB2 OK TR6 27/10/2018 cust1
CB1 |
02/03/2018 (> 30j) |
Transaction TR7 CustomerID :
cust5 Carte : CB1 |
OK | 1 | TR7 02/03/2018 cust5 CB1 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId).
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de clients | 1 client sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | MD;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre de clients différents utilisant la même carte sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | MD;N;MAX=A:B* | MAX=A:B* |
Le nombre de clients différents utilisant la même carte sur la période est inférieur à la limite acceptée | 0 | ||
L'identifiant client n'est pas renseigné | 0 |
*A : le nombre de clients ayant utilisé la même carte sur la période.
B : le nombre maximum de clients acceptés pour la même carte.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxCustomerIdPerCard.
Exemples :
Limites d'utilisation
L'historique CustomerID/Carte d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Nombre de cartes par client
Description de la règle
Cette règle vous permet de vérifier qu’un client donné n’utilise pas un nombre trop élevé de cartes différentes sur une période.
La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’identifiant client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir du numéro de carte et de l’identifiant du client sur une période donnée.
Exemple
Le tableau suivant décrit l'évolution de l'historique Cartes/ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 3 cartes par mois (30 j) pour un même client :
Date de la transaction | Détails du paiement | Résultat de la règle | Cartes/client | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 ID client :
cust1 Carte : CB1 |
OK | 1 | TR1 01/10/2018 cust1 CB1 |
07/10/2018 | Transaction TR2 ID client :
cust1 Carte : CB2 |
OK | 2 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 |
12/10/2018 | Transaction TR3 ID client :
cust1 Carte : CB3 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 OK TR3 12/10/2018 cust1
CB3 |
20/10/2018 | Transaction TR4 ID client : cust1
Carte : CB4 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 OK TR3 12/10/2018 cust1 CB3
OK TR4 20/10/2018 cust1 CB4 |
25/10/2018 | Transaction TR5 ID client :
cust2 Carte : CB4 |
OK | 1 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust1 CB2
OK TR3 12/10/2018 cust1 CB3 OK TR4 20/10/2018
cust1 CB4 KO TR5 25/10/2018 cust2
CB4 |
27/10/2018 | Transaction TR6 ID client :
cust1 Carte : CB1 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 OK TR3 12/10/2018 cust1 CB3
OK TR4 20/10/2018 cust1 CB4 KO TR5
25/10/2018 cust2 CB4 OK TR6 27/10/2018 cust1
CB1 |
02/03/2018 (> 30 j) |
Transaction TR7 ID client :
cust1 Carte : CB5 |
OK | 1 | TR7 02/03/2018 cust1 CB5 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du Merchant Extranet,
- et transmettre l’identifiant client de l’acheteur dans la requête (champ customerId).
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de cartes | 1 carte sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | MR;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre de cartes différentes utilisées par le même client sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | MR;N;MAX=A:B* | MAX=A:B* |
Le nombre de cartes différentes utilisées par le même client sur la période est inférieur à la limite acceptée | 0 | ||
L'identifiant client n'est pas renseigné | 0 |
*A : le nombre de cartes utilisées par le même client sur la période.
B : le nombre maximum de cartes acceptées pour le même client.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxCardPerCustomerId.
Exemples :
Limites d'utilisation
L'historique Cartes/CustomerID d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Nombre de cartes par adresse IP
Description de la règle
Cette règle vous permet de vérifier que des transactions en provenance d’une IP donnée n’utilisent pas un nombre trop élevé de cartes différentes sur une période.
La règle est exécutée sur toutes les transactions de paiement dans lesquelles l’adresse IP de client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir du numéro de carte et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
Exemple
Le tableau suivant décrit l'évolution de l'historique Cartes/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 cartes par mois (30 j), pour un même client :
Date de la transaction | Détails du paiement | Résultat de la règle | Cartes/IP | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP :
105.24.68.102 Carte : CB1 |
OK | 1 | TR1 01/10/2018 105.24.68.102 CB1 |
07/10/2018 | Transaction TR2 IP :
105.24.68.102 Carte : CB2 |
OK | 2 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 |
12/10/2018 | Transaction TR3 IP :
105.24.68.102 Carte : CB3 |
OK | 3 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 |
20/10/2018 | Transaction TR4 IP :
105.24.68.102 Carte : CB4 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102
CB4 |
25/10/2018 | Transaction TR5 IP :
254.24.78.175 Carte : CB4 |
OK | 1 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018
105.24.68.102 CB2 OK TR3 12/10/2018 105.24.68.102 CB3
OK TR4 20/10/2018 105.24.68.102 CB4 KO TR5
25/10/2018 254.24.78.175 CB4 |
27/10/2018 | Transaction TR6 IP :
105.24.68.102 Carte : CB1 |
OK | 3 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102
CB4 KO TR5 25/10/2018 254.24.78.175 CB4
OK TR6 27/10/2018 105.24.68.102 CB1 |
02/03/2018 (> 30 j) |
Transaction TR7 IP :
105.24.68.102 Carte : CB5 |
OK | 1 | TR7 02/03/2018 105.24.68.102 CB5 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre maximum de cartes et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de cartes | 1 carte sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas une carte) | 0 | CI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre de cartes différentes provenant de la même adresse IP sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | CI;N;MAX=A:B* | MAX=A:B* |
Le nombre de cartes différentes provenant de la même adresse IP sur la période est inférieur à la limite acceptée | 0 | ||
L’adresse IP n’est pas renseignée (en Sips Office) | 0 |
*A : le nombre de cartes utilisées par la même adresse IP sur la période.
B : le nombre maximum de cartes acceptées pour la même adresse IP.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxCardPerIp.
Exemples :
Limites d'utilisation
L'historique Cartes/adresse IP d’un client n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Nombre d'IBAN par adresse IP
Description de la règle
Cette règle vous permet de vérifier que des transactions en provenance d’une adresse IP donnée n’utilisent pas un nombre trop élevé d’IBAN différents sur une période.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
Exemple
Le tableau suivant décrit l'évolution de l'historique IBAN/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 IBAN par mois (30 j), pour une même adresse IP :
Date de la transaction | Détails du paiement | Résultat de la règle | IBAN/IP | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP :
105.24.68.102 IBAN : IBAN1 |
OK | 1 | TR1 01/10/2018 105.24.68.102 IBAN1 |
07/10/2018 | Transaction TR2 IP :
105.24.68.102 IBAN : IBAN2 |
OK | 2 | TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN2 |
12/10/2018 | Transaction TR3 IP :
105.24.68.102 IBAN : IBAN3 |
OK | 3 | TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN2 OK TR3 12/10/2018
105.24.68.102 IBAN3 |
20/10/2018 | Transaction TR4 IP :
105.24.68.102 IBAN : IBAN4 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN2 OK TR3 12/10/2018
105.24.68.102 IBAN3 OK TR4 20/10/2018
105.24.68.102 IBAN4 |
25/10/2018 | Transaction TR5 IP :
254.24.78.175 IBAN : IBAN4 |
OK | 1 | TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2 07/10/2018
105.24.68.102 IBAN2 OK TR3 12/10/2018 105.24.68.102
IBAN3 OK TR4 20/10/2018 105.24.68.102 IBAN4
KO TR5 25/10/2018 254.24.78.175
IBAN4 |
27/10/2018 | Transaction TR6 IP :
105.24.68.102 IBAN : IBAN1 |
OK | 3 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102
CB4 KO TR5 25/10/2018 254.24.78.175 CB4
OK TR6 27/10/2018 105.24.68.102 CB1 |
02/03/2018 (> 30 j) |
Transaction TR7 IP :
105.24.68.102 IBAN : IBAN5 |
OK | 1 | TR7 02/03/2018 105.24.68.102 IBAN5 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal d'IBAN | 1 IBAN sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | II;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre d’IBAN différents provenant de la même adresse IP sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | II;N;MAX=A:B* | MAX=A:B* |
L’adresse IP n’est pas renseignée (en Sips Office) | 0 | ||
Le nombre d’IBAN différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée | 0 |
*A : le nombre de d'IBAN utilisés par la même adresse IP sur la période.
B : le nombre maximum d'IBAN acceptés pour la même adresse IP.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxIbanPerIp.
Exemples :
Limites d'utilisation
L'historique IBAN/adresse IP n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Nombre d'adresses IP par IBAN
Description de la règle
Cette règle vous permet de vérifier qu’un IBAN n’est pas utilisé par un nombre trop élevé d’adresses IP différentes sur une période.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
Exemple
Le tableau suivant décrit l'évolution de l'historique adresse IP/IBAN dans le cas où vous avez choisi de limiter les achats sur votre site à 3 adresses IP par mois (30 j) pour un même IBAN :
Date de la transaction | Détails du paiement | Résultat de la règle | IP/IBAN | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP :
105.24.68.101 IBAN : IBAN1 |
OK | 1 | TR1 01/10/2018 105.24.68.101 IBAN1 |
07/10/2018 | Transaction TR2 IP :
105.24.68.102 IBAN : IBAN1 |
OK | 2 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 |
12/10/2018 | Transaction TR3 IP :
105.24.68.103 IBAN : IBAN1 |
OK | 3 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018
105.24.68.103 IBAN1 |
20/10/2018 | Transaction TR4 IP :
105.24.68.104 IBAN : IBAN1 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018
105.24.68.103 IBAN1 OK TR4 20/10/2018
105.24.68.104 IBAN1 |
25/10/2018 | Transaction TR5 IP :
105.24.68.104 IBAN : IBAN2 |
OK | 1 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2 07/10/2018
105.24.68.102 IBAN1 OK TR3 12/10/2018 105.24.68.103
IBAN1 OK TR4 20/10/2018 105.24.68.104 IBAN1
KO TR5 25/10/2018 105.24.68.104
IBAN2 |
27/10/2018 | Transaction TR6 IP :
105.24.68.101 IBAN : IBAN1 |
OK | 3 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018
105.24.68.103 IBAN1 OK TR4 20/10/2018 105.24.68.104
IBAN1 KO TR5 25/10/2018 105.24.68.104
IBAN2 TR6 27/10/2018 105.24.68.101
IBAN1 |
02/03/2018 (> 30 j) |
Transaction TR7 IP :
105.24.68.105 IBAN : IBAN1 |
OK | 1 | TR7 02/03/2018 105.24.68.105 IBAN1 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre maximum d'adresses IP et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l’acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal d'adresses IP | 1 adresse IP sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | IJ;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre d’adresses IP différentes avec le même IBAN sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | IJ;N;MAX=A:B* | MAX=A:B* |
L’adresse IP n’est pas renseignée (en Sips Office) | 0 | ||
Le nombre d’adresses IP différentes avec le même IBAN sur la période est inférieur à la limite acceptée | 0 |
*A : le nombre d'adresses IP utilisées par le même IBAN sur la période.
B : le nombre maximum d'adresses IP acceptées pour le même IBAN.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxIpPerIban.
Exemples :
Limites d'utilisation
L'historique adresse IP/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Nombre de clients par IBAN
Description de la règle
Cette règle vous permet de vérifier qu’un IBAN n’est pas utilisé par un nombre trop élevé de clients différents sur une période.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP du client et l’identifiant du client (customerId) est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir de l’IBAN et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
Exemple
Le tableau suivant décrit l'évolution de l'historique ID client/IBAN dans le cas où vous avez choisi de limiter les achats sur votre site à 3 clients par mois (30 j) avec le même IBAN :
Date de la transaction | Détails du paiement | Résultat de la règle | Clients/IBAN | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 ID client :
cust1 IBAN : IBAN1 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 |
07/10/2018 | Transaction TR2 ID client :
cust2 IBAN : IBAN1 |
OK | 2 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 |
12/10/2018 | Transaction TR3 ID client :
cust3 IBAN : IBAN1 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 OK TR3 12/10/2018 cust3
IBAN1 |
20/10/2018 | Transaction TR4 ID client :
cust4 IBAN : IBAN1 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1
OK TR4 20/10/2018 cust4 IBAN1 |
25/10/2018 | Transaction TR5 ID client :
cust4 IBAN : IBAN2 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust2
IBAN1 OK TR3 12/10/2018 cust3 IBAN1 OK TR4
20/10/2018 cust4 IBAN1 KO TR5 25/10/2018 cust4
IBAN2 |
27/10/2018 | Transaction TR6 ID client :
cust1 IBAN : IBAN1 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1
OK TR4 20/10/2018 cust4 IBAN1 KO TR5
25/10/2018 cust4 IBAN2 OK TR6 27/10/2018 cust1
IBAN1 |
02/03/2018 (> 30 j) |
Transaction TR7 ID client :
cust5 IBAN : IBAN1 |
OK | 1 | TR7 02/03/2018 cust5 IBAN1 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre maximum de clients et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’identifiant client dans la requête (champ customerId).
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de clients | 1 client sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | CJ;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre de clients différents utilisant le même IBAN sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | CJ;N;MAX=A:B* | MAX=A:B* |
L’identifiant client n’est pas renseigné | 0 | ||
Le nombre de clients différents utilisant le même IBAN sur la période est inférieur à la limite acceptée | 0 |
*A : le nombre de clients utilisant le même IBAN sur la période.
B : le nombre maximum de clients acceptés pour le même IBAN.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxCustidPerIban.
Exemples :
Limites d'utilisation
L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Nombre d'IBAN par client
Description de la règle
Cette règle vous permet de vérifier qu’un client n’utilise pas un nombre trop élevé d’IBAN différents sur une période.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’identifiant du client est transmis. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir de l’identifiant client (customerId) et de l’IBAN sur une période donnée.
Exemple
Le tableau suivant décrit l'évolution de l'historique IBAN/ID client dans le cas où vous avez choisi de limiter les achats sur votre site à 3 IBAN par mois (30 j) pour un client :
Date de la transaction | Détails du paiement | Résultat de la règle | IBAN/client | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 ID client :
cust1 IBAN : IBAN1 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 |
07/10/2018 | Transaction TR2 ID client :
cust1 IBAN : IBAN2 |
OK | 2 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 |
12/10/2018 | Transaction TR3 ID client :
cust1 IBAN : IBAN3 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 OK TR3 12/10/2018 cust1
IBAN3 |
20/10/2018 | Transaction TR4 ID client :
cust1 IBAN : IBAN4 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3
OK TR4 20/10/2018 cust1 IBAN4 |
25/10/2018 | Transaction TR5 ID client :
cust2 IBAN : IBAN4 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust1
IBAN2 OK TR3 12/10/2018 cust1 IBAN3 OK TR4
20/10/2018 cust1 IBAN4 KO TR5 25/10/2018 cust2
IBAN4 |
27/10/2018 | Transaction TR6 ID client :
cust1 IBAN : IBAN1 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3
OK TR4 20/10/2018 cust1 IBAN4 KO TR5
25/10/2018 cust2 IBAN4 OK TR6 27/10/2018 cust1
IBAN1 |
02/03/2018 (> 30 j) |
Transaction TR7 ID client :
cust1 IBAN : IBAN5 |
OK | 1 | TR7 02/03/2018 cust1 IBAN5 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer le nombre maximum d'IBAN et la durée du cumul via l’onglet fraude du Merchant Extranet
- et transmettre l’identifiant client dans la requête (champ customerId).
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal d'IBAN | 1 IBAN sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | IC;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre d’IBAN différents utilisés par le même client sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | IC;N;MAX=A:B* | MAX=A:B* |
L’identifiant client n’est pas renseigné | 0 | ||
Le nombre d’IBAN différents utilisés par le même client sur la période est inférieur à la limite acceptée | 0 |
*A : le nombre d'IBAN utilisés pour un même client sur la période.
B : le nombre maximum d'IBAN acceptés pour le même client.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxIbanPerCustid.
Exemples :
Limites d'utilisation
L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Nombre de mandats par adresse IP
Description de la règle
Cette règle vous permet de vérifier qu’une adresse IP n’utilise pas un nombre trop élevé de mandats SDD, désignés par leurs RUM (Référence Unique de Mandat), différents sur une période.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD et dans lesquelles l’adresse IP est transmise. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité à partir du mandat et de l’adresse IP du client sur une période donnée. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
Exemple
Le tableau suivant décrit l'évolution de l'historique mandat/adresse IP dans le cas où vous avez choisi de limiter les achats sur votre site à 3 mandats par mois (30 j) pour une adresse IP :
Date de la transaction | Détails du paiement | Résultat de la règle | Mandats/IP | État de l'historique (30 derniers jours) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP :
105.24.68.102 Mandat : RUM1 |
OK | 1 | TR1 01/10/2018 105.24.68.102 RUM1 |
07/10/2018 | Transaction TR2 IP :
105.24.68.102 Mandat : RUM2 |
OK | 2 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 |
12/10/2018 | Transaction TR3 IP :
105.24.68.102 Mandat : RUM3 |
OK | 3 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018
105.24.68.102 RUM3 |
20/10/2018 | Transaction TR4 IP :
105.24.68.102 Mandat : RUM4 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018
105.24.68.102 RUM3 OK TR4 20/10/2018
105.24.68.102 RUM4 |
25/10/2018 | Transaction TR5 IP :
254.24.78.175 Mandat : RUM4 |
OK | 1 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2 07/10/2018
105.24.68.102 RUM2 OK TR3 12/10/2018 105.24.68.102 RUM3
OK TR4 20/10/2018 105.24.68.102 RUM4 KO TR5
25/10/2018 254.24.78.175 RUM4 |
27/10/2018 | Transaction TR6 IP :
105.24.68.102 Mandat : RUM1 |
OK | 3 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018
105.24.68.102 RUM3 OK TR4 20/10/2018 105.24.68.102
RUM4 KO TR5 25/10/2018 254.24.78.175 RUM4
OK TR6 27/10/2018 105.24.68.102
RUM1 |
02/03/2018 (> 30 j) |
Transaction TR7 IP :
105.24.68.102 Mandat : RUM5 |
OK | 1 | TR7 02/03/2018 105.24.68.102 RUM5 |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet 'Fraude' du Merchant Extranet,
- paramétrer le nombre maximum de mandats et la durée du cumul également via l’onglet 'Fraude' du Merchant Extranet
- et transmettre l’adresse IP de l'acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Nombre maximal de mandats | 1 mandat sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | MJ;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre de mandats différents provenant de la même adresse IP sur la période dépasse la limite acceptée | 0 à -4 selon paramétrage | MJ;N;MAX=A:B* | MAX=A:B* |
L'adresse IP n’est pas renseignée | 0 | ||
Le nombre de mandats différents provenant de la même adresse IP sur la période est inférieur à la limite acceptée | 0 |
*A : le nombre de mandats utilisés pour une même adresse IP sur la période.
B : le nombre maximum de mandats acceptés pour la même adresse IP.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxMandatePerIp.
Exemples :
Limites d'utilisation
L'historique client/IBAN n'est pas mis à jour lors des opérations de remboursement, d'annulation, ou de validation, qu'elles soient partielles ou totales.
Encours par mandat
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant des transactions cumulé) du mandat SDD, désigné par son RUM (Référence Unique de Mandat), sur une période.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité d’un mandat sur une période donnée. Vous devez obligatoirement fournir le nombre des transactions et/ou le montant des transactions cumulé et la durée de la période lors du paramétrage du profil.
Exemple
Le tableau suivant décrit l'évolution de l'historique du mandat dans le cas où vous avez choisi de limiter les achats sur votre site à 3 fois pour un même mandat, pour un montant total de 500 € et par mois (30 j) :
Date de la transaction | Détails du paiement | Résultat de la règle | Encours par mandat (nombre de transactions) |
Encours par mandat (montant cumulé) |
État de l'historique (30 derniers jours) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Montant : 100 € Mandat : RUM1 |
OK | 1 | 100 € | TR1 01/10/2018 RUM1 100 € |
07/10/2018 | Transaction TR2 Montant : 400 € Mandat : RUM2 |
OK | 1 | 400 € | TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 € |
10/10/2018 | Transaction TR3 Montant : 400 € Mandat : RUM2 |
KO | 2 | 800 € (> 500) |
TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 € OK TR3 10/10/2018 RUM2 400 € |
12/10/2018 | Transaction TR4 Montant : 200 € Mandat : RUM1 |
OK | 2 | 300 € | TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 € OK TR3 10/10/2018 RUM2 400 € KO TR4 12/10/2018 RUM1 200 € |
15/10/2018 | Transaction TR5 Montant : 100 € Mandat : RUM1 |
KO | 3 (> 2) |
400 € | TR1 01/10/2018 RUM1 100 € OK TR2 07/10/2018 RUM2 400 € OK TR3 10/10/2018 RUM2 400 € KO TR4 12/10/2018 RUM1 200 € OK TR5 15/10/2018 RUM1 100 € |
02/11/2018 (> 30) |
Transaction TR6 Montant : 300 € Mandat : RUM1 |
OK | 1 | 300 € | TR6 02/11/2018 RUM1 300 € |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
- et paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Merchant Extranet
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Montant cumulé maximal | 0.01 sur la période en devise du commerçant | 9999999 |
Nombre maximal de transactions | 1 transaction sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | EM;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec ce mandat sur la période dépasse(nt) la/les limite(s) acceptée(s) | 0 à -4 selon paramétrage | EM;N;TRANS=A:B; CUMUL=C:D* |
TRANS=A:B; CUMUL=C:D* |
Le nombre des transactions effectuées et la somme des montants cumulés avec ce mandat sur la période sont inférieurs aux limites acceptées | 0 |
*A : le nombre de transactions effectuées avec ce mandat sur la période.
B : le nombre maximum de transactions acceptées avec un mandat sur la période.
C : la somme des montants cumulés sur la période avec ce mandat.
D : la somme maximum des montants cumulés acceptés avec un mandat sur la période.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityMandate.
Exemples :
Limites d'utilisation
Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.
Lors de la validation, de l’annulation et du remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.
Encours par IBAN
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat par le contrôle de l’activité (le nombre et/ou le montant cumulé des transactions) de l’IBAN sur une période.
La règle est exécutée sur toutes les transactions de paiement effectuées avec un moyen de paiement SDD. Le calcul de l’encours ne prend en compte que les transactions qui ont été acceptées au préalable sur la période.
La règle contrôle l’activité d’un IBAN sur une période donnée. Lors du paramétrage du profil, vous devez obligatoirement fournir le nombre des transactions et/ou le montant cumulé des transactions ainsi que la durée de la période.
Exemple
Le tableau suivant décrit l'évolution de l'historique du mandat dans le cas où vous avez choisi de limiter les achats sur votre site à 2 fois pour un même IBAN, pour un montant total de 500 € et par mois (30 j) :
Date de la transaction | Détails du paiement | Résultat de la règle | Encours par IBAN (nombre de transactions) |
Encours par IBAN (montant cumulé) |
État de l'historique (30 derniers jours) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Montant : 100 € IBAN : IBAN1 |
OK | 1 | 100 € | TR1 01/10/2018 IBAN1 100 € |
07/10/2018 | Transaction TR2 Montant : 400 € IBAN : IBAN2 |
OK | 1 | 400 € | TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 € |
10/10/2018 | Transaction TR3 Montant : 400 € IBAN : IBAN2 |
KO | 2 | 800 € (> 500) |
TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 € OK TR3 10/10/2018 IBAN2 400 € |
12/10/2018 | Transaction TR4 Montant : 200 € IBAN : IBAN1 |
OK | 2 | 300 € | TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 € OK TR3 10/10/2018 IBAN2 400 € KO TR4 12/10/2018 IBAN1 200 € |
15/10/2018 | Transaction TR5 Montant : 100 € IBAN : IBAN1 |
KO | 3 (> 2) |
400 € | TR1 01/10/2018 IBAN1 100 € OK TR2 07/10/2018 IBAN2 400 € OK TR3 10/10/2018 IBAN2 400 € KO TR4 12/10/2018 IBAN1 200 € OK TR5 15/10/2018 IBAN1 100 € |
02/11/2018 (> 30) |
Transaction TR6 Montant : 300 € IBAN : IBAN1 |
OK | 1 | 300 € | TR6 02/11/2018 IBAN1 300 € |
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
- et paramétrer le nombre de transactions effectuées et/ou le montant cumulé et la durée du cumul via l’onglet fraude du Merchant Extranet.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Période | En heures : 1 heure En jours : 1 jour En
semaines : 1 semaine |
En heures : 2376 heures En jours :
99 jours En semaines : 14 semaines |
Montant cumulé maximal | 0.01 sur la période en devise du commerçant | 9999999 |
Nombre maximal de transactions | 1 transaction sur la période | 9999 |
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter ce contrôle (moyen de paiement n’est pas SDD) | 0 | EI;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le nombre des transactions effectuées et/ou la somme des montants cumulés avec cet IBAN sur la période dépasse(nt) la/les limite(s) acceptée(s) | 0 à -4 selon paramétrage | EI;N;TRANS=A:B; CUMUL=C:D* |
TRANS=A:B; CUMUL=C:D* |
Le nombre des transactions effectuées et la somme des montants cumulés avec cet IBAN sur la période sont inférieurs aux limites acceptées | 0 |
*A : le nombre de transactions effectuées avec cet IBAN sur la période.
B : le nombre maximum de transactions acceptées avec un IBAN sur la période.
C : la somme des montants cumulés sur la période avec cet IBAN.
D : la somme maximum des montants cumulés acceptés avec un IBAN sur la période.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive VelocityIban.
Exemples :
Limites d'utilisation
Dans le cas d'un paiement en N fois, seule la première échéance est prise en compte.
Lors de la validation, de l’annulation et du remboursement de la transaction, le montant non validé, annulé ou remboursé n’est pas soustrait de l’encours.
Règles diverses
Réputations d'adresse IP
Description de la règle
Cette règle vous permet de décider de refuser ou non un achat provenant d’une adresse IP dont la réputation est dangereuse.
La règle va interroger la base de réputations d’adresses IP afin de connaître la réputation de l’adresse IP de l’acheteur et vérifier l’appartenance de cette réputation de l’adresse IP à la liste des réputations d’adresses IP indésirables que vous avez définie. Cette adresse IP provient :
- de la détection automatique via le navigateur de l’acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
En l’absence d’une liste de réputations d’IP indésirables, la règle retourne un résultat neutre.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer la liste des réputations d'adresse IP indésirables via l’onglet fraude du Merchant Extranet
- et transmettre l’adresse IP de l'acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Pour connaître les réputations d’adresses IP paramétrables, veuillez-vous référer à l’Annexe réputations d'adresse IP.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
L’information n’est pas connue | 0 | IR;N;U;IP_REP=XXX* | IP_REP=XXX* |
La réputation de l'adresse IP appartient à la liste des réputations d'adresse IP indésirables | 0 à -4 selon paramétrage | IR;N;Y;IP_REP=XXX* | |
La réputation de l'adresse IP n'appartient pas à la liste des réputations d'adresse IP indésirables | 0 | IR;N;N;IP_REP=XXX* |
* XXX : réputation d'adresse IP (voir Annexe réputations d’adresse IP)
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive IpReputations.
Exemples :
Carte en opposition
Description de la règle
Cette règle vous permet de décider de refuser ou non un achat provenant d’une carte en opposition.
La règle est exécutée sur toutes les transactions de paiement avec carte CB, Visa et MasterCard.
La règle vérifie si la carte est présente dans la base des cartes en opposition.
Le fichier des cartes en opposition est alimenté en se basant sur la liste des cartes de l'opposition du réseau CB. La mise à jour du fichier est effectuée plusieurs fois par jour.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | OP;N;NOT_APPLICABLE | NOT_APPLICABLE |
L’accès au serveur oppotota a échoué | 0 | OP;N;U | -- |
La carte est en opposition | 0 à -4 selon paramétrage | OP;N;Y | |
La carte n'est pas en opposition | 0 | OP;N;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive HotList.
Exemples :
Carte virtuelle
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation payée par un porteur de carte virtuelle émise par une banque Française.
La règle est exécutée sur toutes les transactions de paiement carte.
La règle vérifie dans la base de données de plages porteuses si la carte est une carte virtuelle.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | EC;N;NOT_APPLICABLE | NOT_APPLICABLE |
L'information n'est pas connue | 0 | EC;N;U | -- |
La carte est une carte virtuelle dynamique | 0 à -4 selon paramétrage | EC;N;Y | |
La carte n'est pas une carte virtuelle dynamique | 0 | EC;N;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive ECard.
Exemples :
Carte à autorisation systématique
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation payée par un porteur de carte à autorisation systématique.
La règle est exécutée sur toutes les transactions de paiement carte.
La règle vérifie dans la base de données de plages porteuses si la carte est une carte à autorisation systématique.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | SA;N;NOT_APPLICABLE | NOT_APPLICABLE |
L'information n'est pas connue | 0 | SA;N;U | -- |
La carte est une carte à autorisation systématique | 0 à -4 selon paramétrage | SA;N;Y | |
La carte n'est pas une carte à autorisation systématique | 0 | SA;N;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive SystematicAuthorizationCard.
Exemples :
Carte commerciale (et pays émetteur de la carte)
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en se basant sur le fait que la carte soit :
- une carte commerciale ;
- une carte commerciale appartenant à une liste de pays émetteurs autorisés ou interdits.
La règle est exécutée sur toutes les transactions de paiement avec une carte.
La règle va d’abord interroger une base de données des informations de cartes afin de vérifier l’appartenance de la carte à une plage de BIN correspond aux cartes commerciales afin de déterminer s’il s’agit d’une carte commerciale. Selon le contrôle demandé, le serveur vérifie si le pays d'émission de cette carte commerciale appartient à votre liste des pays é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.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer la liste des pays d’émission de la carte commerciale
autorisés ou interdits (si vous souhaitez intercepter les cartes
commerciales de certains pays). Pour cela, vous devez :
- paramétrer la liste via l’onglet fraude du Merchant Extranet,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CC;N;NOT_APPLICABLE | NOT_APPLICABLE |
L'information n'est pas connue | 0 | CC;N;U; CARD_COUNTRY=XXX |
CARD_COUNTRY=XXX* |
La carte est une carte commerciale, et la liste des pays de carte commerciale autorisés/interdits n’est pas définie | 0 à -4 selon paramétrage | CC;N;Y; CARD_COUNTRY=XXX* |
CARD_COUNTRY=XXX* |
Le pays de la carte est dans la liste des pays de carte commerciale interdits ou n'est pas dans la liste des pays de carte commerciale autorisés | 0 à -4 selon paramétrage | CC;N;Y; CARD_COUNTRY=XXX* |
|
Le pays de la carte n'est pas dans la liste des pays de carte commerciale interdits ou est dans la liste des pays carte commerciale autorisés | 0 | CC;N;N; CARD_COUNTRY=XXX* |
|
La carte n’est pas une carte commerciale | 0 | CC;N;N; CARD_COUNTRY=XXX* |
* XXX : code pays alphabétique ISO 3166 (cf.champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous pouvez envoyer, dans la requête de paiement, la liste de pays de la carte commerciale. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les 2 paramètres applicables à cette règle sont :
AllowedCommercialCardCountryList pour la liste des pays de carte commerciale autorisés ;
- DeniedCommercialCardCountryList pour la liste des pays de carte commerciale interdits.
Exemples :
<urn:fraudData>
<urn:riskManagementDynamicSettingList>
<urn:riskManagementDynamicSetting>
<urn:riskManagementDynamicParam>AllowedCommercialCardCountryList</urn:riskManagementDynamicParam>
<urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
</urn:riskManagementDynamicSetting>
</urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
"riskManagementDynamicSettingList":[
{
"riskManagementDynamicParam":"AllowedCommercialCardCountryList",
"riskManagementDynamicValue":"(FRA,BEL)"
}
]
}
Pour les 2 méthodes, la liste envoyée doit contenir :
- soit les codes pays au format des codes pays alphabétiques ISO 3166 (cf.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.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CorporateCard.
Exemples :
Plage de montants
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat par le contrôle du montant.
La règle va vérifier si le montant de la transaction se trouve dans la plage de montant que vous souhaitez.
En l’absence de paramétrage des limites minimum et maximum du montant, la règle retourne un résultat neutre.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- et paramétrer le montant minimum et/ou le montant maximum via l’onglet fraude du Merchant Extranet.
Paramètre | Valeur minimale | Valeur maximale |
---|---|---|
Montant minimum | 0.01 en devise du commerçant | 9999999 |
Montant maximum | 0.01 en devise du commerçant | 9999999 |
Restitution du résultat
Mode par défaut :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le montant de la transaction est hors de la plage des montants souhaités | 0 à -4 selon paramétrage | CA;N;MIN=A:B;MAX=A:C* | MIN=A:B;MAX=A:C* |
Le montant de la transaction est dans la plage des montants souhaités | 0 | CA;N;MIN=A:B;MAX=A:C* |
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le montant de la transaction est dans la plage des montants désavantagés | 0 à -4 selon paramétrage | CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=
A:C; POSITIVE_MIN= A:D; POSITIVE_MAX=A:E* |
NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D;POSITIVE_MAX=A:E |
Le montant de la transaction est hors des plages de montants avantagés et désavantagés | 0 | CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D; POSITIVE_MAX=A:E* |
|
Le montant de la transaction est dans la plage des montants avantagés | 0 à +4 selon paramétrage | CA;N;NEGATIVE_MIN=A:B; NEGATIVE_MAX=A:C; POSITIVE_MIN=A:D; POSITIVE_MAX=A:E* |
__________
* A : montant de la transaction.
B : montant minimum accepté.
C : montant maximum accepté.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CapCollerAmount.
Exemples :
Carte réseau CB
Description de la règle
Cette règle vous permet de décider de refuser ou non un achat provenant d’une carte du réseau CB.
La règle est exécutée sur toutes les transactions de paiement avec carte.
Elle vérifie dans la base des plages porteuses si la carte fait partie du réseau Carte Bancaire.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez paramétrer la règle via l’onglet fraude du Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | NC;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le BIN de la carte n’est pas connu | 0 | NC;N;U | -- |
La carte ne fait pas partie du réseau carte bancaire | 0 à -4 selon paramétrage | NC;N;Y | |
La carte fait partie du réseau carte bancaire | 0 | NC;N;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CBScheme.
Exemples :
Adresse e-mail gratuite
Description de la règle
Cette règle vous permet de mesurer le risque de la fraude d’un achat provenant d’un client dont l’adresse e-mail est gratuite.
La règle vérifie si l’adresse e-mail du client fait partie d’un domaine d’adresses e-mail gratuites.
Les adresses e-mail vérifiées sont :
- l’adresse e-mail du client ;
- l’adresse e-mail du porteur du moyen de paiement (il est possible que le client utilise le moyen de paiement d’un proche) ;
- l’adresse e-mail du contact de la facturation ;
- l’adresse e-mail du contact de la livraison.
Si une des adresses e-mail disponibles est présente dans la liste, un résultat négatif sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
- et transmettre au moins une adresse e-mail de l’acheteur dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Au moins une adresse e-mail est présente dans la liste des adresses e-mail gratuites | 0 à -4 selon paramétrage | FE;N;Y | -- |
Aucune adresse e-mail n’est présente dans la liste des adresses e-mail gratuites | 0 | FE;N;U | |
Aucune adresse e-mail n’a été transmise | 0 | FE;N;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive FreeEmail.
Exemples :
Authentification 3-D Secure
Description de la règle
Cette règle vous permet de mesurer le risque sur une transaction avec authentification 3-D Secure en fonction du statut de 3-D Secure. Ici, l’authentification 3-D Secure inclut les programmes d’authentification 3-D Secure de Visa, SecureCode de MasterCard, SafeKey d’American Express, authentification de Bancontact/Mister Cash, etc.
La règle est exécutée sur toutes les transactions de paiement carte avec une authentification 3-D Secure.
Elle vérifie si le statut d’authentification du porteur appartient à une liste de statuts refusés.
En l’absence de liste de statuts refusés, la règle retourne un résultat neutre.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
- et paramétrer la liste des statuts d’authentification 3-D Secure interdits via l’onglet fraude du Merchant Extranet.
Veuillez vous au champ holderAuthentStatus dans le dictionnaire des données.
Restitution du résultat
Mode par défaut (configuration simple) :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement ne propose pas d’authentification 3-D Secure ou vous ne participez pas au programme d’authentification 3-D Secure) | 0 | A3;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le statut 3-D Secure est interdit | 0 à -4 selon paramétrage | A3;N;Y | -- |
Le statut 3-D Secure n'est pas interdit | 0 | A3;N;N |
Mode de configuration avancée :
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement ne propose pas d’authentification 3-D Secure ou vous ne participez pas au programme d’authentification 3-D Secure) | 0 | A3;N;NOT_APPLICABLE | NOT_APPLICABLE |
Le statut 3-D Secure est dans la liste des statuts désavantagés | 0 à -4 selon paramétrage | A3;N;Y | -- |
Le statut 3-D Secure n'est pas dans les listes de statuts avantagés et désavantagés | 0 | A3;N;N | |
Le statut 3-D Secure est dans la liste des statuts avantagés | 0 à +4 selon paramétrage | A3;N;Y |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive 3DSStatus.
Exemples :
Syntaxe d'adresse e-mail
Description de la règle
Cette règle vous permet de mesurer le risque en fonction de la validité des syntaxes des adresses e-mail de la transaction.
La règle va vérifier si la syntaxe des adresses e-mail de la transaction est valide.
Les adresses e-mail vérifiées sont :
- l’adresse e-mail du client ;
- l’adresse e-mail du porteur du moyen de paiement (il est possible que le client utilise le moyen de paiement d’un proche) ;
- l’adresse e-mail du contact de la facturation ;
- l’adresse e-mail du contact de la livraison.
Si une des adresses e-mail présentées a une syntaxe incorrecte, la règle retourne un résultat négatif.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et transmettre au moins une adresse e-mail de l’acheteur dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
La syntaxe de l’adresse e-mail est erronée | 0 à -4 selon paramétrage | ES;N | -- |
La syntaxe de l’adresse e-mail est correcte | 0 | ||
Aucune adresse e-mail n’a été transmise | 0 |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive EmailSyntax.
Exemples :
Date d'expiration de la carte
Description de la règle
Cette règle vous permet de détecter les paiements dont la carte arrive à expiration dans les prochains mois. Elle est notamment utile dans le cadre d'un paiement en plusieurs fois afin de s’assurer que la carte sera toujours valide lors des prochaines échéances du paiement.
La règle est exécutée sur toutes les transactions carte.
Elle vérifie si le nombre de mois avant expiration de la carte est supérieur au nombre de mois que vous avez indiqués.
En l’absence de paramétrage du nombre de mois minimum avant expiration, la règle considère que ce nombre est de zéro.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et paramétrer le nombre minimum de mois avant expiration de la carte via l’onglet fraude du Merchant Extranet.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | PE;N;NOT_APPLICABLE | NOT_APPLICABLE |
La durée de validité du moyen de paiement est inférieure à la durée souhaitée | 0 à -4 selon paramétrage | PE;N;Y;EXPIRY=AAA:BBB* | EXPIRY=AAA:BBB* |
la durée de validité du moyen de paiement est supérieure à la durée souhaitée | 0 | PE;N;N;EXPIRY=AAA:BBB* |
* AAA : date d'expiration de la carte au format MMYY.
BBB : deadline pour le contrôle au format MMYY.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive ExpiryDate.
Exemples :
Carte commerciale (et pays d'émission de la carte)
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
- paramétrer la liste des pays d’émission de la carte commerciale
autorisés ou interdits (si vous souhaitez intercepter les cartes
commerciales de certains pays). Pour cela, vous devez :
- paramétrer la liste via l’onglet fraude du Merchant Extranet,
- ou surcharger dynamiquement la liste des pays autorisés ou interdits dans votre requête.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive CommercialCardIssuingCountry.
Exemples :
Description de la règle
Cette règle vous permet de décider de refuser ou non une prestation en se basant sur le fait que la carte soit :
- une carte commerciale ;
- une carte commerciale appartenant à une liste de pays 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.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | 0 | CC;N;NOT_APPLICABLE | NOT_APPLICABLE |
L'information n'est pas connue | 0 | CC;N;U; CARD_ISSUING_COUNTRY=XXX |
CARD_ISSUING_COUNTRY=XXX* |
La carte est une carte commerciale, et la liste des pays d'émission de la carte commerciale autorisés/interdits n’est pas définie | 0 à -4 selon paramétrage | CC;N;Y; CARD_ISSUING_COUNTRY=XXX* |
CARD_ISSUING_COUNTRY=XXX* |
Le pays d'émission de la carte est dans la liste des pays de carte commerciale interdits ou n'est pas dans la liste des pays de carte commerciale autorisés | 0 à -4 selon paramétrage | CC;N;Y; CARD_ISSUING_COUNTRY=XXX* |
|
Le pays d'émission de la carte n'est pas dans la liste des pays de carte commerciale interdits ou est dans la liste des pays carte commerciale autorisés | 0 | CC;N;N; CARD_ISSUING_COUNTRY=XXX* |
|
La carte n’est pas une carte commerciale | 0 | CC;N;N; CARD_ISSUING_COUNTRY=XXX* |
* XXX : code pays alphabétique ISO 3166 (cf.champ countryList dans le dictionnaire des données)
Surcharge dynamique
Vous pouvez envoyer, dans la requête de paiement, la liste de pays de la carte commerciale. Si une liste est transmise dans la requête, elle est prise en priorité par rapport au paramétrage éventuel, sauf si elle vient à l’encontre du paramétrage imposé par le distributeur.
Choisissez le paramètre à surcharger...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...et envoyez la liste des pays dans le champ suivant :
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
Les 2 paramètres applicables à cette règle sont :
AllowedCommercialCardIssuingCountryList pour la liste des pays de carte commerciale autorisés ;
- DeniedCommercialCardIssuingCountryList pour la liste des pays de carte commerciale interdits.
Exemples :
<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.
Règles de listes
Généralités
Le moteur de gestion de la lutte contre la fraude permet de gérer plusieurs listes de données. Trois types différents de règles peuvent être appliqués à ces listes :
- vérification dans une liste noire ;
- vérification dans une liste grise ;
- vérification dans une liste blanche.
La différence entre ces règles dépend du résultat de la règle ainsi que de la manière dont vous gérez la liste :
- une liste noire est une liste du type négatif utilisée pour des actions sévères, elle entraîne généralement un rejet des transactions ;
- une liste grise est une liste du type négatif utilisée pour des cas douteux nécessitant une attention particulière ;
- une liste blanche est une liste du type positif utilisée pour porter une attention spéciale et positive à certains clients.
Voici les résultats possibles en fonction du type de règle :
Valeur de donnée présente | Résultat liste noire (type NÉGATIF) |
Résultat liste grise (type NÉGATIF) |
Résultat liste blanche (type POSITIF) |
---|---|---|---|
NON | Neutre | Neutre | Neutre |
OUI | Négatif | Négatif | Positif |
D'une manière générale, les achats sur Internet présentent pour vous un risque de fraude plus élevé que lorsque la carte est présentée. Les commandes par téléphone/courrier/Internet sont des vecteurs majeurs de fraude si vous vendez et expédiez des produits. Si la carte n'est pas physiquement présente, vous devez compter sur le porteur de carte (ou quelqu'un qui affirme l'être) pour donner les informations de manière indirecte, que ce soit par courrier, téléphone ou Internet.
Il se peut que vous souhaitiez suivre les clients (ou des propriétés afférentes) avec lesquels vous avez eu une bonne ou une mauvaise expérience lors d'un précédent achat. Par exemple, si vous avez livré un produit à une adresse mais n'avez pas été réglé car la carte utilisée pour le paiement était frauduleuse, vous pouvez mettre ce numéro de carte en liste noire afin que la demande de paiement soit rejetée si cette carte est à nouveau utilisée sur votre boutique.
Autre exemple : vous pouvez ajouter un nom de client à une liste si vous pensez que ce client a des problèmes de solvabilité, par exemple si une tentative d'autorisation financière a été rejetée avec un code indiquant un « solde insuffisant » du compte. Dans ce cas, peut-être ne voulez-vous pas rejeter la transaction immédiatement mais être alerté si ce nom est utilisé à nouveau dans une transaction.
Vous pouvez aussi gérer ce nom dans ce que l'on appelle une liste grise. Vous pouvez ainsi recevoir une alerte si l'une des propriétés est utilisée de nouveau lors d'une transaction différente, et traiter la nouvelle transaction avec une attention particulière, effectuer une vérification manuelle, etc. Les listes grises sont également un moyen de gérer les propriétés (données transactionnelles) que l’on suppose liées à la fraude.
D'autre part, il se peut que vous ayez eu de mauvaises expériences avec certains clients, mais aussi des expériences très positives avec d'autres. Vous pouvez ainsi, par exemple, traiter certains clients comme des « VIP ». Les clients B2B peuvent également s'avérer suffisamment fiables. Les listes dites blanches représentent le moyen approprié de gérer ces clients.
Liste partagée
Par défaut, une boutique a sa propre liste pour chaque règle de type liste. Ces listes sont appelées « listes privées ».
Il est également possible de partager une liste pour plusieurs boutiques.
Une liste est partageable au niveau du groupe commercial.
5 listes partagées peuvent être créées par type de liste.
Toutes les boutiques attachées à cette liste partagée peuvent modifier les éléments de la liste.
L'élément ajouté par un utilisateur d’une boutique ne peut être modifié ou supprimé que par un utilisateur de cette boutique ou un administrateur, mais pas par les utilisateurs d’une autre boutique. Les éléments de la liste sont utilisés pour toutes les boutiques la partageant.
Pour mettre en place une liste partagée, vous devez contacter votre gestionnaire de compte pour la configuration. Cette dernière s’effectue en deux étapes :
- tout d'abord créer une liste commune en choisissant son type (liste d’adresses e-mail, liste de numéros de carte, etc.) et sa couleur (noir, gris ou blanc) ;
- puis associer la liste partagée aux boutiques.
Lors de l'exécution des contrôles antifraudes, si la règle appropriée est activée, la liste partagée sera appliquée à la place de la liste privée par défaut.
Adresses e-mail
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat lié à une adresse e-mail qui appartient à la liste noire ou grise des adresses e-mail.
- et/ou de décider d'honorer ou non un achat lié à une adresse e-mail qui appartient à la liste blanche des adresses e-mail sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des adresses e-mail VIP.
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins une adresse e-mail transmise par vos soins.
La règle va vérifier l’appartenance de toutes les adresses e-mail disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les adresses e-mail vérifiées sont :
- l'adresse e-mail du client ;
- l’adresse e-mail du porteur du moyen de paiement (il est possible que le client/acheteur utilise le moyen de paiement d’un proche) ;
- l’adresse e-mail du contact de la facturation ;
- l’adresse e-mail du contact de la livraison.
Si une des adresses e-mail disponibles est présente dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
paramétrer la liste noire, grise et/ou blanche des adresses e-mail ;
- et transmettre une ou plusieurs adresses e-mail précédemment citées dans la requête (champs billingContact.email, customerContact.email, deliveryContact.email, holderContact.email).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Au moins une adresse e-mail fait partie de la liste | Noire | 0 à -4 selon paramétrage | BM;N;Y | -- |
Grise | GM;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WM;P;Y | ||
Aucune adresse e-mail ne fait partie de la liste | Noire | 0 | BM;N;N | |
Grise | GM;N;N | |||
Blanche | WM;P;N | |||
Aucune adresse e-mail n’a été transmise | Noire | BM;N;U | ||
Grise | GM;N;N | |||
Blanche | WM;P;U |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackEmail (liste noire), GreyEmail (liste grise) et/ou WhiteEmail (liste blanche).
Exemple pour une liste blanche :
Adresses IP
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat lié à une adresse IP qui appartient à la liste noire ou grise des adresses IP.
- et/ou de décider d'honorer ou non un achat lié à une adresse IP qui appartient à la liste blanche des adresses IP, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des adresses IP VIP.
La règle va vérifier l’appartenance de l'adresse IP à la liste noire, grise et/ou blanche que vous avez définie(s). Cette adresse IP provient :
- de la détection automatique via le navigateur de l'acheteur en Sips Paypage ;
- ou du transfert que vous effectuez dans la requête en Sips Office.
Si l'adresse IP est présente dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
paramétrer la liste noire, grise et/ou blanche des adresses IP ;
- et transmettre l'adresse IP de l'acheteur dans la requête (champ customerIpAddress), si vous êtes sur Sips Office.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
L’adresse IP n’est pas renseignée (en Sips Office) | Noire | 0 | BY;N;U | -- |
Grise | GY;N;U | |||
Blanche | WY;P;U | |||
L’adresse IP appartient à la liste | Noire | 0 à -4 selon paramétrage | BY;N;Y | |
Grise | GY;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WY;P;Y | ||
L’adresse IP n’appartient pas à la liste | Noire | 0 | BY;N;N | |
Grise | GY;N;N | |||
Blanche | WY;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackIp (liste noire), GreyIp (liste grise) et/ou WhiteIp (liste blanche).
Exemple pour une liste blanche :
Codes postaux par pays
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat lié à un code postal qui appartient à la liste noire ou grise des codes postaux par pays.
- et/ou de décider d'honorer ou non un achat lié à un code postal qui appartient à la liste blanche des codes postaux, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des codes postaux VIP.
Si la règle est présente dans votre profil, elle sera effectuée sur toutes les transactions de paiement avec au moins un code postal transmis par vos soins.
La règle va vérifier l’appartenance de tous les codes postaux disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les codes postaux vérifiés sont :
- le code postal du contact de la facturation ;
- le code postal du contact de la livraison.
Si un des codes postaux disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
paramétrer la liste noire, grise et/ou blanche des codes postaux ;
- et transmettre un ou plusieurs codes postaux ci-dessus dans la requête (champs billingAddress.zipCode, deliveryAddress.zipCode).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Aucun code postal n'a été transmis | Noire | 0 | BZ;N;U | -- |
Grise | GZ;N;U | |||
Blanche | WZ;P;U | |||
Au moins un code postal fait partie de la liste | Noire | 0 à -4 selon paramétrage | BZ;N;Y | |
Grise | GZ;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WZ;P;Y | ||
Aucun code postal ne fait partie de la liste | Noire | 0 | BZ;N;N | |
Grise | GZ;N;N | |||
Blanche | WZ;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackPostalCode (liste noire), GreyPostalCode (liste grise) et/ou WhitePostalCode (liste blanche).
Exemple pour une liste blanche :
Identifiants clients
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat lié à un identifiant client qui appartient à la liste noire ou grise des identifiants clients.
- et/ou de décider d'honorer ou non un achat lié à un identifiant client qui appartient à la liste blanche identifiants clients, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des identifiants clients VIP.
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec un identifiant client soumis dans la requête/transmis par vos soins.
La règle va vérifier l’appartenance de l'identifiant client à la liste noire, grise et/ou blanche des identifiants clients que vous avez définie(s).
Si l'identifiant client est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
paramétrer la liste noire, grise et/ou blanche des identifiants clients ;
- et transmettre l'identifiant client de l'acheteur dans la requête (champ customerId).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
L’identifiant client n’est pas fourni | Noire | 0 | BI;N;U | -- |
Grise | GI;N;U | |||
Blanche | WI;P;U | |||
Au moins un identifiant client fait partie de la liste | Noire | 0 à -4 selon paramétrage | BI;N;Y | |
Grise | GI;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WI;P;Y | ||
L’identifiant client ne fait pas partie de la liste | Noire | 0 | BI;N;N | |
Grise | GI;N;N | |||
Blanche | WI;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackCustomerId (liste noire), GreyCustomerId (liste grise) et/ou WhiteCustomerId (liste blanche).
Exemple pour une liste blanche :
Noms de clients
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat lié à un nom de client qui appartient à la liste noire ou grise des noms de clients.
- et/ou de décider d'honorer ou non un achat lié à un nom de client qui appartient à la liste blanche des noms de clients, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des noms de clients VIP.
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins un nom de client transmis par vos soins.
La règle va vérifier l’appartenance de tous les noms disponibles à la liste noire, grise et/ou blanche des noms de clients que vous avez définie(s). Les noms vérifiés sont :
- le nom du client ;
- le nom du porteur du moyen de paiement (il est possible que le client/acheteur utilise le moyen de paiement d'un proche) ;
- le nom du contact de la facturation ;
- le nom du contact de la livraison.
Si un des noms disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
paramétrer la liste noire, grise et/ou blanche des noms de clients ;
- et transmettre au moins un nom de client dans la requête (champs billingContact.lastName, customerContact.lastName, deliveryContact.lastName, holderContact.lastName).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Aucun nom de client n'a été transmis | Noire | 0 | BN;N;U | -- |
Grise | GN;N;U | |||
Blanche | WN;P;U | |||
Au moins un nom de client fait partie de la liste | Noire | 0 à -4 selon paramétrage | BN;N;Y | |
Grise | GN;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WN;P;Y | ||
Aucun nom de client ne fait partie de la liste | Noire | 0 | BN;N;N | |
Grise | GN;N;N | |||
Blanche | WN;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackCustomerName (liste noire), GreyCustomerName (liste grise) et/ou WhiteCustomerName (liste blanche).
Exemple pour une liste blanche :
Numéros de carte
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat provenant d'une carte qui appartient à votre liste noire ou grise.
- et/ou de décider d'honorer ou non directement un achat provenant d'une carte qui appartient à votre liste blanche, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste de cartes VIP.
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement par carte transmises par vos soins.
La règle va vérifier l’appartenance du numéro de carte soumis pour autorisation (si applicable) à la liste noire, grise et/ou blanche de vos numéros de carte.
Si le numéro de carte en question est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche des numéros de carte (cardNumber).
La liste peut être paramétrée :
- via l’onglet 'Fraude' et Sips Office Extranet. Les données doivent être ajoutées par le biais d'un identifiant de la transaction. Dans ce dernier cas, la valeur de la donnée stockée pour la transaction liée à l’identifiant de la transaction sera ajoutée à la liste ;
- et par le batch d’alimentation de Sips Office Batch.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | Noire | 0 | BC;N;U | -- |
Grise | GC;N;U | |||
Blanche | WC;P;U | |||
Le numéro de la carte fait partie de la liste | Noire | 0 à -4 selon paramétrage | BC;N;Y | |
Grise | GC;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WC;P;Y | ||
Le numéro de la carte ne fait pas partie de la liste | Noire | 0 | BC;N;N | |
Grise | GC;N;N | |||
Blanche | WC;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackCard (liste noire), GreyCard (liste grise) et/ou WhiteCard (liste blanche).
Exemple pour une liste blanche :
Numéros de téléphone
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat lié à un numéro de téléphone qui appartient à la liste noire ou grise des numéros de téléphone.
- et/ou de décider d'honorer ou non un achat lié à un numéro de téléphone qui appartient à la liste blanche des numéros de téléphone, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste des numéros de téléphone VIP.
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement avec au moins un numéro de téléphone transmis par vos soins.
La règle va vérifier l’appartenance de tous les numéros de téléphone disponibles à la liste noire, grise et/ou blanche que vous avez définie(s). Les numéros de téléphone vérifiés sont :
- les numéros de téléphone fixe/portable du client ;
- les numéros de téléphone fixe/portable du porteur du moyen de paiement (en effet, il est possible que le client/acheteur utilise le moyen de paiement d’un proche) ;
- les numéros de téléphone fixe/portable du contact de la facturation ;
- les numéros de téléphone fixe/portable du contact de la livraison.
Si un des numéros de téléphone disponibles est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet,
paramétrer la liste noire, grise et/ou blanche des numéros de téléphone ;
- et transmettre dans la requête un ou plusieurs des numéros de téléphone énumérés ci-dessus (champs billingContact.phone, customerContact.phone, deliveryContact.phone, holderContact.phone, billingContact.mobile, customerContact.mobile, deliveryContact.mobile, holderContact.mobile).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Aucun numéro de téléphone n’a été transmis | Noire | 0 | BP;N;U | -- |
Grise | GP;N;U | |||
Blanche | WP;P;U | |||
Au moins un numéro de téléphone fait partie de la liste | Noire | 0 à -4 selon paramétrage | BP;N;Y | |
Grise | GP;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WP;P;Y | ||
Aucun numéro de téléphone ne fait partie de la liste | Noire | 0 | BP;N;N | |
Grise | GP;N;N | |||
Blanche | WP;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackPhoneNumber (liste noire), GreyPhoneNumber (liste grise) et/ou WhitePhoneNumber (liste blanche).
Exemple pour une liste blanche :
Plages de BIN
Description de la règle
Cette règle vous permet :
- de décider de refuser ou non un achat effectué avec une carte dont le BIN appartient à votre liste noire ou grise de BIN.
- et/ou de décider d'honorer ou non directement un achat effectué avec une carte dont le BIN appartient à votre liste blanche de BIN, sans avoir à exécuter les autres règles décisives, ce qui vous permet de définir une liste de plages de BIN VIP.
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement par carte transmises par vos soins.
La règle va vérifier l’appartenance du numéro de BIN de la carte à votre liste noire, grise et/ou blanche de plages de BIN.
Si le numéro BIN de la carte en question est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche des numéros de BIN (cardNumber).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Impossible d'exécuter cette règle (le moyen de paiement n’est pas une carte) | Noire | 0 | BB;N;U | -- |
Grise | BR;N;U | |||
Blanche | WB;P;U | |||
Le numéro de BIN de la carte fait partie de la liste | Noire | 0 à -4 selon paramétrage | BB;N;Y | |
Grise | BR;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WB;P;Y | ||
Le numéro de BIN de la carte ne fait pas partie de de la liste | Noire | 0 | BB;N;N | |
Grise | BR;N;N | |||
Blanche | WB;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackBinCard (liste noire), GreyBinCard (liste grise) et/ou WhiteBinCard (liste blanche).
Exemple pour une liste blanche :
BIC (Bank Identifier Code)
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat lié à un BIC (Bank Identifier Code) qui appartient à la liste noire, grise et/ou blanche de BIC, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste de BIC VIP).
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.
La règle va vérifier l’appartenance du BIC à la liste noire, grise et/ou blanche de BIC que vous avez définie(s).
Si le BIC est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche de BIC.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Le BIC fait partie de la liste | Noire | 0 à -4 selon paramétrage | BE;N;Y | -- |
Grise | GM;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WE;P;Y | ||
Le BIC ne fait pas partie de la liste | Noire | 0 | BE;N;N | |
Grise | GM;N;N | |||
Blanche | WE;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackBic (liste noire), GreyBic (liste grise) et/ou WhiteBic (liste blanche).
Exemple pour une liste blanche :
IBAN (International Bank Account Number)
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat lié à un IBAN (International Bank Account Number) qui appartient à la liste noire, grise et/ou blanche d'IBAN, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste d'IBAN VIP).
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.
La règle va vérifier l’appartenance de l'IBAN utilisé par le mandat SDD à la liste noire, grise et/ou blanche d'IBAN que vous avez définie(s).
Si l'IBAN est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche d'IBAN.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
L'IBAN fait partie de la liste | Noire | 0 à -4 selon paramétrage | BA;N;Y | -- |
Grise | GA;N;Y | |||
Blanche | 0 à +4 selon paramétrage | WA;P;Y | ||
L'IBAN ne fait pas partie de la liste | Noire | 0 | BA;N;N | |
Grise | GA;N;N | |||
Blanche | WA;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackIban (liste noire), GreyIban (liste grise) et/ou WhiteIban (liste blanche).
Exemple pour une liste blanche :
Mandats
Description de la règle
Cette règle vous permet de mesurer le risque sur un achat lié à un mandat SDD qui appartient à la liste noire, grise et/ou blanche de mandats, sans avoir à exécuter les autres règles décisives dans le cas d'une liste blanche (ce qui vous permet de définir une liste de mandats VIP).
Si la règle est présente dans votre profil, elle sera appliquée sur toutes les transactions de paiement réalisées avec le moyen de paiement SDD.
La règle va vérifier l’appartenance du mandat, basé sur son RUM (Référence Unique de Mandat), à la liste noire, grise et/ou blanche de mandats que vous avez définie(s).
Si le mandat est présent dans une liste, un résultat négatif (listes noire et grise) et/ou positif (liste blanche) sera retourné.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez, pour chaque liste :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
et paramétrer la liste noire, grise et/ou blanche de mandats.
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo | |
---|---|---|---|---|
Le RUM du mandat fait partie de la liste | Noire | 0 à -4 selon paramétrage | TB;N;Y | -- |
Grise | TG;N;Y | |||
Blanche | 0 à +4 selon paramétrage | TW;P;Y | ||
Le RUM du mandat ne fait pas partie de la liste | Noire | 0 | TB;N;N | |
Grise | TG;N;N | |||
Blanche | TW;P;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive BlackMandate (liste noire), GreyMandate (liste grise) et/ou WhiteMandate (liste blanche).
Exemple pour une liste blanche :
Règles de panier
Généralités
Le moteur de gestion de la lutte contre la fraude permet de prendre en compte la composition du panier de la transaction pour en mesurer le risque. Pour ce faire, il utilise des listes de produits à risque que vous définissez vous-même.
Un produit à risque est un produit que vous vendez et considèrez comme potentiellement associé à des transactions à risque selon certains critères qui vous appartiennent : catégorie ou type de produit, prix du produit, utilisation régulière d’un produit dans des transactions frauduleuses, etc.
Vous avez la possibilité de définir jusqu’à 3 listes de produits à risque pour votre boutique. Vous pouvez ainsi ajouter tout ou partie des produits que vous vendez dans une ou plusieurs listes selon le niveau de risque du produit.
Par exemple, vous pouvez choisir de créer les 3 listes de produits à risques suivantes :
- une liste de produits à faible risque ;
- une liste de produits à risque modéré ;
- et une liste de produits à haut risque.
Les listes de produits à risque sont exploitées par des règles de détection de risque du contenu du panier du client qui effectue un achat sur votre site. Si ces règles sont activées, elles vont analyser le contenu du panier et le comparer aux listes de produits à risque que vous avez définies afin d'évaluer le risque de la transaction. Vous pouvez ainsi limiter l‘achat de certains produits à une certaine quantité ou un certain ratio du montant global.
Listes partagées
Par défaut, une boutique possède ses propres listes de produits à risque (jusqu'à 3 listes). Ces listes sont appelées « listes privées ».
Vous pouvez également réaliser des listes communes à plusieurs boutiques afin de n’administrer qu’un seul jeu de produits à risque pour les boutiques concernées. Ce sont des listes dites « partagées ».
Une liste est partageable au niveau du groupe commercial. Vous pouvez créer et associer aux boutiques 5 listes partagées de produits à risque. Toutes les boutiques associées à une liste partagée donnée peuvent modifier les éléments de la liste. Les éléments de la liste sont utilisés pour toutes les boutiques la partageant.
Pour mettre en place une liste partagée, vous devez contacter votre gestionnaire de compte pour la configuration. Cette dernière s’effectue en deux étapes :
- tout d'abord créer une liste commune en choisissant son type (liste d’adresses e-mail, liste de numéros de carte, etc.) et sa couleur (noir, gris ou blanc) ;
- puis associer la liste partagée aux boutiques.
L’association d’une boutique à une liste partagée se fait en utilisant une liste partagée existante au niveau du groupe commercial, dans l’écran de configuration des listes de produits de la boutique.
Lors de l'exécution des contrôles antifraudes, si la règle appropriée est activée et qu’elle est paramétrée pour utiliser la liste partagée, alors cette dernière sera utilisée.
Liste de produits à risque
Description de la règle
Cette règle vous permet de vérifier la présence ou non de produits à risque dans le panier du client.
La règle va interroger les listes de produits à risque définies par vos soins et paramétrées dans la règle afin de vérifier si l’un des produits du panier du client contient un produit que vous considérez comme potentiellement risqué.
Si la requête que vous envoyez ne contient pas de liste de produits à risque pour la boutique ou de contenu du panier, la règle retourne un résultat neutre.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du Merchant Extranet,
paramétrer au moins une liste de produits à risque via l’onglet fraude du Merchant Extranet
- et transmettre le contenu du panier du client dans la requête, notamment le code produit de chaque produit du panier (champ ShoppingCartDetail).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | Rule DetailedInfo |
---|---|---|---|
Au moins un produit du panier appartient à une liste de produits à risque | 0 à -3 selon paramétrage | RP;N;Y | -- |
L'information n'est pas connue | 0 | RP;N;U; | |
Aucun produit du panier n’appartient à une liste de produits à risque | 0 | RP;N;N |
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive RiskyProductList.
Exemples :
Quantité de produits à risque
Description de la règle
Cette règle vous permet de limiter dans le panier la quantité de produits appartenant à l’une de vos listes de produits à risque.
La règle va analyser le contenu du panier et vérifier que :
- la quantité d’un même produit du panier du client appartenant à l’une de vos listes de produits à risque n’excède pas le seuil paramétré dans la règle ;
- la quantité totale de tous les produits du panier du client appartenant à une même liste de produits à risque n’excède pas le seuil paramétré dans la règle.
Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du Merchant Extranet,
paramétrer au moins une liste de produits à risque via l’onglet fraude du Merchant Extranet
- et transmettre le contenu du panier du client dans la requête, notamment le code produit et la quantité de chaque produit du panier (champ ShoppingCartDetail).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Au moins un produit du panier appartenant à une liste de
produits à risque a une quantité supérieure au seuil paramétré
dans la règle et/ou la quantité totale des produits
appartenant à une liste de produits à risque est supérieure au
seuil paramétré dans la règle. |
0 à -4 selon paramétrage | PQ;N;Y; MAX_QUANTITY_PER_ RISKY_PRODUCT=L:A:B; MAX_QUANTITY_PER_ LIST=L:C:D* |
MAX_QUANTITY _PER_RISKY
_PRODUCT=L:A:B; MAX_QUANTITY_PER_ LIST=L:C:D* |
L'information n'est pas connue | 0 | PQ;N;U | -- |
Aucun produit du panier n’appartient à une liste de
produits à risque ou aucun produit du panier
appartenant à une liste de produits à risque n’a une quantité
supérieure au seuil paramétré dans la règle et la quantité totale
des produits appartenant à une liste de produits à risque est
inférieure ou égale au seuil paramétré dans la
règle. |
0 | PQ;N;N; MAX_QUANTITY_PER_ RISKY_PRODUCT=L:A:B;MAX_QUANTITY_PER_ LIST=L:C:D* |
MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY
_PER_LIST=L:C:D* |
*L : le nom de la liste de produits à risque concernée.
A : la quantité la plus grande d’un produit du panier appartenant à cette liste de produits à risque.
B : la quantité maximum acceptée pour un produit appartenant à cette liste de produits à risque.
C : la somme des quantités des produits du panier appartenant à cette liste de produits à risque.
D : la quantité maximum acceptée pour tous les produits du panier appartenant à cette liste de produits à risque.
MAX_QUANTITY_PER_RISKY_PRODUCT=L1:A1:B1;MAX_QUANTITY_PER_LIST=L1:C1:D1; MAX_QUANTITY_PER_RISKY_PRODUCT=L2:A2:B2;MAX_QUANTITY_PER_LIST=L2:C2:D2; MAX_QUANTITY_PER_RISKY_PRODUCT=L3:A3:B3;MAX_QUANTITY_PER_LIST=L3:C3:D3
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive RiskyProductQuantity.
Exemples :
Ratio de produits à risque
Description de la règle
Cette règle vous permet de détecter un comportement anormal relatif au ratio entre le montant d’un ou de tous les produits appartenant à une liste de produits à risque et le montant total du panier du client.
La règle va analyser le contenu du panier et vérifier que :
- le ratio entre le montant total (quantité x prix unitaire) d’un même produit du panier appartenant à une liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle ;
- le ratio entre le montant total (quantité x prix unitaire) de tous les produits du panier appartenant à une même liste de produits à risque et le montant total du panier n’excède pas le seuil paramétré dans la règle.
Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil et choisir la liste à utiliser via l’onglet fraude du Merchant Extranet,
paramétrer au moins une liste de produits à risque via l’onglet fraude du Merchant Extranet
- et transmettre le contenu du panier du client dans la requête, notamment le code produit, le montant unitaire et la quantité de chaque produit du panier (champ ShoppingCartDetail).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Le plus grand ratio entre le montant total pour au moins un
produit appartenant à une liste de produits à risque et le montant
total du panier est supérieur au seuil paramétré dans la
règle et/ou le ratio entre le montant total de tous les
produits appartenant à une liste de produits à risque et le
montant total du panier est supérieur au seuil paramétré dans la
règle |
0 à -4 selon paramétrage | PQ;N;Y; MAX_RATIO_PER_ RISKY_PRODUCT=L:A:B;MAX_RATIO_PER_ LIST=L:C:D* |
MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D* |
L'information n'est pas connue | 0 | PQ;N;U | -- |
Aucun produit du panier n’appartient à une liste de
produits à risque ou Le ratio entre le montant total pour un
produit appartenant à une liste de produits à risque et le montant
total du panier n’excède pas le seuil paramétré dans la règle et
le ratio entre le montant total de tous les produits appartenant à
cette liste de produits à risque et le montant total du panier
n’excède pas le seuil paramétré dans la règle |
0 | PQ;N;N; MAX_RATIO_PER_ RISKY_PRODUCT=L:A:B;MAX_RATIO_PER_ LIST=L:C:D* |
MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D* |
*L : le nom de la liste de produits à risque concernée.
A : le plus grand ratio entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.
B : le ratio maximum accepté entre le montant total pour un produit appartenant à cette liste de produits à risque et le montant total du panier.
C : le plus grand ratio entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.
D : le ratio maximum accepté entre le montant total de tous les produits appartenant à cette liste de produits à risque et le montant total du panier.
MAX_RATIO_PER_RISKY_PRODUCT=L1:A1:B1;MAX_RATIO_PER_LIST=L1:C1:D1; MAX_RATIO_PER_RISKY_PRODUCT=L2:A2:B2;MAX_RATIO_PER_LIST=L2:C2:D2; MAX_RATIO_PER_RISKY_PRODUCT=L3:A3:B3;MAX_RATIO_PER_LIST=L3:C3:D3
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive RiskyProductRatio.
Exemples :
Quantité de produits
Description de la règle
Cette règle vous permet de limiter la quantité d’un même produit dans le panier d’un client.
La règle va analyser le contenu du panier et vérifier que la quantité de chaque produit n’excède pas le seuil que vous avez paramétré dans la règle. Cette règle n’utilise pas de listes de produits à risque.
Si la requête que vous envoyez ne contient pas de contenu du panier, la règle retourne un résultat neutre.
Conditions d'utilisation
Si vous désirez opter pour cette règle, vous devez :
- activer la règle dans le profil via l’onglet fraude du Merchant Extranet
- et transmettre le contenu du panier du client dans la requête, notamment le code produit et la quantité de chaque produit du panier (champ ShoppingCartDetail).
Restitution du résultat
Cas d'utilisation | ScoreValue | ScoreInfo | RuleDetailedInfo |
---|---|---|---|
Au moins un produit du panier a une quantité supérieure au seuil paramétré dans la règle | 0 à -4 selon paramétrage | QP;N;Y; PRODUCTQUANTITY=A:B* |
PRODUCTQUANTITY =A:B* |
L'information n'est pas connue | 0 | QP;N;U; PRODUCTQUANTITY=XXX:B* |
PRODUCTQUANTITY =XXX:B* |
Aucun produit du panier n’a une quantité supérieure au seuil paramétré dans la règle | 0 | QP;N;N; PRODUCTQUANTITY=A:B* |
PRODUCTQUANTITY =A:B* |
* A : la quantité du premier produit trouvé dont la quantité est supérieure au seuil défini dans la règle.
B : la quantité maximum de chaque produit acceptée dans le panier.
Surcharge dynamique
La surcharge dynamique de cette règle n'est pas disponible.
Débrayage dynamique
Vous pouvez désactiver cette règle pour une transaction donnée, sauf si la règle est imposée par le distributeur. Pour débrayer cette règle pour cette transaction, la requête doit contenir la directive MaxQuantityPerProduct.
Exemples :
Annexes
Désactivation dynamique de certaines règles du profil
Si vous souhaitez empêcher l’exécution d’une des règles de votre profil pour une transaction, vous devez envoyer l'élément correspondant à la règle dans l'élément fraudData de la demande de paiement (consulter le dictionnaire des données pour connaître les valeurs possibles pour chaque champ).
fraudData.bypassCtrlList | Désactiver les règles standards |
fraudData.bypassInfoList | Obsolète |
Réputations d'adresse IP
Une adresse IP peut avoir une ou plusieurs de ces réputations si elle a déjà été récemment concernée par l’un des cas suivants :
Adresse IP utilisée pour : | Description |
---|---|
Botnets | Les botnets sont des virus qui infectent un grand nombre de
machines afin de :
|
Déni de service | Une attaque par déni de service est une attaque
informatique ayant pour but de rendre indisponible un service,
d'empêcher les utilisateurs légitimes d'un service de l'utiliser.
Il peut s'agir de :
|
Phishing | Le Phishing consiste, pour les fraudeurs, à récupérer des informations confidentielles (financières, d'identification sur le système de votre entreprise etc.) grâce à un spam qui met en oeuvre une copie miroir frauduleuse et piégée d'une page réelle. |
Proxy anonymes | Un Proxy anonyme permet de naviguer anonymement. En général, c'est un serveur/proxy qui masque les informations personnelles (adresse IP, système d'exploitation, navigateur...) aux sites visités. |
Scanners | Permet de savoir si plusieurs machines ont la même adresse IP car ils appartiennent au même réseau. |
Source de Spam | Il s'agit en général d'envois d’e-mail en grande quantité effectués à des fins publicitaires. |
Attaques web | Les vulnérabilités des applications web peuvent être
catégorisées de la manière suivante :
|
Sources infectées | Adresses IP émettant des requêtes HTTP avec un indice de réputation faible ou qui sont des sites malveillants connus. |
Exploits Windows | Adresses IP ayant exploité des trous de sécurité contre les ressources Windows en utilisant des navigateurs, des programmes, des fichiers téléchargés, des scripts ou des vulnérabilités du système d'exploitation. |
Correspondances entre moyens de paiement et règles antifraudes
Mode pré-autorisation
Légende des tableaux :
1 astérisque (*) signifie que l'application de la règle dépend des informations carte fourni par votre acquéreur.
2 astérisques (**) signifient que l'application de la règle dépend de l'information que vous soumettez dans la requête de paiement.
Pour les règles combinatoires comme Pays émetteur de la carte et de l’adresse IP, Pays émetteur de la carte et pays de livraison et Pays de facturation et pays émetteur de la carte, l'application dépend à la fois du référentiel carte et de l'information que vous soumettez dans la requête de paiement.
![Règles de géolocalisation. Image trop complexe à décrire. Merci de contacter le support](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-autor-Geo.png)
![Règles d'encours. Image trop complexe à décrire. Merci de contacter le support](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-autor-Encours.png)
![Règles diverses. Image trop complexe à décrire. Merci de contacter le support](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-autor-Divers.png)
![Règles de liste. Image trop complexe à décrire. Merci de contacter le support](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-autor-Liste.png)
![Règles panier. Image trop complexe à décrire. Merci de contacter le support](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-autor-Panier.png)
Mode pré-authentification
Le mode pré-authentification est applicable uniquement pour les transactions carte (sauf portes feuilles numériques).
Légende des images :
1 astérisque (*) signifie que l'application de la règle dépend des informations carte fourni par votre acquéreur.
2 astérisques (**) signifient que l'application de la règle dépend de l'information que vous soumettez dans la requête de paiement.
Pour les règles combinatoires comme Pays émetteur de la carte et de l’adresse IP, Pays émetteur de la carte et de livraison et Pays émetteur de la carte et de facturation, l'application dépend à la fois du référentiel carte et de l'information que vous soumettez dans la requête de paiement.
![Règles de géolocalisation. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-auth-Geo.png)
![Règles d'encours. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-auth-Encours.png)
![Règles diverses. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-auth-Divers.png)
![Règles de liste. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-auth-Listes.png)
![Règles panier. Schéma trop complexe à décrire. Merci de contacter le support sips@worldline.com](../../resources/images/fr/WLSIPS.302-UG-Gestion-de-la-lutte-contre-la-fraude-Go-No-Go/Pre-auth-Panier.png)
Format de fichier d'export de liste
Fichier CSV de listes configurées dans les profils
Les fichiers générés par l’export de listes configurées dans les profils sont au format CSV dont le séparateur est le point-virgule « ; ».
Par défaut le fichier porte un nom dont le format est le suivant : <type de liste>_list.csv (ex : country_list.csv).
La première ligne du fichier correspond à l’en-tête des colonnes.
Chaque autre ligne du fichier correspond à un élément contenu dans la liste.
Quel que soit le type de liste, le contenu du fichier est le même.
Liste de pays simple
Les fichiers contenant une liste de pays (obtenu avec une règle comme « pays émetteur de la carte », « pays de l’adresse IP », etc.) sont constitués de 1 colonne :
- COUNTRY : le code pays ISO-3166.
Exemple :
Soit la liste dans la configuration de la règle « pays émetteur de la carte » d'un profil :
Pays |
---|
FRA |
DEU |
BEL |
Le fichier sera alors le suivant :
country_list.csv
COUNTRY;
FRA;
DEU;
BEL;
Liste de couples de pays
Les fichiers contenant une liste de couples de pays (obtenu avec une règle comme « pays émetteur de la carte et de l’adresse IP », « carte commerciale », etc.) sont constitués de 2 colonnes :
- COUNTRY1 : le code pays ISO-3166
- COUNTRY2 : le code pays ISO-3166
Exemple :
Soit la liste dans la configuration de la règle « pays émetteur de la carte et de l'adresse IP » dans un profil :
Pays 1 | Pays 2 |
---|---|
FRA | FRA |
DEU | FRA |
BEL | FRA |
Le fichier sera alors le suivant :
country_list.csv
COUNTRY1;COUNTRY2;
FRA;FRA;
DEU;FRA;
BEL;FRA;
Liste de domaines d'adresses e-mail
Les fichiers contenant une liste de domaines d'adresses e-mail (obtenu avec la règle « adresse e-mail ») sont constitués de 1 colonne :
- DOMAIN : le domaine web d'une adresse e-mail gratuite.
Exemple :
Soit la liste dans la configuration de la règle « adresse e-mail gratuite » d'un profil :
Domaine |
---|
domaine1.com |
domaine2.com |
domaine3.com |
Le fichier sera alors le suivant :
domain_list.csv
DOMAIN;
domaine1.com;
domaine2.com;
domaine3.com;
Fichier CSV de listes noires, grises et blanches
Les fichiers générés par l’export de liste grise, blanche ou noire sont au format CSV dont le séparateur est le point-virgule « ; ».
Par défaut le fichier porte un nom dont le format est le suivant :
<identifiant de boutique>_<couleur de la liste>_<type de liste>.csv (ex : 200007755500002_GREY_PAN.csv).
La première ligne du fichier correspond à l’en-tête des colonnes.
Chaque autre ligne du fichier correspond à un élément contenu dans la liste.
Quel que soit le type de liste, le contenu du fichier est le même, exception faite des listes de numéros de cartes dont le format est plus spécifique.
Liste de numéros de carte
Les fichiers contenant des listes de numéros de cartes sont constitués de 5 colonnes :
- TRANSACTION_REF où TRANSACTION_ID : la référence ou l’identifiant de la transaction, selon le mode de la boutique ;
- TRANSACTION_DATE : la date de la transaction au format AAAA-MM-JJ ;
- MASKED_PAN : le numéro de carte masqué ;
- REASON : le code raison de l’ajout de la carte dans la liste ;
- SHOP_ID : l’identifiant de la boutique à l’origine de l’ajout de l’élément dans la liste.
Exemple :
Soit la liste noire de numéros de carte de la boutique 201000770050003 suivante :
Réf/ID de transaction | Date | Numéro de carte | Raison | Boutique |
---|---|---|---|---|
915 | 2016-12-21 | 6703##########15 | fraud | 201000770050003 |
1546 | 2016-12-21 | 6703##########46 | fraud | 201000770050003 |
2530 | 2016-12-21 | 6703##########30 | fraud | 201000770050003 |
2735 | 2016-12-21 | 6703##########35 | fraud | 201000770050003 |
Le fichier sera alors le suivant :
201000770050003_BLACK_PAN.csv
TRANSACTION_REF;TRANSACTION_DATE;MASKED_PAN;REASON;SHOP_ID;
915;2016-12-21;6703##########15;fraud;201000770050003;
1546;2016-12-21;6703##########46;fraud;201000770050003;
2530;2016-12-21;6703##########30;fraud;201000770050003;
2735;2016-12-21;6703##########35;fraud;201000770050003;
Autres listes
Hormis les fichiers contenant des listes de numéros de cartes, tous les fichiers contenant des listes sont constitués de 3 colonnes :
- ITEM : correspond à la valeur de l’élément en liste (e-mail, identifiant client, adresse IP, etc.) ;
- REASON : le code raison de l’ajout de l’élément dans la liste ;
- SHOP_ID : l’identifiant de la boutique à l’origine de l’ajout de l’élément dans la liste.
Exemple :
Soit la liste noire d’identifiants de client de la boutique 201000770050003 suivante :
Élément | Raison | Boutique |
---|---|---|
123456 | fraudSuspicion | 201000770050003 |
987654 | negativeExperience | 201000770050003 |
456789 | notSpecified | 201000770050003 |
654321 | fraud | 201000770050003 |
Alors le fichier sera le suivant :
201000770050003_BLACK_CUSTOMER.csv
ITEM;REASON;SHOP_ID;
123456;fraudSuspicion;201000770050003;
987654;negativeExperience;201000770050003;
456789;notSpecified;201000770050003;
654321;fraud;201000770050003;
Fichier CSV de listes de produits à risque
Les fichiers générés par l’export de liste de produits à risque sont au format CSV dont le séparateur est le point-virgule « ; ».
Par défaut le fichier porte un nom dont le format est le suivant : <identifiant de boutique>_<nom de la liste>.csv (ex : 200007755500002_Ma_liste_de_produits.csv).
Chaque ligne du fichier correspond à un élément contenu dans la liste et comporte 3 colonnes :
- code produit ;
- libellé ;
- date de validité.
Exemple :
Si un fichier contient la liste suivante :
Code du produit | Libellé | Date de validité |
---|---|---|
A858F | Produit 1 | 29/10/2016 |
F85F4 | Produit 2 | 31/10/2016 |
Le fichier CSV correspondant sera :
A858F;Produit 1;29/10/2016
F85F4;Produit 2;31/10/2016