La plupart des guides sur Compelling Evidence 3.0 s'arretent aux regles de qualification: faire correspondre deux des quatre elements de donnees sur trois transactions, s'assurer que l'un est l'IP ou le device ID, et deposer sous le code motif 10.4. Si ces criteres sont remplis, le transfert de responsabilite est automatique.
Mais tous les litiges pour fraude ne qualifient pas pour CE 3.0. Quand ce n'est pas le cas, on retombe sur le representment standard, ou les preuves soumises sont effectivement evaluees. Cet article couvre les quatre elements de donnees que Visa impose pour CE 3.0, puis passe en revue six points de preuve supplementaires qui comptent pour les litiges que CE 3.0 ne couvre pas.
La regle, en resume
CE 3.0 s'applique aux litiges Visa carte non presente deposes sous le code motif 10.4 ("Other Fraud: Card-Absent Environment"). Le marchand doit fournir deux transactions precedentes non contestees sur les memes identifiants de paiement, chacune agee de 120 a 365 jours par rapport a la date du litige. Au moins deux des quatre elements de donnees principaux (User ID, adresse de livraison, adresse IP ou device ID) doivent correspondre dans les trois transactions, et l'un des deux doit etre l'adresse IP ou le device ID.
Source: Document de preparation des marchands Visa Compelling Evidence 3.0.
Les quatre elements de donnees que Visa impose
La qualification CE 3.0 exige qu'au moins deux des quatre elements de donnees correspondent dans les trois transactions (la contestee et les deux precedentes non contestees). L'un des deux doit etre l'adresse IP ou le device ID.
- Correspondance de User ID. L'identifiant que le marchand utilise pour le compte du titulaire. Il doit etre coherent dans les trois transactions.
- Correspondance d'adresse de livraison. Adresse de livraison dans les trois transactions. Les differences mineures (numeros d'appartement, ponctuation) peuvent poser probleme; la plupart des acquereurs exigent une correspondance exacte.
- Correspondance d'adresse IP. IP capturee au moment de l'achat pour les trois transactions. La correspondance au niveau FAI est acceptable pour la plupart des emetteurs; l'adresse exacte est plus solide.
- Correspondance de device ID. Empreinte du dispositif capturee au checkout dans les trois transactions. Elle doit etre produite par la meme source pour etre traitee comme deterministe. Un browser fingerprint combine des dizaines de signaux non sensibles (resolution d'ecran, fuseau horaire, parametres de langue) en un hash stable qui persiste entre les sessions, le mode incognito et le stockage efface.
Un cinquieme champ, le numero de compte principal (PAN), est la base. Le meme PAN dans les trois transactions est un prerequis, pas l'un des quatre elements a comparer. Les PAN tokenises comptent si la reference du token est stable entre les sessions.
Au-dela de CE 3.0: six points de preuve pour les litiges qui ne qualifient pas
Si le litige remplit les criteres CE 3.0, le transfert de responsabilite est automatique. Rien d'autre que les quatre elements de donnees imposes n'est necessaire pour gagner.
Mais tous les litiges pour fraude ne qualifient pas pour CE 3.0. Le code motif peut ne pas etre 10.4, il peut ne pas y avoir deux transactions precedentes non contestees dans la fenetre de 120 a 365 jours, ou les elements de donnees peuvent ne pas correspondre assez proprement. Pour ces cas, on retombe sur le representment standard, ou l'emetteur evalue les preuves et prend une decision. Ces six points de preuve font la difference dans ce processus:
- Coherence du descriptor first-6. Les six premiers caracteres du descripteur de facturation doivent etre identiques pour que l'acquereur les traite comme le meme marchand. La derive du descripteur entre les charges initiales et recurrentes est l'une des raisons les plus frequentes d'echec de qualification CE 3.0, et elle affaiblit aussi le representment standard.
- Enregistrement d'authentification. Visa Secure ou Visa Data Only associe a la transaction. En representment standard, cela demontre que le titulaire s'est authentifie, ce qui sape la reclamation de fraude. En contexte CE 3.0, cela peut declencher l'auto-qualification.
- Confirmation de livraison ou d'execution. Pour les biens physiques, un numero de suivi et une preuve de livraison signee. Pour les biens numeriques, une session avec correspondance IP montrant l'acces au contenu. C'est une preuve standard de representment qui contredit directement "je n'ai pas recu cela".
- Schema temporel des transactions precedentes. Un historique de transactions montrant une relation client plausible, pas deux achats regroupes artificiellement. En representment standard, cela etablit le schema d'utilisation legitime du titulaire.
- Signaux de continuite de session. Preuve que la meme session de navigateur ou le meme device a ete utilise pour naviguer, ajouter au panier et completer le paiement. Cela lie la transaction a une session utilisateur reelle plutot qu'a un point de donnees unique au checkout. Le device fingerprinting concu pour CE 3.0 peut produire ce type de continuite au niveau session nativement.
- Profil de litiges du marchand. Un marchand avec un historique de litiges propre beneficie du doute en representment standard. Un marchand avec un long historique de cas renverses fait face a un examen plus severe meme avec des preuves solides.
D'ou vient chaque point de preuve
User ID et adresse de livraison proviennent de la base de donnees des commandes. Descripteur de facturation et authentification proviennent du processeur de paiement et de la configuration 3DS. Adresse IP et device ID (les deux qui determinent la qualification CE 3.0) proviennent de la session de checkout, et la plupart des marchands ne les capturent pas de maniere fiable.
Elements imposes par Visa:
| Element de donnees | Source | Generalement capture au moment du representment? |
|---|---|---|
| PAN (prerequis) | DB commandes / processeur de paiement | Oui |
| User ID | DB commandes | Oui |
| Adresse de livraison | DB commandes | Oui |
| Adresse IP | Session de checkout | Parfois (inconsistant) |
| Device ID | Session de checkout | Rarement (necessite instrumentation) |
Points de preuve supplementaires:
| Point de preuve | Source | Generalement capture au moment du representment? |
|---|---|---|
| Descriptor first-6 | Configuration du processeur de paiement | Oui |
| Enregistrement d'authentification | Flux 3DS | Oui ou 3DS est actif |
| Execution / livraison | OMS / transporteur | Oui |
| Schema temporel des transactions | DB commandes + outil de reponse aux litiges | Oui |
| Continuite de session | Session de checkout | Rarement (necessite instrumentation) |
| Profil de litiges | Acquereur | Implicite |
L'adresse IP et le device ID sont les points ou la plupart des cas de representment echouent sur le fond. Ce sont des donnees de session de checkout, pas des donnees de base de commandes. Un outil de chargeback cote serveur ne peut pas les reconstruire apres coup. Si l'instrumentation n'etait pas presente au moment de l'achat, les donnees n'existent tout simplement pas.
L'exigence de preuve au niveau du navigateur
Device ID et IP au standard de qualification CE 3.0 signifient la meme signature de dispositif et de reseau sur les transactions precedentes et la contestee. Cette signature est capturee au checkout, dans le navigateur, au moment ou le titulaire soumet le paiement. Aucun systeme post-hoc ne peut la produire.
Le produit Chargeback Evidence de cside capture les donnees du navigateur au checkout. L'identite du dispositif est stable entre les sessions chez le meme marchand, ce qui permet qu'une transaction precedente d'il y a huit mois soit reliee de maniere deterministe a une transaction contestee aujourd'hui. L'IP capturee est celle que le titulaire a reellement utilisee a l'achat, pas une IP inferee ulterieurement.
Pour le dossier de preuves dans son ensemble, la capture au niveau navigateur comble les deux champs obligatoires que les outils cote serveur ne peuvent pas (adresse IP et device ID) et renforce la confirmation de livraison en liant l'acces d'execution au meme dispositif. Le dossier presente a l'emetteur se lit comme une chaine de preuves complete plutot qu'un assemblage de documents.
Ce que cela signifie sur le plan operationnel
Commencez par auditer si vos litiges peuvent qualifier pour CE 3.0. Si les quatre elements de donnees imposes correspondent, le transfert de responsabilite est automatique et vous n'avez pas besoin de construire un dossier plus large. La correction a plus fort impact est de vous assurer que vous pouvez reellement capturer IP et device ID au checkout pour que davantage de litiges qualifient.
Pour les litiges hors CE 3.0, auditez les six points de preuve complementaires. Les corrections les moins couteuses sont l'alignement du descriptor first-6 et la couverture 3DS. La plus impactante est la capture de preuves au niveau navigateur, qui vous donne des donnees au niveau session pour soutenir le representment standard.
Un audit de trente minutes:
- Tirez dix litiges recents sous code motif 10.4. Pour chacun, verifiez si vous disposiez des quatre elements de donnees imposes par Visa. Combien auraient pu qualifier pour CE 3.0 mais n'ont pas qualifie parce que l'IP ou le device ID manquait?
- Pour ceux qui n'ont pas qualifie, verifiez lesquels des six points de preuve complementaires vous auriez pu soumettre en representment standard. Le schema est generalement clair: device ID et IP sont soit tous deux absents, soit de faible qualite, et le descriptor first-6 derive entre les cycles de facturation.
- Comparez votre taux de victoire sur les litiges qualifies CE 3.0 (qui devrait etre proche de 100%) a votre taux de representment standard. L'ecart vous indique combien de revenus sont en jeu dans les litiges que CE 3.0 ne couvre pas.
Le Rapport Global Fraude et Paiements 2025 du Merchant Risk Council a constate que la majorite des marchands interroges utilisent desormais le programme Compelling Evidence. Les marchands en tete de cette cohorte sont ceux qui ont instrumente la couche navigateur, qualifiant davantage de litiges pour CE 3.0 des le depart. Ceux en bas du classement manquent d'IP et de device ID, ce qui signifie moins de victoires automatiques et des representments standard plus faibles.
Erreurs courantes
Les trois erreurs CE 3.0 les plus courantes sont la derive du descripteur entre cycles de facturation, la dependance a la capture IP cote serveur (qui reflete souvent le load balancer plutot que le client) et le traitement des device fingerprints comme opportunistes. Chacune peut empecher un litige de qualifier pour CE 3.0 en premier lieu, et chacune affaiblit votre position en representment standard.
Derive du descripteur. Les processeurs de paiement reecrivent parfois les descripteurs entre transactions initiales et recurrentes, ou les font varier par devise. Meme un changement d'un caractere dans les six premiers casse la qualification.
Capture IP cote serveur. Beaucoup de marchands enregistrent l'IP depuis le serveur qui recoit le POST du checkout, ce qui dans les architectures modernes capture souvent un load balancer ou un edge CDN plutot que le client. L'IP doit etre capturee cote client au niveau du navigateur pour correspondre de maniere fiable.
Device fingerprints opportunistes. Un device fingerprint capture par un script tiers qui se charge au checkout n'est pas la meme chose qu'un fingerprint deterministe de session de checkout. Si le marchand ne peut pas reproduire la logique de fingerprinting a la demande, l'emetteur peut ecarter la correspondance.
Autres lectures cside
A propos de l'auteur
Mike Kutlu est Head of GTM chez cside, ou il travaille avec des responsables paiements, risque et finance sur l'instrumentation des preuves de chargeback au niveau navigateur pour le representment Compelling Evidence 3.0. Il ecrit sur VAMP, le friendly fraud et la mecanique des preuves de litige pour les marchands enterprise.
