Softwares 3D Secure Integration Guide Dokumentasjon

Integrasjonsveiledning 3D Secure

Fra 01.01.2021 vil tofaktorautentisering bli implementert som et obligatorisk krav for alle betalingstransaksjoner med netthandel. For å oppfylle denne forpliktelsen, har
operatører av kredittkortnett vil bruke den såkalte 3D Secure-prosedyren. For deg som kjøpmann er det obligatorisk å kunne utføre denne prosedyren for kundene dine fra
01.01.2021. I det følgende finner du en beskrivelse av de forskjellige måtene å integrere og hvordan 3D Secure-prosedyren må implementeres for dem.

Velg integrasjonsmetoden du bruker

• Bruker du kassen skjemaet hCO?
• Bruker du kassen skjemaet hPF?
• Behandler du betalinger uten å bruke et skjema levert av Unzer-systemet?

Vennligst merk: Det er også viktig på hvilken måte debeting eller forhåndsgodkjenning (reservasjon) blir gjort. Selv om du bruker et betalingsskjema fra Unzer GmbH for registrering av kortdata, vil 3D Secure-prosessen utføres uten utsjekkingsskjema når kortdataene først debiteres eller godkjennes for første gang. I dette tilfellet gjelder den tredje måten å integrere uten skjema fra Unzer.

Vær også oppmerksom på:
Hvis du bruker tilbakevendende betalinger (abonnementsbetalinger), må du lese avsnittet “3D Sikker og gjentatt betaling”.

3D Secure-prosedyre når du bruker hCO-utsjekkingsskjemaet

Skjemaet for hCO-utsjekking er allerede designet for 3D Secure-prosedyren. Det er ingen ytterligere tiltak fra din side nødvendig for gjennomføring av prosedyren. Imidlertid du
må du sørge for at systemet ditt kan håndtere de tilsvarende svarene i betalingssystemet vårt i tilfelle 3D Secure-prosessen startes. I det asynkrone svaret fra
betalingssystem til serveren din, blir resultatet av transaksjonen overført og må evalueres der før retur URL overføres til betalingssystemet.

For dette formålet må følgende parametere evalueres.

• PROSESSING.RETURN.CODE = 000.200.000
• PROCESSING.RETURN = Transaksjon + venter
• PROSESSING.RESULT = ACK

Forklaring: Statusen for transaksjonen er "ventende", parameteren PROCESSING.RESULT
representerer bare et foreløpig resultat. Så lenge 3D Secure-prosessen er utført, er statusen
forblir ventende.

Det endelige resultatet av transaksjonen er da heller

•  PROSESSING.RETURN.CODE = 000.000.000
• PROSESSING.RESULT = ACK
  or
• PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
• BEARBEIDING.RESULTAT = kr

I det første tilfellet er transaksjonen fullført, i det andre tilfellet mislyktes den generelt. Sistnevnte kan ha forskjellige grunner, inkludert en nektelse om å godkjenne. Du vil
motta mer detaljert informasjon i parameterne “PROCESSING.RETURN” og “PROCESSING.RETURN.CODE”.
Vi anbefaler at du kjører en test for begge meldingene. For mer informasjon om hvordan du gjør en test og hvilke kredittkortdetaljer du kan bruke til en test, se nedenfor.

3D Secure-prosedyre når du bruker hPF-utsjekkingsskjemaet

HPF utsjekkingsskjema er også designet for å bruke 3DS-prosedyren allerede. Det er ingen ytterligere tiltak fra din side nødvendig for gjennomføring av prosedyren. Som beskrevet
for hCO-implementeringen foregår svaret fra betalingssystemet i to trinn, og derfor må systemet ditt kontrollere verdien av BEHANDLINGEN.RETURN.CODE
parameter når du behandler svaret.

For dette formålet må følgende parametere evalueres.

• PROSESSING.RETURN.CODE = 000.200.000
• PROCESSING.RETURN = Transaksjon + venter
• PROSESSING.RESULT = ACK

Forklaring: Statusen for transaksjonen er "ventende", parameteren BEHANDLING. RESULTAT representerer bare et foreløpig resultat. Så lenge 3D Secure-prosessen er utført, er statusen
forblir ventende.

Det endelige resultatet av transaksjonen er da heller

• PROSESSING.RETURN.CODE = 000.000.000
• PROSESSING.RESULT = ACK
  or
• PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
• BEARBEIDING.RESULTAT = kr

