3-D Secure status guide
1. Introductie
Ons platform communiceert in real-time met financiële instellingen.
Dit stelt ons ertoe in staat je onmiddellijk van een respons van jouw verwerver te voorzien voor jouw transactieverzoeken.
Behalve de algemene transactiestatus en de foutcodes kun je ook aanvullende informatie voor je transacties opzoeken in de zogenaamde "Virtual Ticket".
Het bevat gedetailleerde informatie die je kan helpen een follow-up uit te voeren voor transacties met jouw verwerver, met name voor geweigerde transacties (status 2 / 93).
2. Wat betekenen de 3-D Secure-statussen?
Naast duidelijk gedefinieerde uitsluitingen en uitzonderingen moeten jouw klanten ook allemaal een 3-D Secure-authenticatiecontrole doorlopen. De transactie krijgt zowel een 3-D Secure-status (die het resultaat is van de authenticatiecontrole) als een algemene transactiestatus (die het resultaat van het autorisatieverzoek aangeeft).
Beide zijn dus het resultaat van twee verschillende stappen:
- 3-D Secure-status: als eerste stap moet jouw klant bewijzen dat hij/zij de rechtmatige eigenaar is van de creditcard die voor de transactie wordt gebruikt. Deze authenticatiecontrole vindt plaats in het online portaal van de uitgever van jouw klant. Een overzicht van mogelijke resultaten is te vinden in ons Parameter cookbook
- Algemene transactiestatus: als tweede stap controleert jouw verwerver of er genoeg geld beschikbaar is voor de transactie door dit na te vragen bij de uitgever van jouw klant; dit resulteert in een geslaagde of mislukte autorisatie. Je vindt een overzicht van de mogelijke resultaten in onze transactiestatushandleiding
Je kunt de resultaten handmatig opzoeken in maar ook met onze Rapportering tool:
- Back Office: je kunt de transactie opzoeken via Transacties > Beheer transacties. Controleer in het overzicht “Status” (dit is de algemene transactiestatus) en de afbeelding in combinatie met een beschrijving (dit is de 3-D Secure-status)
De afbeelding laat zien waar je de 3-D Secure-status en de algemene transactiestatus kunt opzoeken in Back Office. - Rapportering: zorg ervoor dat je jouw -profiel configureert zoals beschreven in onze hieraan gewijde video. De parameters ECI / STATUS geven respectievelijk de 3-D Secure-status / algemene transactiestatus aan
Als je transacties verwerkt via e-Commerce, gebruikt ons platform automatisch Versie 1 voor je.
Als je transacties verwerkt via DirectLink, moet je zelf Versie 1 toepassen. Je kunt in het daaraan gewijde DirectLink hoofdstuk nalezen hoe dat werkt.
De onderstaande tabel geeft je een volledig overzicht van mogelijke scenario's en hoe ons platform ze elk voor je weergeeft:
| 3-D Secure-status (Back Office) | 3-D Secure-status (parameter ECI in Rapportering | Transactiestatus | Beschrijving |
|---|---|---|---|
| Duim helemaal omhoog/ "Cardholder has been successfully identified! V1" |
5 | Afhankelijk van het autorisatieresultaat van jouw verwerver is een van de volgende opties van toepassing 2 5 9 |
De klant heeft de autorisatiecontrole met succes doorlopen. Indien sprake is van frauduleuze terugboekingen, is de uitgever aansprakelijk |
| Duim half omhoog/ "Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)" |
6 12 |
Afhankelijk van het autorisatieresultaat van jouw verwerver is een van de volgende opties van toepassing 2 5 9 |
De klant kreeg niet de kans de autorisatiecontrole uit te voeren. Indien sprake is van frauduleuze terugboekingen, is de uitgever aansprakelijk |
| Uitroepteken/ "Cardholder authentication failed!" |
91 | 2 | De autorisatiecontrole van de klant is mislukt als gevolg van bijvoorbeeld een onjuist wachtwoord / een onjuiste PIN. Ons platform voert de autorisatiestap helemaal niet uit en breekt de transactie af |
| Geen afbeelding/ "Cardholder authentication not technically possible!!!" |
92 | Afhankelijk van het autorisatieresultaat van jouw verwerver en van jouw voorkeur is een van de volgende opties van toepassen 2 5 9 |
Authenticatie is niet mogelijk als gevolg van een technische fout. Ons platform voert de autorisatiestap standaard helemaal niet uit en breekt de transactie af (status 2). Ons platform staat je echter toe de autorisatie desondanks uit te voeren, zoals beschreven in het daaraan gewijde hoofdstuk. |
| Duim helemaal omhoog/ "Cardholder has been successfully identified! V2 challenge" |
5 | Afhankelijk van het autorisatieresultaat van jouw verwerver is een van de volgende opties van toepassing 2 5 9 |
De klant heeft de authenticatiecontrole met succes doorlopen en heeft zichzelf actief geïdentificeerd volgens het SCA-protocol ("controlestroom"). Indien sprake is van frauduleuze terugboekingen, is de uitgever aansprakelijk |
| Duim helemaal omhoog/ “Cardholder has been successfully identified! V2 frictionless” |
5 | Afhankelijk van het autorisatieresultaat van jouw verwerver is een van de volgende opties van toepassing 2 5 9 |
De klant heeft de autorisatie met succes doorlopen. Aangezien je oldoende informatie hebt verstrek bij de transactie volgens het SCA-protocol, hoefde de klant zichzelf niet actief te identificeren ("wrijvingsloze stroom") |
Denk eraan dat dit niet meer is dan een indicatie, aangezien de definitieve verantwoordelijkheid afhankelijk is van diverse factoren
3. Wat vind je in het authenticatielogboek?
Ons platform weet niet alleen de 3-D Secure-status voor jouw transacties, het slaat ook logboekbestanden op voor elke authenticatiecontrole. Deze bestanden bevatten gedetailleerde informatie over de precieze stroom die leidt tot het resultaat van de authenticatiecontrole.
Je kunt deze informatie voor elke transactie opzoeken in Back Office via Transacties > Beheer transacties. Klik op "AUTHENTICATION LOG" in het overzicht om een tabeloverzicht te openen. Elke regel vertegenwoordigt één afzonderlijke stap van een volledige authenticatiecontrole.
| Kolom | Beschrijving |
|---|---|
| MsgType |
Uitgevoerde stap van de huidige authenticatiecontrole.
Als ons platform 3-D Secure versie 1 moest gebruiken, zijn de volgende waarden mogelijk:
|
| Status |
Status / resultaat van de uitgevoerde stap.
Als ons platform 3-D Secure versie 1 moest gebruiken, zijn de volgende waarden mogelijk:
|
| Date |
Tijdstempel van de uitgevoerde stap |
| Details |
Informatie / parameters van de uitgevoerde stap.
|
| Card N° |
De kaart die tijdens de respectieve stap is gebruikt |
De afbeelding laat zien waar je de authenticatiestatus kunt opzoeken in Back Office
De afbeelding laat een typische tabel in Back Office zien die authenticatielogboeken bevat
Het begrijpen en afhandelen van uitwijking naar 3-D Secure v1
Het is mogelijk dat ons platform transacties in de modus 3-D Secure v 1 verwerkt (controleer de kolom "MsgType" in het authenticatielogboek). Houd deze goed in de gaten, aangezien v1 in oktober 2022 volledig buiten werking zal worden gesteld. Werp een blik op de onderstaande tabel met mogelijke oorzaken en oplossingen om je te helpen omgaan met dit soort transacties:
| Foutmelding (kolom "MsgType") | Beschrijving | Oplossing |
|---|---|---|
| V2ParamMissing | Ontbrekende verplichte v2-parameters | Zorg ervoor dat je jouw DirectLink integratie navenant bijwerkt. Als je transacties via onze e-Commerce oplossing verwerkt, doen wij dit voor je |
| acquirerBIN/acquirerMerchantID not recognized | Je moet v2 gebruiken bij MasterCard | Neem contact op met jouw verwerver of met ons om dit aan te vragen |
| "Detail":"billAddrCountry; V2Error caused fallback to v1 "Detail":"billAddrLine1,billAddrLine2 "Detail":"cardholderName; "Detail":"email; "Detail":"acctNumber; "Detail":"browserLanguage" "Detail":"acctInfo.nbPurchaseAccount,acctInfo.txnActivityDay,acctInfo.txnActivityYear" "Detail":"Name(s) of erroneous fields separated by (,) : acctInfo.suspiciousAccActivity,threeDSRequestorAuthenticationInfo.threeDSReqAuthMethod, acctInfo.shipAddressUsageInd,acctInfo.chAccAgeInd,acctInfo.shipNameIndicator,acctInfo.paymentAccAge,acctInfo.paymentAccInd,acctInfo.shipAddressUsage" |
Er is een foutmelding ontvangen van de directoryserver. De ISO-code is niet geldig volgens de ISO-tabellen (voor de landcode of voor de valutacode) |
Er zijn ongeldige parameters verzonden voor verplichte v2-) parameters Zorg ervoor dat je jouw DirectLink integratie navenant bijwerkt |
| Error received from the DS. Format of one or more elements is invalid according to the specification","Detail":"threeDSRequestorURL" | De gegevens die voor jouw website in Back Office staan, zijn onjuist (Configuratie > Abonnement > Uw administratieve gegevens > Website-adres) |
Corrigeer jouw URL in Back Office |
| Specific reason fallbacks to V1 because transaction status will be blocked by issuer MC Fallback to V1 since Transaction status reason is 82 Cb Fallback to V1 since Transaction status reason is 13 |
Er zijn niet-gespecificeerde fouten opgetreden |
Deze fouten zijn opgetreden bij derden, er is niets wat jij kunt doen om dit op te lossen |
4. De transactiestroom voortzetten / onderbreken
In navolging van de PSD2-richtlijnen, krijgen transacties waarvoor dankzij technische problemen geen authenticatiecontrole kan worden uitgevoerd, standaard status 2. Ons platform onderbreekt de transactie door de autorisatie helemaal niet uit te voeren..
Je kunt dit standaardscenario echter overschrijven door je platform de instructie te geven desondanks met de autorisatiestap door te gaan. Ga als volgt te werk om deze optie te gebruiken:
- Meld je aan bij de Back Office. Ga naar Geavanceerd > Fraudedetecie > 3D-Secure
- Selecteer de betalingsmethode waarvoor je het standaardscenario wilt overschrijven door op “WIJZIG”
- Selecteer het keuzerondje “Voortzetten” voor zowel “De transactie voortzetten/onderbreken, indien door een technisch probleem geen verbinding gemaakt kan worden met de MasterCard directory tijdens de controle van de 3D-Secure registratie.” als“De transactie voortzetten/onderbreken, indien het identificatiesysteem van de kaartuitgever tijdelijk niet beschikbaar is”. Bevestig door op “VERSTUREN”
De afbeelding laat zien waar u de voortzetten/ onderbreekfunctie in de Back Office kunt configureren
- Als je deze optie gebruikt, kun je verantwoordelijk worden gehouden voor frauduleuze terugboekingen
- Er is een sterke waarschijnlijkheid dat je transactie nog steeds status 2 bereikt, aangezien iedereen sinds PSD2 een authenticatiecontrole moet doorstaan as per PSD2 every online shopper must pass an authentication check
-
5. Gedeeltelijke beëindiging van aansprakelijkheidsverschuiving
Alle onderstaande belangrijke systemen hebben de beslissing genomen om 3DS v1 officieel uit gebruik te nemen in oktober 2022:
- VISA
- Mastercard
- American Express
- JCB
- Diners Discover
VISA en Mastercard hebben al een overgangsperiode naar EMV 3DS aangekondigd.
In hoofdzaak betekent dit dat alleen volledig geauthenticeerde transacties door zowel VISA als Mastercard zullen worden ondersteund, waardoor handelaars die nog met 3DS v1 werken minder beschermd zullen zijn voor fraudeaansprakelijkheid.
In het Back Office zal het volgende vermeld staan: "Kaarthouder niet geïdentificeerd: toepassing van regels inzake aansprakelijkheidsverschuiving (afhankelijk van transactiedatum en land van de kredietkaart)", en ECI=12 bij de feedback na verkoop.
Bij ditzelfde bericht "Kaarthouder niet geïdentificeerd: toepassing van regels inzake aansprakelijkheidsverschuiving (afhankelijk van transactiedatum en land van de kredietkaart)" en ECI=6 is de aansprakelijkheidsverschuiving wel nog steeds van toepassing.
Visa
| Visa Secure 3DS V1 | Vóór 16 oktober 2021 | Na 16 oktober 2021 |
|---|---|---|
| Volledig geauthenticeerd (deelnemende uitgever) | Fraudeaansprakelijkheid verschuift naar de uitgever (ECI=5) | Geen wijziging |
| Poging tot authenticatie (niet-deelnemende uitgever) | Fraudeaansprakelijkheid verschuift naar de uitgever (ECI=12) | Fraudeaansprakelijkheid ligt bij de handelaar (ECI=12) Deelnameresultaat=N |
Mastercard
| Mastercard Identity Check 3DS V1 | Vóór 16 oktober 2021 | Na 16 oktober 2021 |
|---|---|---|
| Volledig geauthenticeerd (deelnemende uitgever) | Fraudeaansprakelijkheid verschuift naar de uitgever (ECI=5) | Geen wijziging |
| Poging tot authenticatie (niet-deelnemende uitgever) | Fraudeaansprakelijkheid verschuift naar de uitgever (ECI=12) | Fraudeaansprakelijkheid ligt bij de handelaar (ECI=12) Deelnameresultaat=N |