De meeste gidsen over Compelling Evidence 3.0 stoppen bij de kwalificatieregels: twee van vier data-elementen matchen over drie transacties, zorgen dat een ervan IP of device ID is, en indienen onder reason code 10.4. Als aan die criteria is voldaan, is de aansprakelijkheidsverschuiving automatisch.
Maar niet elke fraudedispute kwalificeert voor CE 3.0. Als dat niet het geval is, val je terug op standaard representment, waar het ingediende bewijs daadwerkelijk wordt gewogen. Dit artikel behandelt de vier data-elementen die Visa eist voor CE 3.0 en loopt vervolgens zes aanvullende bewijspunten langs die ertoe doen voor disputes die CE 3.0 niet dekt.
De regel, compact
CE 3.0 is van toepassing op Visa card-not-present disputes ingediend onder reason code 10.4 ("Other Fraud: Card-Absent Environment"). De merchant moet twee eerdere niet-betwiste transacties op dezelfde betaalgegevens aanleveren, elk tussen 120 en 365 dagen oud ten opzichte van de disputedatum. Minstens twee van vier kerndata-elementen (User ID, verzendadres, IP-adres of device ID) moeten overeenkomen in alle drie de transacties, en een van de twee moet IP-adres of device ID zijn.
Bron: Visa Compelling Evidence 3.0 Merchant Readiness document.
De vier data-elementen die Visa eist
CE 3.0-kwalificatie vereist dat minstens twee van vier data-elementen overeenkomen in alle drie de transacties (de betwiste en de twee eerdere niet-betwiste). Een van de twee moet IP-adres of device ID zijn.
- User ID-match. Het identificatienummer dat de merchant gebruikt voor het account van de kaarthouder. Moet consistent zijn in alle drie de transacties.
- Verzendadres-match. Afleveradres in alle drie de transacties. Kleine verschillen (appartementiummers, interpunctie) kunnen problematisch zijn; de meeste acquirers vereisen een exacte match.
- IP-adresmatch. IP vastgelegd op het moment van aankoop voor alle drie de transacties. ISP-niveau match is acceptabel voor de meeste uitgevers; exact adres is sterker.
- Device ID-match. Devicefingerprint vastgelegd bij checkout in alle drie de transacties. Moet uit dezelfde bron komen om als deterministisch te worden behandeld. Een browser fingerprint combineert tientallen niet-gevoelige signalen (schermresolutie, tijdzone, taalinstellingen) tot een stabiele hash die persisteert over sessies, incognitomodus en gewist geheugen.
Een vijfde veld, het primaire accountnummer (PAN), is het fundament. Hetzelfde PAN in alle drie de transacties is een voorwaarde, niet een van de vier te matchen elementen. Getokeniseerde PANs tellen als de tokenreferentie stabiel is over sessies.
Voorbij CE 3.0: zes bewijspunten voor disputes die niet kwalificeren
Als de dispute aan de CE 3.0-criteria voldoet, is de aansprakelijkheidsverschuiving automatisch. Je hebt niets meer nodig dan de vier verplichte data-elementen om te winnen.
Maar niet elke fraudedispute kwalificeert voor CE 3.0. De reason code is mogelijk niet 10.4, er zijn mogelijk geen twee eerdere niet-betwiste transacties in het venster van 120 tot 365 dagen, of de data-elementen matchen niet schoon genoeg. Voor die gevallen val je terug op standaard representment, waar de uitgever het bewijs weegt en een oordeel velt. Deze zes bewijspunten maken het verschil in dat proces:
- Descriptor first-6 consistentie. De eerste zes tekens van de facturatiedescriptor moeten identiek zijn zodat de acquirer ze behandelt als dezelfde merchant. Descriptor drift tussen initiele en terugkerende kosten is een van de meest voorkomende redenen waarom CE 3.0-kwalificatie faalt, en het verzwakt ook standaard representment.
- Authenticatierecord. Visa Secure of Visa Data Only gekoppeld aan de transactie. Bij standaard representment toont dit aan dat de kaarthouder zich heeft geauthenticeerd, wat de fraudeclaim ondermijnt. In een CE 3.0-context kan het auto-kwalificatie activeren.
- Leverings- of uitvoeringsbevestiging. Voor fysieke goederen, een trackingnummer en getekende leveringsbevestiging. Voor digitale goederen, een IP-gematchte sessie die toegang tot de content toont. Dit is standaard representmentbewijs dat direct tegenspreekt "ik heb dit niet ontvangen".
- Tijdspatroon eerdere transacties. Een transactiegeschiedenis die een plausibele klantrelatie toont, niet twee kunstmatig geclusterde aankopen. Bij standaard representment vestigt dit het patroon van legitiem gebruik van de kaarthouder.
- Sessiecontinueiteitssignalen. Bewijs dat dezelfde browsersessie of hetzelfde device werd gebruikt om te browsen, toe te voegen aan de winkelwagen en de betaling af te ronden. Dit koppelt de transactie aan een echte gebruikerssessie in plaats van een enkel datapunt bij checkout. Device fingerprinting gebouwd voor CE 3.0 kan dit type sessieniveau-continueteit native produceren.
- Disputeprofiel van de merchant. Een merchant met een schone disputegeschiedenis krijgt het voordeel van de twijfel bij standaard representment. Een merchant met een lang track record van omgekeerde zaken krijgt strenger onderzoek, zelfs met sterk bewijs.
Waar elk bewijspunt vandaan komt
User ID en verzendadres komen uit de orderdatabase. Facturatiedescriptor en authenticatie komen van de betalingsprocessor en 3DS-configuratie. IP-adres en device ID (de twee die bepalen of je kwalificeert voor CE 3.0) komen uit de checkoutsessie, en de meeste merchants leggen deze niet betrouwbaar vast.
Door Visa verplichte elementen:
| Data-element | Bron | Meestal vastgelegd bij representment? |
|---|---|---|
| PAN (voorwaarde) | Order-DB / betalingsprocessor | Ja |
| User ID | Order-DB | Ja |
| Verzendadres | Order-DB | Ja |
| IP-adres | Checkoutsessie | Soms (inconsistent) |
| Device ID | Checkoutsessie | Zelden (vereist instrumentatie) |
Aanvullende bewijspunten:
| Bewijspunt | Bron | Meestal vastgelegd bij representment? |
|---|---|---|
| Descriptor first-6 | Configuratie betalingsprocessor | Ja |
| Authenticatierecord | 3DS-flow | Ja waar 3DS actief |
| Uitvoering / levering | OMS / vervoerder | Ja |
| Tijdspatroon eerdere transacties | Order-DB + dispute response tool | Ja |
| Sessiecontinueteit | Checkoutsessie | Zelden (vereist instrumentatie) |
| Disputeprofiel | Acquirer | Impliciet |
IP-adres en device ID zijn waar de meeste representmentzaken falen op inhoud. Het zijn checkoutsessiedata, geen orderdatabasedata. Een server-side chargebacktool kan ze niet achteraf reconstrueren. Als de instrumentatie niet aanwezig was op het moment van aankoop, bestaan de data simpelweg niet.
De browserlaag-bewijsvereiste
Device ID en IP op CE 3.0-kwalificatiestandaard betekenen dezelfde device- en netwerksignatuur op de eerdere en betwiste transacties. Die signatuur wordt vastgelegd bij checkout, in de browser, op het moment dat de kaarthouder de betaling indient. Geen post-hocsysteem kan dit produceren.
Het Chargeback Evidence-product van cside legt de browserlaagdata vast bij checkout. De device-identiteit is stabiel over sessies bij dezelfde merchant, waardoor een eerdere transactie van acht maanden geleden deterministisch kan worden gematcht aan een betwiste transactie van vandaag. De vastgelegde IP is de IP die de kaarthouder daadwerkelijk gebruikte bij de aankoop, niet een later afgeleide IP.
Voor het bewijspakket als geheel sluit browserlaagcapture de twee verplichte velden die server-side tools niet kunnen (IP-adres en device ID) en versterkt het de leveringsbevestiging door uitvoeringstoegang te koppelen aan hetzelfde device. Het pakket dat aan de uitgever wordt gepresenteerd leest als een complete bewijsketen in plaats van een papierwerk-assemblage.
Wat dit operationeel betekent
Begin met auditen of je disputes kunnen kwalificeren voor CE 3.0. Als de vier verplichte data-elementen overeenkomen, is de aansprakelijkheidsverschuiving automatisch en hoef je geen breder dossier op te bouwen. De fix met de meeste impact is zorgen dat je daadwerkelijk IP en device ID kunt vastleggen bij checkout zodat meer disputes kwalificeren.
Voor disputes die buiten CE 3.0 vallen, audit de zes aanvullende bewijspunten. De goedkoopste fixes zijn descriptor first-6 alignement en 3DS-dekking. De meest impactvolle is browserlaag-bewijscapture, die sessieniveaudata geeft ter ondersteuning van standaard representment.
Een audit van dertig minuten:
- Trek tien recente reason code 10.4-disputes. Controleer voor elke dispute of je de vier door Visa verplichte data-elementen beschikbaar had. Hoeveel hadden kunnen kwalificeren voor CE 3.0 maar deden dat niet omdat IP of device ID ontbrak?
- Voor degene die niet kwalificeerden, controleer welke van de zes aanvullende bewijspunten je had kunnen indienen bij standaard representment. Het patroon is meestal duidelijk: device ID en IP zijn beide afwezig of van lage kwaliteit, en descriptor first-6 driftt tussen factureringscycli.
- Vergelijk je winratio op CE 3.0-gekwalificeerde disputes (die dicht bij 100% zou moeten liggen) met je standaard representment winratio. Het verschil vertelt je hoeveel omzet er op het spel staat in de disputes die CE 3.0 niet dekt.
Het 2025 Global Fraud and Payments Report van de Merchant Risk Council vond dat de meerderheid van de ondervraagde merchants nu het Compelling Evidence-programma gebruikt. De merchants bovenaan die groep zijn degenen die de browserlaag hebben geinstrumenteerd en meer disputes voor CE 3.0 kwalificeren. De merchants onderaan missen IP en device ID, wat minder automatische wins en zwakkere standaard representments betekent.
Veelgemaakte fouten
De drie meest voorkomende CE 3.0-fouten zijn descriptor drift tussen factureringscycli, vertrouwen op server-side IP-capture (die vaak de load balancer weergeeft in plaats van de client), en device fingerprints als opportunistisch behandelen. Elk van deze kan voorkomen dat een dispute kwalificeert voor CE 3.0, en elk verzwakt je positie bij standaard representment.
Descriptor drift. Betalingsprocessors herschrijven soms descriptors tussen initiiele en terugkerende transacties, of varieren ze per valuta. Zelfs een wijziging van een teken in de eerste zes breekt de kwalificatie.
Server-side IP-capture. Veel merchants loggen IP vanaf de server die de checkout-POST ontvangt, wat in moderne architecturen vaak een load balancer of CDN-edge registreert in plaats van de client. De IP moet client-side worden vastgelegd op browserlaagniveau om betrouwbaar te matchen.
Opportunistische device fingerprints. Een device fingerprint vastgelegd door een derdepartijscript dat toevallig laadt bij checkout is niet hetzelfde als een deterministische checkoutsessie-fingerprint. Als de merchant de fingerprinting-logica niet op verzoek kan reproduceren, kan de uitgever de match verwerpen.
Verder lezen bij cside
Over de auteur
Mike Kutlu is Head of GTM bij cside, waar hij samenwerkt met Heads of Payments, Risk en Finance aan het instrumenteren van browserlaag-chargebackbewijs voor Compelling Evidence 3.0-representment. Hij schrijft over VAMP, friendly fraud en de werking van disputebewijs voor enterprise merchants.
