Software Software Secure Integration Guide Documentation

Ghid de integrare 3D Secure

Începând cu 01.01.2021, autentificarea cu doi factori va fi implementată ca o cerință obligatorie pentru toate tranzacțiile de plată prin card de comerț electronic. Pentru a respecta această obligație,
operatorii rețelelor de carduri de credit vor folosi așa-numita procedură 3D Secure. Pentru dvs., în calitate de comerciant, este obligatoriu să puteți efectua această procedură pentru clienții dvs. de la
01.01.2021. În cele ce urmează veți găsi o descriere a diferitelor moduri de integrare și modul în care trebuie implementată procedura 3D Secure pentru acestea.

Vă rugăm să selectați metoda de integrare pe care o utilizați

  • Folosiți formularul de plată hCO?
  • Folosiți formularul de plată hPF?
  • Procesați plăți fără a utiliza un formular furnizat de sistemul Unzer?

Vă rugăm să rețineți: De asemenea, este important în ce mod se fac debite sau preautorizări (rezervări). Chiar dacă utilizați un formular de plată de la Unzer GmbH pentru înregistrarea datelor cardului, procesul 3D Secure va fi efectuat fără un formular de plată atunci când datele cardului sunt debitate sau autorizate pentru prima dată pentru prima dată. În acest caz se aplică a treia modalitate de integrare fără un formular furnizat de Unzer.

Vă rugăm să rețineți și:
Dacă utilizați plăți recurente (plăți de abonament), asigurați-vă că citiți secțiunea „Plată securizată și recurentă 3D”.

Procedură 3D Secure atunci când utilizați formularul de plată hCO

Formularul de verificare hCO este deja conceput pentru procedura 3D Secure. Nu există nicio acțiune suplimentară din partea dvs. necesară pentru implementarea procedurii. Cu toate acestea, tu
trebuie să vă asigurați că sistemul dvs. poate gestiona răspunsurile corespunzătoare sistemului nostru de plăți în cazul în care procesul 3D Secure este pornit. În răspunsul asincron de la
sistemul de plată către serverul dvs., rezultatul tranzacției este transmis și trebuie evaluat acolo înainte de returnare URL se transmite sistemului de plăți.

În acest scop trebuie evaluați următorii parametri.

  • COD.PROCESARE.RETURNARE = ​​000.200.000
  • PROCESSING.RETURN = Tranzacție + în așteptare
  • PROCESARE.REZULTAT = ACK

Explicație: Starea tranzacției este „în așteptare”, parametrul PROCESSING.RESULT
reprezintă doar un rezultat preliminar. Atâta timp cât se realizează procesul 3D Secure, starea
rămâne în așteptare.

Rezultatul final al tranzacției este atunci fie

  •  COD.PROCESARE.RETURNARE = ​​000.000.000
  • PROCESARE.REZULTAT = ACK
    or
  • PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 sau 000.200.000
  • PROCESING.RESULT = NOK

În primul caz tranzacția a fost finalizată cu succes, în al doilea caz a eșuat în general. Acesta din urmă poate avea diverse motive, inclusiv un refuz de autentificare. Veți
primiți informații mai detaliate în parametrii „PROCESSING.RETURN” și „PROCESSING.RETURN.CODE”.
Vă recomandăm să rulați un test pentru ambele mesaje. Pentru mai multe informații despre cum să faceți un test și despre detaliile cardului de credit pe care le puteți utiliza pentru un test, vă rugăm să consultați mai jos.

Procedură 3D Secure atunci când utilizați formularul de plată hPF

Formularul de verificare hPF este, de asemenea, conceput pentru a utiliza deja procedura 3DS. Nu există nicio acțiune suplimentară din partea dvs. necesară pentru implementarea procedurii. După cum este descris
pentru implementarea hCO răspunsul din sistemul de plată are loc în doi pași, motiv pentru care sistemul dvs. trebuie să verifice valoarea PROCESSING.RETURN.CODE
parametru la procesarea răspunsului.

În acest scop trebuie evaluați următorii parametri.

  • COD.PROCESARE.RETURNARE = ​​000.200.000
  • PROCESSING.RETURN = Tranzacție + în așteptare
  • PROCESARE.REZULTAT = ACK

Explicație: Starea tranzacției este „în așteptare”, parametrul PROCESSING.RESULT reprezintă doar un rezultat preliminar. Atâta timp cât se realizează procesul 3D Secure, starea
rămâne în așteptare.

Rezultatul final al tranzacției este atunci fie

  • COD.PROCESARE.RETURNARE = ​​000.000.000
  • PROCESARE.REZULTAT = ACK
    or
  • PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 sau 000.200.000
  • PROCESING.RESULT = NOK

În primul caz tranzacția a fost finalizată cu succes, în al doilea caz a eșuat în general. Acesta din urmă poate avea diverse motive, inclusiv un refuz de autentificare. Veți
primiți informații mai detaliate în parametrii „PROCESSING.RETURN” și „PROCESSING.RETURN.CODE”.
Vă recomandăm să rulați un test pentru ambele mesaje. Pentru mai multe informații despre cum să faceți un test și despre detaliile cardului de credit pe care le puteți utiliza pentru un test, vă rugăm să consultați mai jos.