I det første tilfellet er transaksjonen fullført, i det andre tilfellet mislyktes den generelt. Sistnevnte kan ha forskjellige grunner, inkludert en nektelse om å godkjenne. Du vil
motta mer detaljert informasjon i parameterne “PROCESSING.RETURN” og “PROCESSING.RETURN.CODE”.
Vi anbefaler at du kjører en test for begge meldingene. For mer informasjon om hvordan du gjør en test og hvilke kredittkortdetaljer du kan bruke til en test, se nedenfor.

3D Secure-prosedyre med direkte tilkobling

Hvis du ikke bruker et betalingsskjema levert av Unzer (tidligere heidelpay) for å behandle kredittkortbetalinger, eller hvis du bare registrerer et kort ved hjelp av et av skjemaene og behandler forhåndsgodkjenning (reservasjon) eller belastning som referanse til registreringen som direkte kommunikasjon med betalingssystemet, må du implementere 3D Secure-prosessen.

Asynkron transaksjonsflyt:

Dette er en asynkron prosess der serveren din mottar videresending URL (Viderekobling URL) fra vårt betalingssystem. Serveren din må videresende kunden til dette URL slik at han kan utføre autentiseringen via 3D Secure-prosedyren. Resultatet av denne 3D Secure-autentiseringen rapporteres direkte til Unzer av den kortutstedende banken.

Etter vellykket autentisering blir transaksjonen videre behandlet i Unzer-systemet på den måten du allerede vet ved å sende systemet et samlet resultat på slutten, som du svarer på
med en omdirigering URL. Betalingssystemet omdirigerer deretter kunden tilbake til systemet ditt ved hjelp av denne viderekoblingen URL fra systemet ditt

Merk: I denne arbeidsflyten mottar systemet to svar fra betalingssystemet:

- En med statusen "ventende" (PROCESSING.RETURN.CODE = 000.200.000 og PROCESSING.RETURN = Transaksjon + ventende) og viderekoblingsparametrene til den kortutstedende banken til kunden
- Ett med det endelige resultatet av debet eller reservasjonen. Det er også to omdirigeringer URLer nevnt i denne prosessen, en fra betalingssystemet som kunden må omdirigeres til for å autentisere på kortutstedende bank og en fra systemet ditt, når du mottar det endelige resultatet, for å omdirigere kunden tilbake til systemet ditt.

Følgende endringer vil bli gjort i den vanlige prosedyren. Vær oppmerksom på at noen av disse på grunn av implementeringen av andre asynkrone betalingsmåter, for eksempel Paypal
prosesser kan allerede eksistere i implementeringen.

1. Svar URL
   I den første samtalen (nr. 2 i diagrammet) til betalingssystemet, et “Svar URL”Må bestås i frontend-gruppen.
   
   Vennligst merk: Parameteren IDENTIFICATION.REFERENCEID er bare relevant hvis du refererer til en registrering eller en annen allerede eksisterende transaksjon
2. Behandler omdirigering URL Hvis godkjenning er nødvendig, en omdirigering URL og andre parametere i viderekoblingsgruppen overføres i svaret fra betalingssystemet (nr. 5 i diagrammet).
   
   
3. Videresending av kunden til viderekoblingen URL
   Hvis viderekoblingsgruppen svarer med en viderekobling URLmå kundens nettleser omdirigeres til dette URL (nr. 6 i diagrammet) for å utføre autentisering. De ekstra parameterne fra omdirigeringsgruppen må overføres til den eksterne webnettsted som POST-parametere.
   Merk: Ytterligere parametere returneres i gruppen “PROCESSING.REDIRECT.xxx” bare med 3D Secure versjon 1 (selv der kan nummeret og navngivningen variere), mens det med 3D versjon 2 bare er en BEHANDLING.REDIRECT.URL som vist nedenfor returneres: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
   CCF / run Dette betyr at uansett type og antall parametere, må klientleseren omdirigere til PROCESSING.REDIRECT.URL.
   Nedenfor finner du en enkel kode eksamples om hvordan en slik omdirigering kan utføres. De delen er ment å informere sluttkunder hvis systemer ikke støtter Javascript eller har det deaktivert. Vi anbefaler på det sterkeste at omdirigeringen gjøres i kundens aktive nettleservindu og ikke å bruke popup-vinduer eller nye nettleservinduer, da dette kan
   irritere kunder og føre dem til å lukke siden de blir omdirigert til.
   
