Comment réduire les rétrofacturations grâce à la détection IP
Réduisez les rétrofacturations grâce à la détection IP : évaluez l'IP derrière chaque commande carte non présente pour stopper la fraude CNP, et gagnez les litiges de fraude amicale avec des preuves IP.

Tous les commerçants rencontrent la rétrofacturation de la même façon. Une carte est acceptée, la commande est expédiée, et quarante jours plus tard l'argent est repris sur votre compte avec des frais, parfois des frais supérieurs au montant de la vente. Si cela arrive assez souvent, vous ne discutez plus de commandes individuelles. Vous discutez avec Visa et Mastercard pour savoir si vous pouvez continuer à accepter les cartes.
La plupart des conseils anti-rétrofacturation traitent le litige comme l'événement. Ce n'en est pas un. Le litige est la facture d'une décision que vous avez déjà prise : le moment où vous avez autorisé une transaction que vous auriez dû filtrer, ou expédié à un client dont vous n'aviez pas assez bien enregistré la commande pour la défendre. La détection IP n'est pas un moyen de mieux argumenter après coup. C'est un moyen de ramener la décision aux deux points où elle peut encore tourner en votre faveur : l'autorisation et la preuve.

Une rétrofacturation, ce sont en réalité deux problèmes différents
Avant tout outil, posez la bonne taxonomie, car les deux types de rétrofacturation exigent des réponses opposées.
La vraie fraude, c'est un inconnu qui utilise une carte volée. Le numéro de quelqu'un d'autre, votre boutique, des marchandises expédiées à une adresse relais. C'est la rétrofacturation que vous voulez prévenir, car chacune qui passe représente du stock perdu, plus des frais, plus une marque contre votre taux. La détection IP la combat à la porte d'entrée, avant l'expédition, en lisant le réseau de la commande comme un score de fraude IP avec des tranches allow, review, step-up et block.
La fraude amicale (aussi appelée abus de première partie), c'est votre vrai client qui conteste un paiement qu'il a bel et bien effectué. Il a oublié l'abonnement, un membre de sa famille a commandé, ou il a simplement appris qu'un « je ne reconnais pas cette opération » permet de récupérer l'argent. Selon les propres chiffres de Visa, ce type d'abus de première partie représente jusqu'à 75 % de toutes les rétrofacturations. Vous ne pouvez pas la prévenir au paiement, car la transaction était légitime. Vous la gagnez après coup, avec des preuves, et l'adresse IP est l'une de ces preuves expressément citées.
Un champ, deux rôles : il écarte la vraie fraude avant qu'elle ne devienne un litige, et il vous aide à annuler la fraude amicale une fois le litige ouvert. C'est pourquoi c'est le meilleur point de départ.
Pourquoi le taux est désormais une question de survie
Si les rétrofacturations ont cessé d'être un simple coût d'exploitation pour devenir une question de survie, c'est que les réseaux de cartes ont réécrit leurs programmes de surveillance, et que les deux nouvelles versions visent directement les commandes en ligne.
Visa a fusionné ses deux anciens programmes (le Visa Dispute Monitoring Program et le Visa Fraud Monitoring Program) en un seul Visa Acquirer Monitoring Program (VAMP), en vigueur depuis avril 2025. Lisez le fonctionnement dans la fiche d'information VAMP de Visa, car deux détails changent la manière dont vous devriez aborder le problème :
- Seules les transactions carte absente comptent. Le taux VAMP est construit à partir de l'activité carte non présente. Les rétrofacturations qui menacent votre compte commerçant sont, par définition, les commandes en ligne : exactement celles pour lesquelles vous disposez de l'adresse IP du client.
- Fraudes et litiges sont comptés ensemble, et souvent deux fois. Le taux combine les déclarations de fraude TC40 et les litiges TC15 sur les transactions réglées. Comme une transaction déclarée frauduleuse devient généralement aussi un litige, une seule mauvaise commande peut peser deux fois sur votre taux. La prévenir une fois supprime les deux.
- La barre baisse. Le seuil « Excessive » pour les commerçants a démarré à 2,2 % et descend à 1,5 % à partir d'avril 2026 aux États-Unis, au Canada et dans l'UE. Le plancher se rapproche de vous.
Mastercard suit une voie parallèle. Son Excessive Chargeback Program signale un Excessive Chargeback Merchant (ECM) à un taux de 1,5 % avec 100 à 299 rétrofacturations dans le mois, et un High Excessive Chargeback Merchant (HECM) à 3,0 % avec 300 ou plus. Les amendes augmentent à mesure que vous restez au-dessus du seuil, et l'issue finale pour un commerçant qui ne parvient pas à redresser la situation est la liste MATCH, un exil de fait de cinq ans hors du traitement des cartes.
| Programme | Seuil qui compte | Ce qu'il comptabilise | Issue finale |
|---|---|---|---|
| Visa VAMP (commerçant) | 2,2 % aujourd'hui → 1,5 % à partir d'avr. 2026 (US/CA/UE) | Fraudes + litiges carte absente, combinés | Amendes croissantes, pression de l'acquéreur |
| Mastercard ECM | Taux de 1,5 %, 100 à 299 rétrofacturations | Toutes les rétrofacturations, quel que soit le motif | Amendes mensuelles qui augmentent avec le temps |
| Mastercard HECM | Taux de 3,0 %, 300+ rétrofacturations | Toutes les rétrofacturations, quel que soit le motif | Hausse plus rapide des amendes, risque de liste MATCH |
L'enseignement n'est pas le chiffre exact (vérifiez auprès de votre propre acquéreur, car les régions et les dates de déploiement varient). C'est la direction. Les réseaux ont décidé que votre taux de rétrofacturation carte non présente est un indicateur de conformité, le seuil baisse, et le trafic qu'il mesure est précisément celui qu'une requête IP peut lire.
Où la détection IP s'inscrit dans le cycle de vie d'une rétrofacturation
Une commande carte non présente franchit trois points de contrôle où l'IP est décisive, au sein d'une pile de détection de la fraude au paiement en couches plus large, avec des vérifications de l'appareil, de l'émetteur et des revues. Réduire les rétrofacturations implique d'utiliser les trois, pas seulement le premier.
| Étape | Quand | Ce que fait l'IP |
|---|---|---|
| Filtrage avant autorisation | Avant d'approuver ou d'expédier | Signale la fraude à la carte volée pour que vous puissiez refuser, examiner ou renforcer l'authentification. La rétrofacturation n'existe alors jamais. |
| Décision d'authentification renforcée (3DS) | Au paiement, de façon sélective | Décide quelles commandes reçoivent un défi 3-D Secure, pour obtenir le transfert de responsabilité sans friction sur les commandes saines. |
| Preuve en cas de litige | Des semaines plus tard, lors de la contestation | Fournit l'IP capturée comme Compelling Evidence 3.0 pour annuler les rétrofacturations de fraude amicale. |
La plupart des commerçants n'utilisent jamais que le premier point de contrôle, et encore, de façon rudimentaire. Les gains cumulés viennent de l'utilisation de l'IP pour décider qui voit un défi 3DS, et du fait de l'avoir capturée pour pouvoir gagner les litiges qui arrivent en contestation. Nous traitons d'abord la porte d'entrée, car c'est là que se trouvent les signaux les plus fiables et les moins sujets aux faux positifs.
Les signaux IP qui annoncent une rétrofacturation
Voici ce qu'il faut lire dans l'adresse derrière une commande, à peu près par ordre de rapport signal/bruit pour les paiements carte non présente.
| Signal | Pourquoi il annonce une rétrofacturation | Comment le traiter |
|---|---|---|
| Le type de connexion / l'ASN est un hébergeur | Les vrais acheteurs ne paient pas depuis AWS. Une origine datacenter est le signe classique du carding automatisé. | Fort au paiement, faible dans le score seul. Ajoutez votre propre règle dessus (voir la requête ci-dessous). |
| VPN / proxy public / Tor | Masquer délibérément son origine lors d'un paiement est une raison de regarder de plus près. | Pondérez-le, mais ne bloquez jamais sur ce seul critère. Beaucoup de vrais acheteurs utilisent un VPN. |
| Pays de facturation ≠ pays du réseau | Une carte facturée dans un pays qui paie depuis un réseau situé dans un autre est un schéma de fraude CNP bien connu. | Négatif modéré. Combinez-le avec le type de connexion avant d'agir. |
| Inscription dans un flux de menaces / une liste de blocage | Une infrastructure avec un historique d'abus actif est réutilisée d'une campagne de fraude à l'autre. | Fort lorsqu'il est récent. Pondérez selon l'ancienneté, pas selon la simple présence sur une liste. |
| Fournisseur de VPN/d'anonymisation nommé | L'attribution à un VPN commercial ou à un relais précis renforce le signal de masquage. | Corroborant : augmente la confiance dans les autres indicateurs. |
| FAI résidentiel / mobile | C'est là que se trouvent réellement vos vrais clients. | Disculpant. Une raison d'être plus indulgent, pas moins. |
| CGNAT (NAT de niveau opérateur) | Des centaines d'abonnés mobiles partagent une seule adresse publique. | Disculpant. Plafonnez le risque ici, sinon vous pénaliserez de vrais acheteurs. |
Notez le sens des deux dernières lignes. Un modèle de score qui ne fait qu'ajouter des points écrasera votre audience mobile légitime sous les faux refus, et un faux refus au paiement n'est pas une connexion bloquée. C'est un client payant que vous avez renvoyé. Un modèle qui sait aussi soustraire (en traitant un FAI résidentiel comme une raison d'indulgence et en plafonnant les plages CGNAT) est ce qui empêche la prévention des rétrofacturations de devenir discrètement une prévention du chiffre d'affaires. Cet équilibre repose sur les raisons qui abaissent un score de risque, et il compte davantage au paiement que presque partout ailleurs.
Point crucial, l'IP est une preuve, pas un verdict. Ne bannissez pas l'adresse. Une IP publique est partagée par de nombreuses personnes sans lien entre elles, donc un blocage strict supprime de vrais clients en même temps que la fraude. Évaluez-la, pondérez-la par rapport aux autres signaux et agissez sur l'ensemble. Nous développons cet argument dans détecter le trafic anonymisé sans bloquer de vrais clients, et c'est la même discipline qui distingue un filtre de paiement intelligent d'un filtre grossier dans stopper la fraude des agents d'achat IA et des bots au paiement par IP.
Tout lire en un seul appel
Concrètement, il s'agit d'une seule requête sur l'IP qui a passé la commande, avant de décider s'il faut l'approuver, la soumettre à un défi ou l'examiner.
curl -H "x-api-key: YOUR_API_KEY" \
https://api.geoiphub.com/v1/lookup/45.33.32.156
Les champs qui comptent pour une commande carte non présente se répartissent sur quatre groupes de la réponse :
const res = await fetch(`https://api.geoiphub.com/v1/lookup/${orderIp}`, {
headers: { "x-api-key": process.env.GEOIPHUB_API_KEY },
});
const ip = await res.json();
ip.asn.asn_type; // "hosting": a checkout should not originate here
ip.asn.connection_type; // "datacenter" | "residential" | "mobile"
ip.detection.is_hosting; // true: datacenter origin on a consumer payment
ip.detection.is_vpn; // deliberate concealment; weigh it, don't ban
ip.detection.vpn_provider; // the named provider, when concealment is present
ip.geo.country_code; // compare against the billing country on the card
ip.threat.threat_types; // e.g. ["vpn"] or ["tor"] when a feed or probe tags the address
ip.threat.is_cgnat; // shared mobile address: a reason for leniency
ip.scoring.fraud_score; // 0-100 composite
ip.scoring.recommended_action; // "allow" | "review" | "step_up" | "block"
ip.scoring.detection_methods; // exactly which signals fired: your audit trail
detection_methods est le champ qui transforme une boîte noire en une décision que vous pouvez défendre. Lorsqu'une commande est soumise à un défi ou retenue, vous pouvez dire pourquoi (ASN d'hébergement, masquage par VPN, discordance du pays de facturation, listée dans deux flux cette semaine) au lieu de hausser les épaules devant un score. Et country_code est celui à rapprocher de l'adresse de facturation de la carte : une carte facturée en Allemagne qui paie depuis un réseau d'hébergement dans un autre pays est la plus vieille histoire de fraude CNP qui soit.
Vous pouvez essayer le résultat du score sur n'importe quelle adresse avec l'outil gratuit de vérification du score de fraude IP avant de l'intégrer, et la même requête est documentée comme une brique réutilisable dans ajouter la détection de fraude IP en temps réel à votre application.
Une IP d'hébergement obtient allow ; un VPN vérifié obtient block
Les deux signaux en tête du tableau se comportent très différemment dans le score : une simple adresse d'hébergement revient en allow, et un serveur VPN avec une preuve de protocole revient en block. Voici les deux, extraits de vraies requêtes effectuées le 2026-10-26 (les résultats changent à mesure que les plages évoluent). D'abord 45.33.32.156, l'adresse d'hébergement de l'appel ci-dessus (l'hôte de test public de Nmap, scanme.nmap.org) :
{
"ip": "45.33.32.156",
"asn": {
"asn": 63949,
"org": "AKAMAI-LINODE-AP - Akamai Connected Cloud",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"geo": { "country_code": "US", "city": "Fremont" },
"detection": {
"is_hosting": true,
"is_vpn": false,
"is_proxy": false,
"is_tor": false
},
"threat": { "is_cgnat": false, "threat_types": [] },
"scoring": {
"fraud_score": 10,
"confidence": 0.25,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip"]
}
}
Puis 185.213.155.73, un serveur VPN Mullvad à Francfort :
{
"ip": "185.213.155.73",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"geo": { "country_code": "DE", "city": "Frankfurt am Main (Innenstadt I)" },
"detection": {
"is_vpn": true,
"is_hosting": true,
"is_anonymous": true,
"vpn_provider": "Mullvad",
"vpn_confidence": 95
},
"threat": { "threat_types": ["vpn"] },
"scoring": {
"fraud_score": 100,
"confidence": 0.7075,
"recommended_action": "block",
"detection_methods": ["known_vpn_server", "wireguard_open", "datacenter_with_vpn_proxy", "no_ptr_datacenter"]
}
}
L'IP d'hébergement a déclenché une seule méthode, datacenter_ip, et obtenu 10 : le score général ne traite pas une origine datacenter comme une fraude en soi, c'est donc à vous d'ajouter la règle de paiement correspondante. Le VPN en a déclenché quatre : il figure sur la liste de serveurs publiée par Mullvad lui-même (qui nomme aussi le fournisseur), cette liste l'indique comme serveur WireGuard, le protocole sur un réseau d'hébergement ajoute datacenter_with_vpn_proxy, et il n'a pas de nom DNS inverse. Il a obtenu 100. Tous les VPN ne sont pas nommés : un serveur détecté uniquement par notre propre sonde de protocole revient avec vpn_provider "none", n'y comptez donc pas. Comme de vrais acheteurs utilisent aussi des VPN, traitez ce block au paiement comme « envoyer vers 3-D Secure ou en revue », sauf si un second signal va dans le même sens, par exemple un pays de facturation différent de geo.country_code.
3-D Secure sans la taxe de friction
Le deuxième point de contrôle est celui où la réduction des rétrofacturations cesse d'être purement défensive.
Lorsqu'une transaction carte non présente est authentifiée via EMV 3-D Secure, la responsabilité d'une rétrofacturation ultérieure pour fraude passe généralement du commerçant à l'émetteur de la carte. C'est le levier le plus puissant dont vous disposez contre les rétrofacturations de vraie fraude : une commande authentifiée qui se révèle ensuite frauduleuse n'est généralement pas votre perte.
Alors pourquoi ne pas faire passer chaque commande par 3DS ? Parce qu'un défi est une friction, et que la friction, ce sont des paniers abandonnés. Imposez une authentification renforcée à chaque acheteur et vous perdrez plus de chiffre d'affaires en abandons de panier que vous n'en avez jamais perdu à cause de la fraude.
C'est exactement le compromis que résout un score de risque IP. Au lieu de soumettre tout le monde ou personne à un défi, vous le faites selon le risque :
- Score faible (FAI résidentiel, historique propre, pays concordant) : laissez passer sans friction. La plus grande partie de votre trafic se trouve ici.
- Score élevé (discordance de pays, signaux faibles), ou VPN sans rien d'autre contre lui : orientez vers un défi 3DS. Un VPN vérifié tombe à lui seul dans la tranche block, il s'agit donc d'une dérogation délibérée. Vous obtenez le transfert de responsabilité précisément sur les commandes où vous le voulez.
- Score très élevé (un VPN vérifié ou un nœud de sortie Tor avec un second signal concordant, comme une discordance de pays) : refusez ou retenez pour revue ; ne gaspillez pas la tentative 3DS sur une infrastructure évidente.
Le score IP décide qui voit le défi. C'est ainsi que vous captez la protection de responsabilité de 3DS sur la tranche risquée tout en laissant votre majorité saine intacte. C'est la même logique par action que nous exposons dans à partir de quel score de fraude IP bloquer, appliquée spécifiquement à l'étape du paiement.
Gagner le litige de fraude amicale
Le troisième point de contrôle est celui que la plupart des commerçants laissent totalement désarmé, et c'est là que se trouvent réellement jusqu'aux trois quarts des rétrofacturations.
Lorsqu'un vrai client conteste un achat qu'il a réellement effectué, vous ne pouviez pas l'empêcher au paiement, car la commande était légitime. Ce que vous pouvez faire, c'est prouver que c'était bien lui. Visa a créé une norme exactement pour cela : Compelling Evidence 3.0, en vigueur depuis avril 2023, qui permet à un commerçant d'annuler un litige de fraude carte absente (code motif Visa 10.4) en démontrant une empreinte historique avec le titulaire de la carte.
Lisez attentivement l'exigence, car l'adresse IP y est inscrite :
- Vous fournissez deux transactions antérieures non contestées sur les mêmes identifiants, datant de 120 à 365 jours.
- Ces transactions doivent partager des éléments de données de base avec la commande contestée. Les éléments cités par Visa sont l'adresse IP, l'identifiant ou l'empreinte de l'appareil, l'identifiant utilisateur et l'adresse de livraison.
- Au moins deux éléments doivent correspondre sur les trois transactions, et au moins l'un d'eux doit être l'adresse IP ou l'identifiant ou l'empreinte de l'appareil.
- Si la preuve est recevable, la responsabilité passe à l'émetteur, et vous gardez l'argent.
L'adresse IP n'est pas un simple plus ici. C'est l'un des deux éléments d'ancrage que Visa accepte comme preuve que la personne qui conteste le paiement est la même que celle qui vous achète depuis des mois. Mais voici ce qui fait discrètement perdre aux commerçants des litiges qu'ils auraient pu gagner : vous ne pouvez soumettre cette preuve que si vous avez capturé l'IP de chaque commande dès le départ, et que vous l'avez conservée assez longtemps pour remonter une année entière.
Cela change entièrement la perspective sur la requête avant autorisation. L'IP que vous enregistrez au paiement n'est pas seulement un signal de fraude pour la commande du jour. C'est la matière première pour gagner un litige de fraude amicale dans un an. Capturez-la à chaque transaction, conservez-la avec l'historique du client, et Compelling Evidence 3.0 passe d'une règle que vous ne pouvez pas utiliser à une rétrofacturation que vous pouvez annuler.
Se lancer cette semaine
- Capturez l'IP de chaque commande. Conservez-la avec la transaction et le client, horodatée, pendant au moins 18 mois afin qu'elle soit disponible pour une soumission Compelling Evidence 3.0. Vous ne pouvez pas évaluer (ni défendre) ce que vous n'avez pas enregistré.
- Évaluez, ne bannissez pas. Passez chaque IP de paiement dans une requête et conservez le score avec la commande, afin de pouvoir segmenter les litiges par tranche de risque et affiner à partir des résultats réels.
- Commencez par le plancher datacenter. Un ASN
hostingouconnection_type: "datacenter"sur un paiement grand public est un signal très fiable, avec peu de faux positifs. Le score général classe une simple IP d'hébergement enallow, donc écrivez cela comme votre propre règle de paiement surdetection.is_hostingplutôt que d'attendre que le score le détecte. - Vérifiez la concordance des pays. Comparez
geo.country_codeau pays de facturation de la carte. Une discordance accompagnée d'un indicateur de masquage, quel qu'il soit, est une bonne raison de renforcer l'authentification. - Orientez vers 3DS selon le score, pas par défaut. Envoyez la tranche risquée vers le défi pour le transfert de responsabilité ; laissez la majorité saine passer sans friction.
- Protégez les vrais clients. Traitez le CGNAT et les FAI résidentiels et mobiles comme disculpants. Le garde-fou contre les faux refus est ce qui rend tout cela rentable.
La rétrofacturation vous a déjà dit d'où elle venait, deux fois : à la commande et au litige. Les réduire consiste surtout à écouter aux deux moments au lieu d'aucun.
Questions fréquentes
Comment la détection IP réduit-elle les rétrofacturations ?
À deux endroits. Avant la vente, une requête IP sur la commande signale les transactions les plus risquées (une connexion d'hébergement ou de datacenter, un VPN d'anonymisation ou un nœud de sortie Tor, un pays de facturation qui ne correspond pas au pays du réseau, ou une adresse déjà listée dans des flux de menaces) afin que vous puissiez les orienter vers 3-D Secure ou une revue manuelle au lieu d'expédier vers un litige assuré. Après la vente, lorsqu'un vrai client dépose une rétrofacturation de fraude amicale sur un achat qu'il a bien effectué, l'adresse IP fait partie des « éléments de données de base » nommés dans Compelling Evidence 3.0 de Visa, donc une IP capturée et concordante vous aide à gagner la contestation (representment). Le même champ réduit à la fois la fraude qui devient une rétrofacturation et la fraude amicale que vous pouvez annuler.
Quel taux de rétrofacturation met un commerçant en difficulté ?
Dans le cadre du Visa Acquirer Monitoring Program (VAMP), qui a remplacé les anciens programmes VDMP et VFMP en avril 2025, un commerçant est classé « Excessive » à un taux de 2,2 % au lancement, abaissé à 1,5 % à partir d'avril 2026 aux États-Unis, au Canada et dans l'UE. Point essentiel, seules les transactions carte absente (en ligne) comptent dans ce taux. L'Excessive Chargeback Program de Mastercard signale un Excessive Chargeback Merchant à un taux de 1,5 % avec 100 à 299 rétrofacturations, et un High Excessive Chargeback Merchant à 3,0 % avec 300 ou plus. Des dépassements prolongés entraînent des amendes croissantes et, au bout du compte, l'inscription sur la liste MATCH, qui peut empêcher une entreprise de traiter des cartes pendant cinq ans.
Peut-on stopper une rétrofacturation simplement en bloquant les adresses IP risquées ?
Non. Le blocage est le mauvais outil et il coûte plus qu'il ne rapporte. Une même IP publique est couramment partagée par de nombreuses personnes via le CGNAT (NAT de niveau opérateur), et beaucoup d'acheteurs légitimes utilisent un VPN, donc un blocage strict d'une adresse ou d'une plage supprime de vrais clients en même temps que la fraude. L'IP est une preuve, pas un verdict : évaluez-la comme une donnée pondérée parmi d'autres, n'orientez que les commandes réellement à haut risque vers une authentification renforcée ou une revue, et réservez les blocages purs et simples aux infrastructures sans ambiguïté, comme une adresse de datacenter sur un paiement grand public.
3-D Secure élimine-t-il les rétrofacturations ?
Il transfère la responsabilité plutôt qu'il n'élimine les litiges. Lorsqu'une transaction carte non présente est authentifiée via EMV 3-D Secure, la responsabilité d'une rétrofacturation ultérieure pour fraude passe généralement du commerçant à l'émetteur de la carte. Le problème est que soumettre chaque client à un défi 3DS ajoute de la friction et fait perdre des ventes. Un score de risque IP vous permet d'appliquer 3DS de façon sélective : envoyez les commandes risquées vers le défi et laissez passer les commandes saines sans friction. C'est ainsi que vous obtenez la protection de responsabilité sans pénaliser vos bons clients.
Comment l'adresse IP sert-elle de preuve dans une rétrofacturation ?
Compelling Evidence 3.0 de Visa, en vigueur depuis avril 2023, permet à un commerçant de contester un litige de fraude carte absente (code motif 10.4) en montrant une « empreinte historique » : deux transactions antérieures non contestées sur les mêmes identifiants, datant de 120 à 365 jours, qui partagent des éléments de données de base avec la commande contestée. L'adresse IP est l'un de ces éléments de base, et au moins l'une des deux correspondances exigées doit être l'adresse IP ou l'identifiant ou l'empreinte de l'appareil. Si la preuve est recevable, la responsabilité passe à l'émetteur. Cela ne fonctionne que si vous avez capturé et conservé l'IP de chaque commande dès le départ.
Quels signaux IP annoncent une rétrofacturation ?
Les champs les plus parlants sont le type de connexion et le type d'ASN (un paiement depuis un réseau d'hébergement ou de datacenter n'est pas celui d'un acheteur normal), les indicateurs d'anonymisation (VPN, proxy public, Tor), une discordance entre le pays du réseau et le pays de facturation, et les inscriptions dans des flux de menaces pondérées selon leur ancienneté. Le CGNAT et un simple FAI résidentiel jouent dans l'autre sens : ce sont des raisons d'être plus indulgent, pas moins. Un bon score de risque combine tout cela en un seul chiffre explicable, accompagné des signaux exacts qui se sont déclenchés, de sorte qu'une commande refusée ou soumise à un défi puisse être justifiée plutôt que devinée.
L'équipe derrière l'API GeoIPHub
Rédigé par l'équipe GeoIPHub, les personnes qui développent l'API de renseignement IP GeoIPHub et son scanner. Les brouillons sont préparés avec l'aide de l'IA et relus par l'équipe ; les exemples d'API sont de vraies requêtes sur l'API en production, sauf mention « illustratif ».