Procedură 3D Secure cu conexiune directă

Dacă nu utilizați un formular de plată furnizat de Unzer (fost heidelpay) pentru a procesa plățile cu cardul de credit sau pur și simplu înregistrați un card folosind unul dintre formulare și procesați preautorizarea (rezervarea) sau debitul ca referință la înregistrare ca comunicare directă cu sistemul de plată, trebuie să implementați procesul 3D Secure.

Fluxul de tranzacții asincron:

Acesta este un proces asincron în care serverul dvs. primește o redirecționare URL (Redirecţiona URL) din sistemul nostru de plăți. Serverul dvs. trebuie să redirecționeze clientul către acest lucru URL astfel încât să poată efectua autentificarea prin procedura 3D Secure. Rezultatul acestei autentificări 3D Secure este raportat direct către Unzer de către banca emitentă a cardului.

După autentificarea cu succes, tranzacția este procesată în continuare în sistemul Unzer așa cum știți deja, trimițând sistemului dvs. un rezultat general la final, la care răspundeți
cu o redirecționare URL. Sistemul de plăți va redirecționa clientul înapoi către sistemul dvs. utilizând această redirecționare URL din sistemul dvs.

Vă rugăm să rețineți: în acest flux de lucru, sistemul dvs. primește două răspunsuri de la sistemul de plăți:

- Unul cu starea „în așteptare” (PROCESSING.RETURN.CODE = 000.200.000 și PROCESSING.RETURN = Tranzacție + în așteptare) și parametrii de redirecționare către banca emitentă a cardului clientului
- Unul cu rezultatul final al debitului sau rezervării. Există, de asemenea, două redirecționări URLMenționat în acest proces, unul din sistemul de plată către care clientul trebuie să fie redirecționat pentru a se autentifica la banca emitentă a cardului său și unul din sistemul dvs., la primirea rezultatului final, pentru a redirecționa clientul înapoi în sistemul dvs.

cronologie

Următoarele modificări vor fi aduse procedurii obișnuite. Vă rugăm să rețineți că, din cauza implementării altor metode de plată asincrone, cum ar fi Paypal, unele dintre acestea
procesele pot exista deja în implementarea dvs.

  1. Răspuns URL
    În primul apel (nr. 2 din diagramă) către sistemul de plată, un „Răspuns URL”Trebuie trecut în grupul frontend.
    interfață grafică cu utilizatorul, text, aplicație
    Vă rugăm să rețineți: Parametrul IDENTIFICATION.REFERENCEID este relevant numai dacă vă referiți la o înregistrare sau la o altă tranzacție deja existentă
  2. Redirecționare procesare URL Dacă este necesară autentificarea, o redirecționare URL și alți parametri din grupul de redirecționare sunt transferați în răspunsul din sistemul de plăți (nr. 5 din diagramă).
    interfață grafică cu utilizatorul, text
    interfață grafică de utilizator, text, aplicație, scrisoare
  3. Redirecționarea clientului către redirecționare URL
    Dacă grupul de redirecționare răspunde cu o redirecționare URL, browserul clientului trebuie redirecționat către acesta URL (Nr. 6 în diagramă) pentru a efectua autentificarea. Parametrii suplimentari din grupul de redirecționare trebuie să fie transferați către extern website ca parametri POST.
    Vă rugăm să rețineți: parametrii suplimentari sunt returnați în grupul „PROCESSING.REDIRECT.xxx” numai cu versiunea 3D Secure 1 (chiar și acolo numărul și denumirea pot varia), în timp ce cu versiunea 3D 2 doar un PROCESSING.REDIRECT.URL după cum este afișat mai jos este returnat: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
    CCF / run Aceasta înseamnă că, indiferent de tipul și numărul de parametri, browserul client trebuie să redirecționeze către PROCESSING.REDIRECT.URL.
    Mai jos veți găsi un cod simplu example despre cum poate fi executată o astfel de redirecționare. The partea este destinată să informeze clienții finali ale căror sisteme nu acceptă Javascript sau îl dezactivează. Vă recomandăm insistent ca redirecționarea să se facă în fereastra de browser activă a clientului și să nu utilizați ferestre pop-up sau ferestre noi de browser, deoarece acest lucru ar putea
    irită clienții și îi determină să închidă pagina către care sunt redirecționați.
    text, scrisoare
  4. Verificare asincronă a rezultatelor
    Rezultatul autentificării este trimis asincron către serverul dvs. Sistemul de plăți așteaptă un valabil URL ca răspuns. (Nr. 12 și 13 în diagramă). Pentru succes sau respins
    plăți, altfel URL poate fi răspuns aici de sistemul dvs.
  5. Calea de retur a clientului
    Sistemul de plăți redirecționează clientul către URL furnizate de sistemul comerciantului după finalizarea procesului de autentificare și a tranzacției de plată.
    Vă rugăm să rețineți: pașii 4.) și 5.) procedați exact în același mod în care sunteți deja familiarizați cu tranzacțiile existente NONE 3D Secure.