4. Asynkron resultatkontroll
   Resultatet av autentiseringen sendes asynkront til serveren din. Betalingssystemet forventer en gyldig URL som svar. (Nr. 12 og 13 i diagrammet). For vellykket eller avvist
   betalinger, en annen URL kan besvares her av systemet ditt.
5. Retursti til kunden
   Betalingssystemet omdirigerer kunden til URL levert av selgers system etter at autentiseringsprosessen og betalingstransaksjonen er fullført.
   Merk: Trinn 4.) og 5.) fortsett på nøyaktig samme måte som du allerede er kjent med i eksisterende NONE 3D Secure-transaksjoner.

3D Sikker og tilbakevendende betaling

Fra 1. januar 2021 vil 3D Secure være obligatorisk for alle e-handelskorttransaksjoner. Men siden dette neppe gjelder for gjentatte betalinger, vil banken
systemer har en egen arbeidsflyt for dette.

For dette formålet skiller bankene mellom

• CIT = kundeinitialiserte transaksjoner
• MIT = selgerinitialiserte transaksjoner

Den første transaksjonen av et kort i selgerkontoen din må godkjennes med 3D Secure fra 01.01.2021 og utover. En slik vellykket autentisering er et obligatorisk krav i
for å kunne sende inn ytterligere bestillinger på samme kort uten 3D Secure. Kunden må derfor sendes til sin kortutstedende bank for første debet
i henhold til prosedyren beskrevet ovenfor og autentisere seg der som kortholder. Dersom en belastning ikke er planlagt på bestillingstidspunktet, f.eksample grunnet en prøveperiode, må en reservasjon (forhåndsautorisasjon) på minst én euro gjøres med 3D Secure i nærvær av kunden i stedet. Det er ikke nødvendig å fange denne reservasjonen.

For eksisterende kunder trenger imidlertid ingen 3D Secure-autentisering å bli gjort opp. Hvis den første vellykkede debetningen fant sted før 01.01.2021, kan også kundeposten antas å
har blitt godkjent. For nye kunder per 01.01.2021, derimot, er 3D Secure-autentisering obligatorisk for første debet eller reservasjon (forhåndsgodkjenning).

Vennligst merk: I denne forbindelse ser banksystemet på kortdataene, ikke kundedataene. Så hvis en eksisterende kunde bruker et nytt kort etter 01.01.2021, f.eksample fordi den forrige
en har utløpt eller fordi han har byttet kortutstedende bank, er dette en ny tilbakevendende syklus fra bankenes side av view og må være autentisert med 3D Secure for første bestilling.

Når denne første autentiseringen er vellykket, er alle ytterligere transaksjoner unntatt fra forpliktelsen til å bruke 3D Secure Forutsetningene for gjentakende betaling uten 3D Secure er derfor:

• Det er minst en vellykket belastning eller reservasjon (forhåndsgodkjenning) som enten ble utført med 3D Secure eller fant sted før 01.01.2021.
• det refereres til en eksisterende registrering og debet ved innsending

For å gi betalingssystemet beskjed om at dette er en tilbakevendende betaling, må også parameteren RECURRENCE.MODE = REPEATED sendes. Dette signaliserer til systemet at en
Gjentatt betaling skal rapporteres til banksystemene.

Merk: Hvis parameteren RECURRENCE.MODE = REPEATED tastes inn når et nytt kort lastes inn for første gang, vil 3D Secure videresending utføres til tross for denne parameteren.

Testing av 3D Secure implementering

Du kan teste 3D Secure-tilkoblingen når som helst via vårt betalingssystem. For å gjøre det, bruk "CONNECTOR_TEST"-modus for en transaksjon, som vist i eksamples ovenfor.
Tilkoblingsdata for denne testen:

Systemgateway-endepunktet er enten
SGW -gateway:
- https://test-heidelpay.hpcgw.net/sgw/gtw - Latin-15 kodet
- https://test-heidelpay.hpcgw.net/sgw/gtwu - UTF-8 kodet
NGW gateway:
- https://test-heidelpay.hpcgw.net/ngw/post

Kredittkortdata for denne testen:

Merk: For 3D Secure versjon 2 trenger du ikke å oppgi passord, men bare klikke på lenken ”Klikk her for å fullføre godkjenningen.
Den eneste måten å simulere en feil med 3D Secure versjon 2 er å la siden med lenken gå ut (ca. 18 minutter).

Les mer om denne håndboken og last ned PDF:

Dokumenter / Ressurser

Programvare 3D Secure Integration Guide [pdfDokumentasjon Unzer, Integrasjonsguide, 3D Secure

Referanser

• Brukerhåndbok