Programmatūras 3D drošas integrācijas rokasgrāmatas dokumentācija
Integrācijas ceļvedis 3D Secure
Sākot ar 01.01.2021. Divu faktoru autentifikācija tiks ieviesta kā obligāta prasība visiem e-komercijas karšu maksājumu darījumiem. Lai izpildītu šo pienākumu,
kredītkaršu tīklu operatori izmantos tā saukto 3D Secure procedūru. Jums kā tirgotājam ir obligāti jāspēj veikt šo procedūru klientiem no plkst
01.01.2021. Turpmāk jūs atradīsit dažādu integrācijas veidu aprakstu un to, kā 3D Secure procedūra tiem jāievieš.
Lūdzu, atlasiet izmantoto integrācijas metodi
- Vai izmantojat norēķinu veidlapu hCO?
- Vai izmantojat norēķinu veidlapu hPF?
- Vai jūs apstrādājat maksājumus, neizmantojot sistēmas Unzer veidlapu?
Lūdzu, ņemiet vērā: Ir arī svarīgi, kādā veidā tiek veikti debeti vai priekšautorizācijas (atrunas). Pat ja karšu datu reģistrēšanai izmantojat maksājuma veidlapu no Unzer GmbH, 3D Secure process tiks veikts bez izrakstīšanās veidlapas, kad kartes dati pirmo reizi tiek debetēti vai autorizēti. Šajā gadījumā tiek piemērots trešais integrācijas veids bez formas, kuru nodrošina Unzer.
Lūdzu, ņemiet vērā arī:
Ja izmantojat periodiskus maksājumus (abonēšanas maksājumus), noteikti izlasiet sadaļu “Drošs un 3D maksājums XNUMXD”.
3D Secure procedūra, izmantojot hCO izrakstīšanās veidlapu
HCO izrakstīšanās forma jau ir paredzēta 3D Secure procedūrai. Procedūras īstenošanai no jūsu puses nav nepieciešama papildu darbība. Tomēr jūs
jāpārliecinās, vai jūsu sistēma spēj apstrādāt atbilstošās mūsu maksājumu sistēmas atbildes, ja tiek sākts 3D Secure process. Asinhronajā atbildē no
maksājumu sistēmu uz jūsu serveri, darījuma rezultāts tiek pārsūtīts un pirms atgriešanas tas tur jānovērtē URL tiek pārsūtīts uz maksājumu sistēmu.
Šim nolūkam jānovērtē šādi parametri.
- APSTRĀDES.ATGRIEŠANAS KODS = 000.200.000
- PROCESSING.RETURN = Darījums + gaida
- APSTRĀDE. REZULTĀTS = ACK
Paskaidrojums: Darījuma statuss ir “gaida”, parametrs PROCESSING.RESULT
ir tikai provizorisks rezultāts. Kamēr tiek veikts 3D Secure process, statuss
paliek gaida.
Tad arī ir darījuma galīgais rezultāts
- APSTRĀDES.ATGRIEŠANAS KODS = 000.000.000
- APSTRĀDE. REZULTĀTS = ACK
or - PROCESSING.RETURN.CODE = ungendein Wert ungleich 000.000.000 oder 000.200.000
- APSTRĀDE. REZULTĀTS = NOK
Pirmajā gadījumā darījums ir veiksmīgi pabeigts, otrajā gadījumā tas kopumā ir izgāzies. Pēdējam var būt dažādi iemesli, tostarp atteikums autentificēties. Jums būs
saņemt detalizētāku informāciju parametros “PROCESSING.RETURN” un “PROCESSING.RETURN.CODE”.
Mēs iesakām pārbaudīt abus ziņojumus. Lai iegūtu papildinformāciju par to, kā veikt testu un kuru kredītkartes informāciju varat izmantot testam, lūdzu, skatiet zemāk.
3D Secure procedūra, izmantojot hPF izrakstīšanās veidlapu
Arī hPF norēķinu forma ir paredzēta, lai jau izmantotu 3DS procedūru. Procedūras īstenošanai no jūsu puses nav nepieciešama papildu darbība. Kā aprakstīts
hCO ieviešanai atbilde no maksājumu sistēmas notiek divos posmos, tāpēc jūsu sistēmai jāpārbauda PROCESSING.RETURN.CODE vērtība
parametrs, apstrādājot atbildi.
Šim nolūkam jānovērtē šādi parametri.
- APSTRĀDES.ATGRIEŠANAS KODS = 000.200.000
- PROCESSING.RETURN = Darījums + gaida
- APSTRĀDE. REZULTĀTS = ACK
Paskaidrojums: Darījuma statuss ir “gaida”, parametrs PROCESSING.RESULT parāda tikai provizorisku rezultātu. Kamēr tiek veikts 3D Secure process, statuss
paliek gaida.
Tad arī ir darījuma galīgais rezultāts
- APSTRĀDES.ATGRIEŠANAS KODS = 000.000.000
- APSTRĀDE. REZULTĀTS = ACK
or - PROCESSING.RETURN.CODE = ungendein Wert ungleich 000.000.000 oder 000.200.000
- APSTRĀDE. REZULTĀTS = NOK
Pirmajā gadījumā darījums ir veiksmīgi pabeigts, otrajā gadījumā tas kopumā ir izgāzies. Pēdējam var būt dažādi iemesli, tostarp atteikums autentificēties. Jums būs
saņemt detalizētāku informāciju parametros “PROCESSING.RETURN” un “PROCESSING.RETURN.CODE”.
Mēs iesakām pārbaudīt abus ziņojumus. Lai iegūtu papildinformāciju par to, kā veikt testu un kuru kredītkartes informāciju varat izmantot testam, lūdzu, skatiet zemāk.
3D Secure procedūra ar tiešu savienojumu
Ja kredītkaršu maksājumu apstrādei neizmantojat Unzer (agrāk heidelpay) sniegto maksājuma veidlapu vai vienkārši reģistrējat karti, izmantojot kādu no veidlapām, un apstrādājat priekšautorizāciju (rezervāciju) vai debetu kā atsauci uz reģistrāciju kā tieša saziņa ar maksājumu sistēmu, jums jāievieš 3D Secure process.
Asinhrono darījumu plūsma:
Tas ir asinhronais process, kurā jūsu serveris saņem pārsūtīšanu URL (Pāradresēt URL) no mūsu maksājumu sistēmas. Jūsu serverim ir jāpārsūta klients uz šo URL lai viņš varētu veikt autentifikāciju, izmantojot 3D Secure procedūru. Par šīs 3D Secure autentifikācijas rezultātiem karti izsniedzošā banka tieši ziņo Unzer.
Pēc veiksmīgas autentifikācijas darījums tiek tālāk apstrādāts sistēmā Unzer tā, kā jūs jau zināt, beigās nosūtot savai sistēmai kopējo rezultātu, uz kuru jūs atbildat
ar novirzīšanu URL. Pēc tam maksājumu sistēma, izmantojot šo novirzīšanu, novirzīs klientu atpakaļ uz jūsu sistēmu URL no jūsu sistēmas
Lūdzu, ņemiet vērā: šajā darbplūsmā jūsu sistēma saņem divas atbildes no maksājumu sistēmas:
- Viens ar statusu “gaida” (PROCESSING.RETURN.CODE = 000.200.000 un PROCESSING.RETURN = Transaction + pending) un parametru novirzīšana uz klienta karti izsniedzošo banku
- viens ar debeta vai rezervācijas gala rezultātu. Ir arī divas novirzīšanas URLŠajā procesā ir minēts viens no maksājumu sistēmas, uz kuru klients ir jāpāradresē, lai autentificētos savā kartes izsniedzošajā bankā, un viens no jūsu sistēmas, saņemot gala rezultātu, lai novirzītu klientu atpakaļ jūsu sistēmā.
Parastajā procedūrā tiks veiktas šādas izmaiņas. Lūdzu, ņemiet vērā, ka citu asinhrono maksājumu metožu, piemēram, Paypal, ieviešanas dēļ daži no tiem
procesi, iespējams, jau pastāv jūsu ieviešanā.
- Atbilde URL
Pirmajā izsaukumā (diagrammā nr.2) uz maksājumu sistēmu tiek parādīts “Atbilde URL”Jānokārto frontend grupā.
Lūdzu, ņemiet vērā: Parametrs IDENTIFICATION.REFERENCEID ir būtisks tikai tad, ja atsaucaties uz reģistrāciju vai citu jau esošu darījumu - Notiek novirzīšanas apstrāde URL Ja nepieciešama autentifikācija, novirziet URL un citi novirzīšanas grupas parametri tiek pārsūtīti atbildē no norēķinu sistēmas (diagrammā Nr. 5).
- Klienta pārsūtīšana uz novirzīšanu URL
Ja novirzīšanas grupa atbild ar novirzīšanu URL, klienta pārlūkprogramma ir jānovirza uz to URL (Nr. 6 diagrammā), lai veiktu autentifikāciju. Papildu parametri no novirzīšanas grupas ir jāpārsūta uz ārējo webvietne kā POST parametri.
Lūdzu, ņemiet vērā: Papildu parametri grupā “PROCESSING.REDIRECT.xxx” tiek atgriezti tikai ar 3D Secure 1. versiju (pat tur numurs un nosaukumi var atšķirties), savukārt ar 3D 2D versiju tikai PROCESSING.REDIRECT.URL kā parādīts zemāk, tiek atgriezta: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run Tas nozīmē, ka neatkarīgi no parametru veida un skaita klienta pārlūkprogrammai ir jāpāradresē uz PROCESSING.REDIRECT.URL.
Zemāk jūs atradīsit vienkāršu kodu example par to, kā šādu novirzīšanu var izpildīt. The daļa ir paredzēta, lai informētu galapatērētājus, kuru sistēmas neatbalsta Javascript vai ir atspējotas. Mēs ļoti iesakām novirzīšanu veikt klienta aktīvajā pārlūkprogrammas logā un neizmantot uznirstošos logus vai jaunus pārlūkprogrammas logus, jo tas var
kairināt klientus un likt viņiem aizvērt lapu, uz kuru viņi tiek novirzīti.
- Asinhronā rezultāta pārbaude
Autentifikācijas rezultāts tiek asinhroni nosūtīts uz jūsu serveri. Maksājumu sistēma sagaida derīgu URL kā atbildi. (Diagrammā Nr. 12 un 13). Par veiksmīgu vai noraidītu
maksājumi, atšķirīgs URL šeit var atbildēt jūsu sistēma. - Klienta atgriešanās ceļš
Maksājumu sistēma novirza klientu uz URL nodrošina tirgotāja sistēma pēc autentifikācijas procesa un maksājuma darījuma pabeigšanas.
Lūdzu, ņemiet vērā: 4. un 5. darbība turpinās tieši tāpat, kā jūs jau zināt esošajos NAV 3D Secure darījumos.
3D drošs un atkārtots maksājums
Sākot ar 1. gada 2021. janvāri, 3D Secure būs obligāts visiem e-komercijas karšu darījumiem. Tomēr, tā kā tas gandrīz nav piemērojams atkārtotiem maksājumiem, banku
sistēmām tam ir atsevišķa darbplūsma.
Šajā nolūkā bankas izšķir
- CIT = klienta inicializēti darījumi
- MIT = tirgotāja inicializēti darījumi
Pirmais kartes darījums jūsu tirgotāja kontā ir jāapstiprina ar 3D Secure no 01.01.2021. Šāda veiksmīga autentifikācija ir obligāta prasība
lai vēlāk varētu iesniegt papildu rezervācijas tajā pašā kartē bez 3D Secure. Tāpēc klients ir jānodod savai karšu izdevējai bankai par pirmo debetu
iepriekš aprakstītajā kārtībā un autentificēties tur kā kartes turētājs. Ja pasūtījuma veikšanas brīdī debets nav plānots, piemēram,ampIzmēģinājuma perioda dēļ ar 3D Secure klienta klātbūtnē ir jāveic rezervācija (priekšautorizācija) vismaz viena eiro apmērā. Šīs rezervācijas tveršana nav nepieciešama.
Tomēr esošajiem klientiem nav jāveido 3D Secure autentifikācija. Ja pirmais veiksmīgais debets notika pirms 01.01.2021. gada XNUMX. janvāra, var pieņemt arī klienta ierakstu
ir veiksmīgi autentificēti. Jaunajiem klientiem, sākot ar 01.01.2021. gada 3. janvāri, XNUMXD debitoru autentifikācija ir obligāta pirmā debeta vai rezervācijas veikšanai (priekšautorizācija).
Lūdzu, ņemiet vērā: šajā ziņā banku sistēma skatās kartes datus, nevis klienta datus. Tātad, ja esošais klients izmanto jaunu karti pēc 01.01.2021., piemample jo iepriekšējā
vienai ir beidzies derīguma termiņš vai tāpēc, ka viņš ir mainījis kartes izdevējbanku, tas ir jauns atkārtots cikls no banku viedokļa view un pirmajai rezervācijai ir jābūt autentificētam ar 3D Secure.
Kad šī sākotnējā autentifikācija ir veiksmīgi veikta, visi turpmākie darījumi ir atbrīvoti no pienākuma izmantot 3D Secure. Tāpēc priekšnoteikumi atkārtotam maksājumam bez 3D Secure ir:
- Ir vismaz viens veiksmīgs debets vai rezervācija (priekšautorizācija), kas tika veikts ar 3D Secure vai arī notika pirms 01.01.2021. gada XNUMX. janvāra.
- pēc iesniegšanas uz to atsaucas uz esošu reģistrāciju un debetu
Lai informētu maksājumu sistēmu, ka tas ir atkārtots maksājums, ir jānosūta arī parametrs RECURRENCE.MODE = REPEATED. Tas signalizē sistēmai, ka a
par atkārtotu maksājumu jāziņo banku sistēmām.
Lūdzu, ņemiet vērā: Ja parametrs RECURRENCE.MODE = REPEATED tiek ievadīts, pirmo reizi ielādējot jaunu karti, 3D Secure pārsūtīšana tiks veikta, neskatoties uz šo parametru.
3D Secure ieviešanas pārbaude
3D Secure savienojumu varat pārbaudīt jebkurā laikā, izmantojot mūsu maksājumu sistēmu. Lai to izdarītu, darījumam izmantojiet režīmu “CONNECTOR_TEST”, kā parādīts piemamples augstāk.
Savienojuma dati šim testam:
| DROŠĪBA. Sūtītājs | 31HA07BC8142C5A171745D00AD63D182 |
| LIETOTĀJS.LOGIN | 31ha07bc8142c5a171744e5aef11ffd3 |
| LIETOTĀJS.PWD | 93167DE7 |
| DARĪJUMI. KANĀLS | 31HA07BC8142C5A171749A60D979B6E4 |
| Konfigurētas valūtas 3D versijai 2 | EUR, USD, SEK |
| Konfigurētas valūtas 3D versijai 1 | GBP, CZK, CHF |
Sistēmas vārtejas galapunkts ir vai nu
SGW vārteja:
- https://test-heidelpay.hpcgw.net/sgw/gtw - kodēts latīņu valodā-15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - kodēts UTF-8
NGW vārteja:
- https://test-heidelpay.hpcgw.net/ngw/post
Kredītkartes dati šim testam:
| zīmoli | karšu numuri | CVV | derīguma termiņš | piezīme |
| MasterCard | 5453010000059543 | 123 | nākotnes datums | 3D - parole: noslēpums |
| Vīza | 4711100000000000 | 123 | nākotnes datums | 3DS - parole: noslēpums! 33 |
Lūdzu, ņemiet vērā: 3D Secure 2. versijai nav jāievada parole, bet vienkārši noklikšķiniet uz saites ”Noklikšķiniet šeit, lai pabeigtu autentifikāciju.
Vienīgais veids, kā simulēt kļūdu ar 3D Secure 2. versiju, ir atļaut lapas ar saiti noildzi (aptuveni 18 minūtes).
Lasiet vairāk par šo rokasgrāmatu un lejupielādējiet PDF:
Dokumenti / Resursi
 |
Programmatūras 3D Secure Integration Guide [pdfDokumentācija Unzer, integrācijas rokasgrāmata, 3D Secure |