Plată 3D sigură și recurentă

De la 1 ianuarie 2021, 3D Secure va fi obligatoriu pentru toate tranzacțiile cu carduri de comerț electronic. Cu toate acestea, deoarece acest lucru este greu de aplicat pentru plăți recurente, serviciile bancare
sistemele au un flux de lucru separat pentru aceasta.

În acest scop, băncile disting între

  • CIT = tranzacții inițializate de client
  • MIT = tranzacții inițializate de comerciant

Prima tranzacție a unui card din contul dvs. de comerciant trebuie autentificată cu 3D Secure începând cu 01.01.2021. O astfel de autentificare reușită este o cerință obligatorie în
pentru a putea trimite ulterior rezervări ulterioare pe același card fără 3D Secure. Prin urmare, clientul trebuie să fie înaintat băncii sale emitente de carduri pentru primul debit în
conform procedurii descrise mai sus și se autentifică acolo ca titular al cardului. Dacă un debit nu este planificat în momentul comenzii, de exampdatorită unei perioade de încercare, trebuie făcută o rezervare (preautorizare) de cel puțin un euro cu 3D Secure în prezența clientului. Captarea acestei rezervări nu este necesară.

Cu toate acestea, pentru clienții existenți nu este necesară inventarea autentificării 3D Secure. Dacă primul debit reușit a avut loc înainte de 01.01.2021, se poate presupune că și înregistrarea clientului
au fost autentificate cu succes. Pentru clienții noi începând cu 01.01.2021, pe de altă parte, autentificarea 3D Secure este obligatorie pentru primul debit sau rezervare (preautorizare).

Vă rugăm să rețineți: în acest sens, sistemul bancar privește datele cardului, nu datele clientului. Deci, dacă un client existent folosește un card nou după 01.01.2021, de example pentru că precedentul
unul a expirat sau pentru că și-a schimbat banca emitentă a cardului, acesta este un nou ciclu recurent din punctul de vedere al băncilor view și trebuie autentificat cu 3D Secure pentru prima rezervare.

Odată ce această autentificare inițială a fost efectuată cu succes, toate tranzacțiile ulterioare sunt scutite de obligația de a utiliza 3D Secure Condițiile preliminare pentru plata recurentă fără 3D Secure sunt, prin urmare:

  • Există cel puțin un debit sau o rezervare reușită (preautorizare) care a fost fie efectuată cu 3D Secure, fie a avut loc înainte de 01.01.2021.
  • se face trimitere la o înregistrare existentă și debit la depunere

Pentru a informa sistemul de plăți că aceasta este o plată recurentă, trebuie trimis și parametrul RECURRENCE.MODE = REPEATED. Acest lucru semnalează sistemului că a
plata recurentă trebuie raportată sistemelor bancare.

Vă rugăm să rețineți: Dacă parametrul RECURRENCE.MODE = REPEATED este introdus la încărcarea pentru prima dată a unui nou card, redirecționarea 3D Secure va fi efectuată în ciuda acestui parametru.

Testarea implementării 3D Secure

Puteți testa conexiunea 3D Secure în orice moment prin intermediul sistemului nostru de plăți. Pentru aceasta, utilizați modul „CONNECTOR_TEST” pentru o tranzacție, așa cum se arată în example mai sus.
Date de conexiune pentru acest test:

  SIGURANȚĂ   31HA07BC8142C5A171745D00AD63D182
  LOGARE UTILIZATOR   31ha07bc8142c5a171744e5aef11ffd3
  UTILIZATOR.PWD   93167DE7
  TRANZACȚIE.CHANNEL   31HA07BC8142C5A171749A60D979B6E4
  Valute configurate pentru versiunea 3D 2   EUR, USD, SEK
  Valute configurate pentru versiunea 3D 1   GBP, CZK, CHF

Punctul final al gateway-ului de sistem este fie
Gateway SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - Latin-15 codificat
- https://test-heidelpay.hpcgw.net/sgw/gtwu - codificat UTF-8
Gateway NGW:
- https://test-heidelpay.hpcgw.net/ngw/post

Date despre cardul de credit pentru acest test:

  mărci   numere de card   CVV   Data de expirare   nota
  MasterCard   5453010000059543   123   data viitoare   3D - parolă: secret3
  Visa   4711100000000000   123   data viitoare   3DS - parolă: secret! 33

Vă rugăm să rețineți: Pentru 3D Secure Versiunea 2, nu este nevoie să introduceți o parolă, ci pur și simplu faceți clic pe linkul ”Faceți clic aici pentru a finaliza autentificarea.
Singura modalitate de a simula o eroare cu 3D Secure Version 2 este să lăsați pagina cu linkul să expire (aproximativ 18 minute).

 

Citiți mai multe despre acest manual și descărcați PDF:

Documente/Resurse

Ghid de integrare software 3D Secure [pdfDocumentație
Unzer, Ghid de integrare, 3D Secure

Referințe

Lasă un comentariu

Adresa ta de e-mail nu va fi publicată. Câmpurile obligatorii sunt marcate *