Softwares 3D Secure Integration Guide Dokumentation
Integrationsguide 3D Secure
Från och med 01.01.2021-XNUMX-XNUMX kommer tvåfaktorsautentisering att implementeras som ett obligatoriskt krav för alla transaktioner med e-handelskort. För att uppfylla denna skyldighet måste
operatörer av kreditkortsnätverk kommer att använda den så kallade 3D Secure-proceduren. För dig som handlare är det obligatoriskt att kunna utföra denna procedur för dina kunder fr.o.m
01.01.2021. I det följande hittar du en beskrivning av de olika sätten att integrera och hur 3D Secure-proceduren måste implementeras för dem.
Välj den integrationsmetod du använder
- Använder du kassaformuläret hCO?
- Använder du kassaformuläret hPF?
- Behandlar du betalningar utan att använda ett formulär från Unzer-systemet?
Observera: Det är också viktigt på vilket sätt debiteringar eller förauktorisationer (reservationer) görs. Även om du använder ett betalningsformulär från Unzer GmbH för registrering av kortdata, kommer 3D Secure-processen att utföras utan kassaformulär när kortdata debiteras eller auktoriseras för första gången. I det här fallet gäller det tredje sättet att integrera utan ett formulär från Unzer.
Observera även:
Om du använder återkommande betalningar (prenumerationsbetalningar), se till att läsa avsnittet "3D Säker och återkommande betalning".
3D Säker procedur när du använder hCO-utcheckningsformuläret
HCO-utcheckningsformuläret är redan utformat för 3D Secure-proceduren. Det behövs inga ytterligare åtgärder från din sida för att genomföra proceduren. Men du
måste se till att ditt system kan hantera motsvarande svar från vårt betalningssystem om 3D Secure-processen startas. I det asynkrona svaret från
betalningssystem till din server, resultatet av transaktionen överförs och måste utvärderas där innan en retur URL överförs till betalningssystemet.
För detta ändamål måste följande parametrar utvärderas.
- BEHANDLING.RETURN.KOD = 000.200.000
- PROCESSING.RETURN = Transaktion+väntande
- BEHANDLING.RESULTAT = ACK
Förklaring: Transaktionens status är "väntande", parametern BEHANDLING.RESULTAT
representerar endast ett preliminärt resultat. Så länge 3D Secure-processen utförs, status
förbli väntande.
Det slutliga resultatet av transaktionen är då antingen
- BEHANDLING.RETURN.KOD = 000.000.000
- BEHANDLING.RESULTAT = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 eller 000.200.000
- BEHANDLING.RESULTAT = NOK
I det första fallet har transaktionen slutförts framgångsrikt, i det andra fallet har den totalt sett misslyckats. Det senare kan ha olika skäl, inklusive en vägran att autentisera. Du kommer
få mer detaljerad information i parametrarna "BEHANDLING.RETURNERING" och "BEHANDLING.RETURN.KOD".
Vi rekommenderar att du kör ett test för båda meddelandena. För mer information om hur du gör ett test och vilka kreditkortsuppgifter du kan använda för ett test, se nedan.
3D Säker procedur när du använder hPF kassaformuläret
hPF-utcheckningsformuläret är också utformat för att redan använda 3DS-proceduren. Det behövs inga ytterligare åtgärder från din sida för att genomföra proceduren. Som beskriven
för hCO-implementeringen sker svaret från betalningssystemet i två steg, varför ditt system måste kontrollera värdet på PROCESSING.RETURN.CODE
parameter vid bearbetning av svaret.
För detta ändamål måste följande parametrar utvärderas.
- BEHANDLING.RETURN.KOD = 000.200.000
- PROCESSING.RETURN = Transaktion+väntande
- BEHANDLING.RESULTAT = ACK
Förklaring: Transaktionens status är "väntande", parametern BEHANDLING.RESULTAT representerar endast ett preliminärt resultat. Så länge 3D Secure-processen utförs, status
förbli väntande.
Det slutliga resultatet av transaktionen är då antingen
- BEHANDLING.RETURN.KOD = 000.000.000
- BEHANDLING.RESULTAT = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 eller 000.200.000
- BEHANDLING.RESULTAT = NOK
I det första fallet har transaktionen slutförts framgångsrikt, i det andra fallet har den totalt sett misslyckats. Det senare kan ha olika skäl, inklusive en vägran att autentisera. Du kommer
få mer detaljerad information i parametrarna "BEHANDLING.RETURNERING" och "BEHANDLING.RETURN.KOD".
Vi rekommenderar att du kör ett test för båda meddelandena. För mer information om hur du gör ett test och vilka kreditkortsuppgifter du kan använda för ett test, se nedan.
3D Säker procedur med direktanslutning
Om du inte använder ett betalningsformulär från Unzer (tidigare heidelpay) för att behandla kreditkortsbetalningar, eller om du helt enkelt registrerar ett kort med hjälp av ett av formulären och behandlar förauktorisationen (bokningen) eller debiteringen som en referens till registreringen som en direkt kommunikation med betalningssystemet måste du implementera 3D Secure-processen.
Asynkront transaktionsflöde:
Detta är en asynkron process där din server tar emot en vidarebefordran URL (Dirigera om URL) från vårt betalningssystem. Din server måste vidarebefordra kunden till detta URL så att han kan utföra autentiseringen via 3D Secure-proceduren. Resultatet av denna 3D Secure-autentisering rapporteras direkt till Unzer av den kortutfärdande banken.
Efter lyckad autentisering bearbetas transaktionen vidare i Unzer-systemet på det sätt du redan känner till genom att ditt system skickas ett övergripande resultat i slutet, som du svarar på
med en omdirigering URL. Betalningssystemet omdirigerar sedan kunden tillbaka till ditt system med denna omdirigering URL från ditt system
Observera: I detta arbetsflöde får ditt system två svar från betalningssystemet:
– En med statusen “väntande” (BEHANDLING.RETURN.CODE=000.200.000 och PROCESSING.RETURN=Transaktion+väntande) och omdirigeringsparametrarna till kundens kortutfärdande bank
– En med det slutliga resultatet av debiteringen eller reservationen. Det finns också två omdirigeringar URLs som nämns i denna process, en från betalningssystemet som kunden måste omdirigeras till för att autentisera hos sin kortutgivande bank och en från ditt system, när du tar emot det slutliga resultatet, för att omdirigera kunden tillbaka till ditt system.
Följande ändringar kommer att göras i det ordinarie förfarandet. Observera att på grund av implementeringen av andra asynkrona betalningsmetoder, såsom Paypal, några av dessa
processer kanske redan finns i din implementering.
- Svar URL
I det första samtalet (nr 2 i diagrammet) till betalningssystemet, ett "Svar URL” måste godkännas i frontend-gruppen.
Observera: Parametern IDENTIFICATION.REFERENCEID är endast relevant om du hänvisar till en registrering eller annan redan existerande transaktion - Bearbetar omdirigering URL Om autentisering krävs, en omdirigering URL och andra parametrar i omdirigeringsgruppen överförs i svaret från betalningssystemet (nr 5 i diagrammet).
- Vidarebefordran av kunden till omdirigeringen URL
Om omdirigeringsgruppen svarar med en omdirigering URL, måste kundens webbläsare omdirigeras till denna URL (nr 6 i diagrammet) för att utföra autentisering. De ytterligare parametrarna från omdirigeringsgruppen måste överföras till den externa webwebbplats som POST-parametrar.
Observera: Ytterligare parametrar returneras i gruppen "PROCESSING.REDIRECT.xxx" endast med 3D Secure Version 1 (även där kan numret och namngivningen variera), medan med 3D Version 2 endast en PROCESSING.REDIRECT.URL som visas nedan returneras: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF/run Detta innebär att oavsett typ och antal parametrar måste klientwebbläsaren omdirigera till PROCESSING.REDIRECT.URL.
Nedan hittar du en enkel kod exampinformation om hur en sådan omdirigering kan utföras. De delen är avsedd att informera slutkunder vars system inte stöder Javascript eller har det inaktiverat. Vi rekommenderar starkt att omdirigeringen görs inom kundens aktiva webbläsarfönster och att inte använda popup-fönster eller nya webbläsarfönster, eftersom detta kan
irritera kunderna och få dem att stänga sidan de omdirigeras till.
- Asynkron resultatkontroll
Resultatet av autentiseringen skickas asynkront till din server. Betalningssystemet förväntar sig en giltig URL som svar. (Nr 12 & 13 i diagrammet). För framgångsrik eller avvisad
betalningar, en annan URL kan besvaras här av ditt system. - Returväg för kunden
Betalningssystemet omdirigerar kunden till URL tillhandahålls av handlarens system efter att autentiseringsprocessen och betalningstransaktionen har slutförts.
Observera: steg 4.) och 5.) fortsätt på exakt samma sätt som du redan är bekant med i befintliga NONE 3D Secure-transaktioner.
3D säker och återkommande betalning
Från den 1 januari 2021 kommer 3D Secure att vara obligatoriskt för alla e-handelskorttransaktioner. Men eftersom detta knappast är tillämpligt för återkommande betalningar, har banken
system har ett separat arbetsflöde för detta.
För detta ändamål skiljer bankerna mellan
- CIT = kundinitierade transaktioner
- MIT = handlarens initierade transaktioner
Den första transaktionen av ett kort på ditt handlarkonto måste autentiseras med 3D Secure från 01.01.2021-XNUMX-XNUMX och framåt. En sådan framgångsrik autentisering är ett obligatoriskt krav i
för att i efterhand kunna lämna in ytterligare bokningar på samma kort utan 3D Secure. Kunden måste därför vidarebefordras till sin kortutgivande bank för första debiteringen in
i enlighet med förfarandet som beskrivs ovan och autentisera sig där som kortinnehavare. Om en debitering inte är planerad vid beställningstillfället, t.example på grund av en provperiod måste en reservation (förauktorisation) på minst en euro göras med 3D Secure i kundens närvaro istället. Det är inte nödvändigt att fånga denna reservation.
För befintliga kunder behöver dock ingen 3D Secure-autentisering göras. Om den första lyckade debiteringen ägde rum före 01.01.2021-XNUMX-XNUMX, kan kundposten också antas vara
har autentiserats. För nya kunder från och med 01.01.2021-3-XNUMX, å andra sidan, är XNUMXD Secure-autentisering obligatorisk för den första debiteringen eller reservationen (förauktorisation).
Observera: I detta avseende tittar banksystemet på kortdata, inte kunddata. Så om en befintlig kund använder ett nytt kort efter 01.01.2021-XNUMX-XNUMX, t.example eftersom den föregående
en har gått ut eller för att han har bytt kortutgivande bank är detta en ny återkommande cykel från bankernas synpunkt view och måste autentiseras med 3D Secure för första bokningen.
När denna första autentisering väl har genomförts är alla ytterligare transaktioner undantagna från skyldigheten att använda 3D Secure. Förutsättningarna för återkommande betalning utan 3D Secure är därför:
- Det finns minst en lyckad debitering eller reservation (förauktorisation) som antingen utfördes med 3D Secure eller ägde rum före 01.01.2021-XNUMX-XNUMX.
- den hänvisas till en befintlig registrering och debitering vid inlämnandet
För att meddela betalningssystemet att detta är en återkommande betalning måste parametern RECURRENCE.MODE=REPEATED skickas också. Detta signalerar till systemet att a
återkommande betalning ska rapporteras till banksystemen.
Observera: Om parametern RECURRENCE.MODE=REPEATED anges när ett nytt kort laddas för första gången, kommer 3D Secure forwarding att utföras trots denna parameter.
Testar implementeringen av 3D Secure
Du kan testa 3D Secure-anslutningen när som helst via vårt betalningssystem. För att göra det, använd läget "CONNECTOR_TEST" för en transaktion, som visas i examples ovan.
Anslutningsdata för detta test:
| SÄKERHET.AVSÄNDARE | 31HA07BC8142C5A171745D00AD63D182 |
| ANVÄNDARNAMN | 31ha07bc8142c5a171744e5aef11ffd3 |
| ANVÄNDARE.PWD | 93167DE7 |
| TRANSACTION.CHANNEL | 31HA07BC8142C5A171749A60D979B6E4 |
| Valutor konfigurerade för 3D version 2 | EUR, USD, SEK |
| Valutor konfigurerade för 3D version 1 | GBP, CZK, CHF |
System gateway slutpunkt är antingen
SGW gateway:
– https://test-heidelpay.hpcgw.net/sgw/gtw – Latin-15-kodad
– https://test-heidelpay.hpcgw.net/sgw/gtwu – UTF-8-kodad
NGW gateway:
– https://test-heidelpay.hpcgw.net/ngw/post
Kreditkortsdata för detta test:
| varumärken | kortnummer | CVV | utgångsdatum | notera |
| MasterCard | 5453010000059543 | 123 | framtida datum | 3D – lösenord: hemligt3 |
| Visum | 4711100000000000 | 123 | framtida datum | 3DS – lösenord: hemligt!33 |
Observera: För 3D Secure Version 2 behöver du inte ange något lösenord, utan klicka bara på länken ”Klicka här för att slutföra autentiseringen.
Det enda sättet att simulera ett fel med 3D Secure Version 2 är att låta sidan med länken timeout (ca 18 minuter).
Läs mer om denna manual och ladda ner PDF:
Dokument/resurser
 |
Programvaror 3D Secure Integration Guide [pdfDokumentation Unzer, Integrationsguide, 3D Secure |
