Software 3D Secure Integration Guide Documentation
Integratiegids 3D Secure
Vanaf 01.01.2021 januari XNUMX wordt tweefactorauthenticatie geïmplementeerd als een verplichte vereiste voor alle e-commercekaartbetalingstransacties. Om aan deze verplichting te voldoen, heeft de
exploitanten van creditcardnetwerken zullen gebruik maken van de zogenaamde 3D Secure-procedure. Voor u als webwinkelier is het verplicht om deze procedure voor uw klanten uit te kunnen voeren
01.01.2021. Hieronder vindt u een beschrijving van de verschillende manieren van integratie en hoe de 3D Secure-procedure daarvoor moet worden geïmplementeerd.
Selecteer de integratiemethode die u gebruikt
- Maakt u gebruik van het afrekenformulier hCO?
- Maakt u gebruik van het afrekenformulier hPF?
- Verwerkt u betalingen zonder gebruik te maken van een formulier van het Unzer-systeem?
Let op: Ook is het van belang op welke wijze afschrijvingen of pre-autorisaties (reserveringen) plaatsvinden. Zelfs als u voor de registratie van kaartgegevens een betalingsformulier van Unzer GmbH gebruikt, wordt het 3D Secure-proces zonder afrekenformulier uitgevoerd wanneer de kaartgegevens voor de eerste keer worden afgeschreven of geautoriseerd. In dit geval is de derde manier van integratie zonder formulier van Unzer van toepassing.
Let ook op:
Als u gebruikmaakt van terugkerende betalingen (abonnementsbetalingen), lees dan zeker het hoofdstuk “3D Veilige en Terugkerende Betalingen”.
3D Veilige procedure bij gebruik van het hCO-afrekenformulier
Het hCO-afrekenformulier is al ontworpen voor de 3D Secure-procedure. Er is geen aanvullende actie van uw kant nodig voor de uitvoering van de procedure. Echter, jij
moeten ervoor zorgen dat uw systeem de overeenkomstige antwoorden van ons betalingssysteem kan verwerken in het geval dat het 3D Secure-proces wordt gestart. In de asynchrone reactie van de
betalingssysteem naar uw server, het resultaat van de transactie wordt verzonden en moet daar worden geëvalueerd voordat het wordt geretourneerd URL wordt doorgegeven aan het betalingssysteem.
Hiervoor moeten de volgende parameters worden geëvalueerd.
- VERWERKING.RETOUR.CODE = 000.200.000
- PROCESSING.RETURN = Transactie+in behandeling
- VERWERKING.RESULTAAT = ACK
Toelichting: De status van de transactie is “pending”, de parameter PROCESSING.RESULT
vertegenwoordigt slechts een voorlopig resultaat. Zolang het 3D Secure-proces wordt uitgevoerd, blijft de status
blijven in behandeling.
Het uiteindelijke resultaat van de transactie is dan een van beide
- VERWERKING.RETOUR.CODE = 000.000.000
- VERWERKING.RESULTAAT = ACK
or - PROCESSING.RETOUR.CODE = irgendein Wert ungleich 000.000.000 of 000.200.000
- VERWERKING.RESULTAAT = NOK
In het eerste geval is de transactie succesvol afgerond, in het tweede geval is de transactie globaal mislukt. Dit laatste kan verschillende redenen hebben, waaronder een weigering tot authenticatie. Je zal
ontvang meer gedetailleerde informatie in de parameters “PROCESSING.RETURN” en “PROCESSING.RETURN.CODE”.
We raden u aan een test voor beide berichten uit te voeren. Hieronder vindt u meer informatie over hoe u een test doet en welke creditcardgegevens u voor een test kunt gebruiken.
3D Secure-procedure bij gebruik van het hPF-afrekenformulier
Het hPF-afrekenformulier is ook ontworpen om de 3DS-procedure al te gebruiken. Er is geen aanvullende actie van uw kant nodig voor de uitvoering van de procedure. Zoals beschreven
bij de hCO-implementatie vindt de reactie van het betalingssysteem plaats in twee stappen, daarom moet uw systeem de waarde van de PROCESSING.RETURN.CODE controleren
parameter bij het verwerken van het antwoord.
Hiervoor moeten de volgende parameters worden geëvalueerd.
- VERWERKING.RETOUR.CODE = 000.200.000
- PROCESSING.RETURN = Transactie+in behandeling
- VERWERKING.RESULTAAT = ACK
Toelichting: De status van de transactie is “pending”, de parameter PROCESSING.RESULT vertegenwoordigt slechts een voorlopig resultaat. Zolang het 3D Secure-proces wordt uitgevoerd, blijft de status
blijven in behandeling.
Het uiteindelijke resultaat van de transactie is dan een van beide
- VERWERKING.RETOUR.CODE = 000.000.000
- VERWERKING.RESULTAAT = ACK
or - PROCESSING.RETOUR.CODE = irgendein Wert ungleich 000.000.000 of 000.200.000
- VERWERKING.RESULTAAT = NOK
In het eerste geval is de transactie succesvol afgerond, in het tweede geval is de transactie globaal mislukt. Dit laatste kan verschillende redenen hebben, waaronder een weigering tot authenticatie. Je zal
ontvang meer gedetailleerde informatie in de parameters “PROCESSING.RETURN” en “PROCESSING.RETURN.CODE”.
We raden u aan een test voor beide berichten uit te voeren. Hieronder vindt u meer informatie over hoe u een test doet en welke creditcardgegevens u voor een test kunt gebruiken.
3D Secure-procedure met directe verbinding
Als u geen door Unzer (voorheen heidelpay) verstrekt betalingsformulier gebruikt om creditcardbetalingen te verwerken, of als u eenvoudigweg een kaart registreert met behulp van een van de formulieren en de pre-autorisatie (reservering) of afschrijving verwerkt als verwijzing naar de registratie als een directe communicatie met het betalingssysteem, moet u het 3D Secure-proces implementeren.
Asynchrone transactiestroom:
Dit is een asynchroon proces waarbij uw server een forwarding ontvangt URL (Omleiding URL) van ons betalingssysteem. Uw server moet de klant hiernaar doorsturen URL zodat hij de authenticatie via de 3D Secure-procedure kan uitvoeren. Het resultaat van deze 3D Secure-authenticatie wordt door de kaartuitgevende bank rechtstreeks aan Unzer gerapporteerd.
Na succesvolle authenticatie wordt de transactie verder verwerkt in het Unzer-systeem op de manier die u al kent, door uw systeem aan het einde een totaalresultaat te sturen, waarop u antwoordt
met een omleiding URL. Het betalingssysteem zal de klant vervolgens via deze omleiding terugsturen naar uw systeem URL Van uw systeem
Let op: In deze workflow ontvangt uw systeem twee antwoorden van het betalingssysteem:
– Eén met de status “pending” (PROCESSING.RETURN.CODE=000.200.000 en PROCESSING.RETURN=Transaction+pending) en de redirectparameters naar de kaartuitgevende bank van de klant
– Eén met het eindresultaat van de afschrijving of reservering. Er zijn ook twee omleidingen URLDe stappen die in dit proces worden genoemd, zijn één van het betalingssysteem waarnaar de klant moet worden doorgestuurd om zich te authenticeren bij de bank die zijn kaart heeft uitgegeven, en één van uw systeem, wanneer u het eindresultaat ontvangt, om de klant terug naar uw systeem te leiden.
In de reguliere procedure worden de volgende wijzigingen aangebracht. Houd er rekening mee dat als gevolg van de implementatie van andere asynchrone betaalmethoden, zoals Paypal, sommige hiervan
Het kan zijn dat er al processen bestaan in uw implementatie.
- Antwoord URL
Bij de eerste oproep (nr. 2 in het diagram) naar het betalingssysteem wordt een “Response URL” moet worden doorgegeven in de frontendgroep.
Let op: De parameter IDENTIFICATION.REFERENCEID is alleen relevant als u verwijst naar een registratie of andere reeds bestaande transactie - Omleiding verwerken URL Als authenticatie vereist is, wordt er omgeleid URL en andere parameters in de omleidingsgroep worden overgedragen in het antwoord van het betalingssysteem (nr. 5 in het diagram).
- Doorsturen van de klant naar de redirect URL
Als de omleidingsgroep reageert met een omleiding URL, moet de browser van de klant hiernaar worden doorverwezen URL (nr. 6 in het diagram) om authenticatie uit te voeren. De aanvullende parameters van de omleidingsgroep moeten naar de externe worden overgebracht website als POST-parameters.
Let op: Extra parameters worden alleen geretourneerd in de groep “PROCESSING.REDIRECT.xxx” met 3D Secure Versie 1 (zelfs daar kunnen het nummer en de naam variëren), terwijl met 3D Versie 2 alleen een PROCESSING.REDIRECT wordt weergegeven.URL zoals hieronder weergegeven wordt geretourneerd: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF/run Dit betekent dat, ongeacht het type en aantal parameters, de clientbrowser moet omleiden naar PROCESSING.REDIRECT.URL.
Hieronder vindt u een eenvoudige code, bijvamphoe een dergelijke omleiding kan worden uitgevoerd. De deel is bedoeld om eindklanten te informeren wiens systemen Javascript niet ondersteunen of hebben uitgeschakeld. We raden ten zeerste aan dat de omleiding plaatsvindt binnen het actieve browservenster van de klant en dat er geen gebruik wordt gemaakt van pop-upvensters of nieuwe browservensters, aangezien dit
klanten irriteren en ertoe leiden dat ze de pagina sluiten waarnaar ze worden doorverwezen.
- Asynchrone resultaatcontrole
Het resultaat van de authenticatie wordt asynchroon naar uw server verzonden. Het betalingssysteem verwacht een geldige URL als reactie. (Nr. 12 en 13 in het diagram). Voor succesvol of afgewezen
betalingen, anders URL kan hier door uw systeem worden beantwoord. - Retourpad van de klant
Het betalingssysteem verwijst de klant door naar de URL verstrekt door het systeem van de handelaar nadat het authenticatieproces en de betalingstransactie zijn voltooid.
Let op: Stappen 4.) en 5.) verlopen op precies dezelfde manier als u al bekend bent bij bestaande NONE 3D Secure-transacties.
3D Veilige en terugkerende betaling
Vanaf 1 januari 2021 is 3D Secure verplicht voor alle e-commerce kaarttransacties. Omdat dit bij terugkerende betalingen echter nauwelijks van toepassing is, is het bankwezen
systemen hebben hiervoor een aparte workflow.
Voor dit doel maken de banken onderscheid tussen
- CIT = door de klant geïnitialiseerde transacties
- MIT = door de verkoper geïnitialiseerde transacties
De eerste transactie van een kaart in uw verkopersaccount moet vanaf 3 worden geauthenticeerd met 01.01.2021D Secure. Een dergelijke succesvolle authenticatie is een verplichte vereiste in
om vervolgens zonder 3D Secure verdere boekingen op dezelfde kaart te kunnen plaatsen. De klant moet daarom voor de eerste afschrijving worden doorgestuurd naar de bank die zijn kaart heeft uitgegeven
volgens de hierboven beschreven procedure en authenticeert hij zich daar als kaarthouder. Als er op het moment van de bestelling geen afschrijving gepland is, bijvampVanwege een proefperiode moet in plaats daarvan een reservering (pre-autorisatie) van minimaal één euro worden gemaakt bij 3D Secure in aanwezigheid van de klant. Het vastleggen van deze reservering is niet nodig.
Voor bestaande klanten hoeft er echter geen 3D Secure-authenticatie te worden opgemaakt. Als de eerste succesvolle afschrijving vóór 01.01.2021 heeft plaatsgevonden, kan er ook van worden uitgegaan dat het klantrecord
zijn succesvol geverifieerd. Voor nieuwe klanten vanaf 01.01.2021 is 3D Secure-authenticatie daarentegen verplicht bij de eerste afschrijving of reservering (pre-autorisatie).
Let op: Hierbij kijkt het banksysteem naar de kaartgegevens, niet naar de klantgegevens. Dus als een bestaande klant na 01.01.2021 bijvoorbeeld een nieuwe kaart gebruiktample omdat de vorige
één is verlopen of omdat hij van bank is veranderd die zijn kaart heeft uitgegeven, dit is een nieuwe terugkerende cyclus vanuit het oogpunt van de bank view en moet voor de eerste boeking worden geverifieerd bij 3D Secure.
Zodra deze initiële authenticatie succesvol is uitgevoerd, zijn alle verdere transacties vrijgesteld van de verplichting om 3D Secure te gebruiken. De voorwaarden voor terugkerende betaling zonder 3D Secure zijn daarom:
- Er is minimaal één succesvolle afschrijving of reservering (pre-autorisatie) die ofwel met 3D Secure is uitgevoerd of vóór 01.01.2021 heeft plaatsgevonden.
- er wordt verwezen naar een bestaande registratie en wordt bij indiening afgeschreven
Om het betalingssysteem te laten weten dat het om een terugkerende betaling gaat, moet de parameter RECURRENCE.MODE=REPEATED meegestuurd worden. Dit geeft aan het systeem door dat a
terugkerende betalingen moeten aan de banksystemen worden gerapporteerd.
Let op: Als de parameter RECURRENCE.MODE=REPEATED wordt ingevoerd wanneer een nieuwe kaart voor de eerste keer wordt geladen, wordt ondanks deze parameter een 3D Secure-doorsturing uitgevoerd.
Testen van de 3D Secure-implementatie
Via ons betaalsysteem kunt u de 3D Secure verbinding op ieder moment testen. Om dit te doen, gebruikt u de “CONNECTOR_TEST”-modus voor een transactie, zoals weergegeven in voorbeeldamples hierboven.
Verbindingsgegevens voor deze test:
| BEVEILIGING.AFZENDER | 31HA07BC8142C5A171745D00AD63D182 |
| GEBRUIKER LOGIN | 31ha07bc8142c5a171744e5aef11ffd3 |
| GEBRUIKER.PWD | 93167DE7 |
| TRANSACTIE.KANAAL | 31HA07BC8142C5A171749A60D979B6E4 |
| Valuta's geconfigureerd voor 3D versie 2 | EUR, USD, SEK |
| Valuta's geconfigureerd voor 3D versie 1 | GBP, CZK, CHF |
Het eindpunt van de systeemgateway is een van beide
SGW-gateway:
– https://test-heidelpay.hpcgw.net/sgw/gtw – Latin-15 gecodeerd
– https://test-heidelpay.hpcgw.net/sgw/gtwu – UTF-8 gecodeerd
NGW-gateway:
– https://test-heidelpay.hpcgw.net/ngw/post
Creditcardgegevens voor deze test:
| merken | kaartnummers | CVV | vervaldatum | opmerking |
| MasterCard | 5453010000059543 | 123 | toekomstige datum | 3D – wachtwoord: geheim3 |
| Visa | 4711100000000000 | 123 | toekomstige datum | 3DS – wachtwoord: geheim!33 |
Let op: Voor 3D Secure Versie 2 hoeft u geen wachtwoord in te voeren, maar klikt u eenvoudig op de link 'Klik hier om de authenticatie te voltooien.
De enige manier om een fout te simuleren met 3D Secure Versie 2 is door de pagina met de link een time-out te geven (ca. 18 minuten).
Lees meer over deze handleiding en download PDF:
Documenten / Bronnen
 |
Software 3D Secure Integratiehandleiding [pdf] Documentatie Unzer, Integratiegids, 3D Secure |
