Softwares 3D Secure Integration Guide Documentazione
Guida di Integrazione 3D Secure
Da u 01.01.2021 nantu à l'autentificazione cù dui fattori serà implementata cum'è un requisitu obligatoriu per tutte e transazzioni di pagamentu cù carta di ecommerce. Per rispettà st'obligazione, u
l'operatori di e rete di carte di creditu aduprà a cosiddetta prucedura 3D Secure. Per voi cum'è cummerciante hè obligatoriu esse capace di fà sta procedura per i vostri clienti da
01.01.2021. In seguitu truverete una descrizzione di i diversi modi di integrazione è cume a procedura 3D Secure deve esse implementata per elli.
Sceglite puru u metudu di integrazione chì aduprate
- Usate u modulu di pagamentu hCO?
- Stà aduprendu u modulu di pagamentu hPF?
- Trasformate i pagamenti senza aduprà una forma furnita da u sistema Unzer?
Per piacè nutate: Hè ancu impurtante in chì modu si facenu debiti o preautorizzazioni (riservazioni). Ancu se utilizate una forma di pagamentu da Unzer GmbH per a registrazione di dati di carta, u prucessu 3D Secure serà realizatu senza una forma di pagamentu quandu i dati di a carta sò prima addebitati o autorizati per a prima volta. In questu casu si applica u terzu modu d'integrazione senza una forma furnita da Unzer.
Per piacè nutate ancu:
Se utilizate pagamenti recurrenti (pagamenti d'abbunamentu), assicuratevi di leghje a sezione "Pagamentu Securizatu è Ricurrente 3D".
Procedura 3D Secure quandu si usa u modulu di pagamentu hCO
U modulu di pagamentu hCO hè digià cuncipitu per a prucedura 3D Secure. Ùn ci hè nisuna azzione supplementaria da u vostru latu necessaria per l'implementazione di a procedura. Tuttavia, voi
deve esse sicuru chì u vostru sistema pò gestisce e risposte currispundenti di u nostru sistema di pagamentu in casu chì u prucessu 3D Secure sia iniziatu. In a risposta asincrona da u
sistema di pagamentu à u vostru servitore, u risultatu di a transazzione hè trasmessu è deve esse valutatu quì prima di un ritornu URL hè trasmessa à u sistema di pagamentu.
Per questu scopu i seguenti parametri devenu esse valutati.
- CODICE.PROCESSING.RETURN. = 000.200.000
- PROCESSING.RETURN = Transazzione + in attesa
- TRATTamentu.RISULTAT = ACK
Spiegazione: U statutu di a transazzione hè "pendente", u parametru PROCESSING.RESULT
rapprisenta solu un risultatu preliminariu. Finu chì u prucessu 3D Secure hè realizatu, u statutu
fermanu pendenti.
U risultatu finale di a transazzione hè allora
- CODICE.PROCESSING.RETURN. = 000.000.000
- TRATTamentu.RISULTAT = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 o 000.200.000
- TRATTamentu.RISULTU = NOK
In u primu casu a transazzione hè stata cumpletata cù successu, in u secondu casu hà fallutu in generale. Quest'ultima pò avè varie ragioni, cumpresu un rifiutu di autentificassi. Puderete
riceve informazioni più dettagliate in i parametri "PROCESSING.RETURN" è "PROCESSING.RETURN.CODE".
Ricumandemu di fà un test per i dui messaghji. Per saperne di più infurmazioni nantu à cume fà un test è chì dettagli di a carta di creditu pudete aduprà per un test, per piacè vede quì sottu.
3D Secure procedure in usu di u modulu di pagamentu hPF
U modulu di pagamentu hPF hè ancu cuncepitu per aduprà a procedura 3DS dighjà. Ùn ci hè nisuna azzione addizionale da parte vostra necessaria per l'implementazione di a procedura. Cumu hè descrittu
per l'implementazione hCO a risposta da u sistema di pagamentu si face in dui passi, hè per quessa chì u vostru sistema deve verificà u valore di u PROCESSING.RETURN.CODE
parametru quandu elabureghja a risposta.
Per questu scopu i seguenti parametri devenu esse valutati.
- CODICE.PROCESSING.RETURN. = 000.200.000
- PROCESSING.RETURN = Transazzione + in attesa
- TRATTamentu.RISULTAT = ACK
Spiegazione: U statutu di a transazzione hè "pendente", u parametru PROCESSING.RESULT riprisenta solu un risultatu preliminariu. Finu chì u prucessu 3D Secure hè realizatu, u statutu
fermanu pendenti.
U risultatu finale di a transazzione hè allora
- CODICE.PROCESSING.RETURN. = 000.000.000
- TRATTamentu.RISULTAT = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 o 000.200.000
- TRATTamentu.RISULTU = NOK
In u primu casu a transazzione hè stata cumpletata cù successu, in u secondu casu hà fallutu in generale. Quest'ultima pò avè varie ragioni, cumpresu un rifiutu di autentificassi. Puderete
riceve informazioni più dettagliate in i parametri "PROCESSING.RETURN" è "PROCESSING.RETURN.CODE".
Ricumandemu di fà un test per i dui messaghji. Per saperne di più infurmazioni nantu à cume fà un test è chì dettagli di a carta di creditu pudete aduprà per un test, per piacè vede quì sottu.
3D Secure procedure cù cunnessione diretta
Se ùn aduprate micca un modulu di pagamentu furnitu da Unzer (ex heidelpay) per trattà i pagamenti cù a carta di creditu, o sì basta à registrà una carta aduprendu unu di i moduli è prucede a preautorizazione (riservazione) o debitu cum'è riferimentu à a registrazione cum'è cumunicazione diretta cù u sistema di pagamentu, duvete implementà u prucessu 3D Secure.
Flussu di transazzioni asincrone:
Questu hè un prucessu asincrunu in u quale u vostru servitore riceve un trasferimentu URL (Redirigisce URL) da u nostru sistema di pagamentu. U vostru servitore deve trasmette u cliente à questu URL da pudè realizà l'autentificazione cù a prucedura 3D Secure. U risultatu di sta autentificazione 3D Secure hè signalatu direttamente à Unzer da a banca chì emette a carta.
Dopu l'autenticazione riesciuta, a transazzione hè ulteriormente trattata in u sistema Unzer in u modu chì sapete dighjà mandendu à u vostru sistema un risultatu generale à a fine, à quale risponde
cù una redirect URL. U sistema di pagamentu reindirizzarà u cliente à u vostru sistema cù questu redirect URL da u vostru sistema
Nota: In questu flussu di travagliu u vostru sistema riceve duie risposte da u sistema di pagamentu:
- Unu cù u statutu "in attesa" (PROCESSING.RETURN.CODE = 000.200.000 è PROCESSING.RETURN = Transazione + in attesa) è i parametri di reindirizzamentu à a banca chì emette a carta di u cliente
- Unu cù u risultatu finale di u debitu o di a riservazione. Ci hè ancu dui redirect URLHè menzionatu in questu prucessu, unu da u sistema di pagamentu à u quale u cliente deve esse redirigitu per autentificà à a so banca emittente di carta è unu da u vostru sistema, quandu riceve u risultatu finale, per redirigere u cliente in u vostru sistema.
I seguenti cambiamenti saranu fatti à a prucedura regulare. Per piacè nutate chì per via di l'implementazione di altri metudi di pagamentu asincroni, cum'è Paypal, alcuni di questi
i prucessi ponu esiste dighjà in a vostra implementazione.
- Risposta URL
In a prima chjamata (n ° 2 in u schema) à u sistema di pagamentu, una "Risposta URL"Deve esse passatu in u gruppu frontend.
Per piacè nutate: U parametru IDENTIFICATION.REFERENCEID hè pertinente solu se fate riferimentu à una registrazione o altra transazzione esistente - Trasfurmazione Redirect URL Se l'autenticazione hè necessaria, una redirezione URL è altri parametri in u gruppu di redirect sò trasferiti in a risposta da u sistema di pagamentu (N ° 5 in u schema).
- Trasmissione di u cliente à u redirect URL
Se u gruppu di redirect risponde cù una redirect URL, u navigatore di u cliente deve esse redirettatu versu questu URL (N ° 6 in u schema) per eseguisce l'autenticazione. I parametri addiziunali da u gruppu di redirect devenu esse trasferiti à l'esternu websitu cum'è parametri POST.
Da nutà: Parametri addiziunali sò restituiti in u gruppu "PROCESSING.REDIRECT.xxx" solu cù 3D Secure Version 1 (ancu quì u numeru è i nomi ponu varià), invece chì cù 3D Version 2 solu un PROCESSING.REDIRECT.URL cum'è mostratu sottu hè restituitu: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run Questu significa chì, independentemente di u tippu è u numeru di parametri, u navigatore client deve redirige à u PROCESSING.REDIRECT.URL.
Sottu truverete un codice simplice example di cumu una tale redirect pò esse eseguita. U parte hè destinata à informà i clienti finali chì i so sistemi ùn supportanu micca Javascript o l'anu disattivatu. Ricumandemu fermamente chì a reindirizzamentu sia fatta in a finestra attiva di u navigatore di u cliente è micca di utilizà finestre popup o nuove finestre di navigatore, perchè questu puderia
irritanu i clienti è i cunducenu à chjude a pagina ch'elli sò ridiretti.
- Verificazione di risultati asincroni
U risultatu di l'autentificazione hè mandatu in modu asincrunu à u vostru servitore. U sistema di pagamentu aspetta un validu URL cum'è risposta. (N ° 12 è 13 in u schema). Per successu o rifiutatu
pagamenti, un altru URL pò risponde quì da u vostru sistema. - Percorsu di ritornu di u cliente
U sistema di pagamentu redirige u cliente à u URL furnita da u sistema di u mercante dopu u prucessu di autenticazione è a transazzione di pagamentu sò state compie.
Per piacè nutate: Passi 4.) è 5.) procedenu esattamente u listessu modu chì site dighjà familiarizatu in e transazzione NONE 3D Secure esistenti.
Pagamentu Securizatu è Ricurrente 3D
À partesi da u 1 di ghjennaghju 2021, 3D Secure serà ubligatoriu per tutte e transazzione cù e-commerce. Tuttavia, postu chì questu ùn hè guasi applicabile per i pagamenti ricorrenti, a banca
i sistemi anu un flussu di travagliu separatu per questu.
Per questu scopu, e banche distinguenu trà
- CIT = transazzione inizializata da u cliente
- MIT = transazzione inizializata mercante
A prima transazzione di una carta in u vostru contu mercante deve esse autentificata cù 3D Secure da 01.01.2021 in poi. Una tale autenticazione riesciuta hè un requisitu obligatoriu in
per esse capace di invià successivamente ulteriori prenotazioni nantu à a stessa carta senza 3D Secure. U cliente deve dunque esse trasmessu à a so banca chì emette a carta per u primu debitu in
in cunfurmità cù a prucedura sopra descritta è si autentificheghja quì cum'è detentore di carta. Se un debitu ùn hè micca previstu à u mumentu di l'ordine, per esampà causa di un periodu di prova, una riservazione (pre-autorizazione) di almenu un euro deve esse fatta cù 3D Secure in presenza di u cliente invece. Catturà sta riservazione ùn hè micca necessariu.
Per i clienti esistenti, tuttavia, nisuna autenticazione 3D Secure ùn deve esse fatta. Se u primu debitu successu hè statu fattu prima u 01.01.2021, u registru di u cliente pò ancu esse presu
sò stati autenticati cù successu. Per i clienti novi da u 01.01.2021, invece, l'autenticazione 3D Secure hè ubligatoria per u primu debitu o riservazione (pre-autorizazione).
Da nutà: In stu rispettu, u sistema bancariu guarda i dati di a carta, micca i dati di i clienti. Allora se un cliente esistente utilizza una nova carta dopu u 01.01.2021, per esample perchè u precedente
unu hè scadutu o perchè hà cambiatu a so banca di emissione di carte, questu hè un novu ciclu ricorrente da u puntu di e banche di view è deve esse autentificatu cù 3D Secure per a prima riservazione.
Una volta chì sta autentificazione iniziale hè stata riesciuta, tutte e transazzioni successive sò esentate da l'obbligazione di aduprà 3D Secure I prerequisiti per u pagamentu ricorrente senza 3D Secure sò dunque:
- Ci hè almenu un debitu o una riservazione riesciuta (pre-autorizazione) chì hè stata effettuata cù 3D Secure o hè stata fatta prima di u 01.01.2021.
- hè riferitu à una registrazione esistente è debitu à a presentazione
Per fà sapè à u sistema di pagamentu, chì si tratta di un pagamentu recurrente, u parametru RECURRENCE.MODE = RIPETU deve esse inviatu ancu. Questu signale à u sistema chì a
U pagamentu recurrente deve esse segnalatu à i sistemi bancarii.
Da nutà: Se u paràmetru RECURRENCE.MODE = RIPETITU hè inseritu quandu una nova carta hè caricata per a prima volta, 3D Secure forwarding serà realizatu malgradu stu parametru.
Pruvenza di l'implementazione 3D Secure
Pudete pruvà a cunnessione 3D Secure in ogni mumentu attraversu u nostru sistema di pagamentu. Per fà cusì, aduprate u modu "CONNECTOR_TEST" per una transazzione, cum'è mostratu in l'esamples sopra.
Dati di cunnessione per questa prova:
| SICUREZZA.MITTENTE | 31HA07BC8142C5A171745D00AD63D182 |
| USER.LOGIN | 31ha07bc8142c5a171744e5aef11ffd3 |
| USER.PWD | 93167DE7 |
| TRANSACTION.CHANNEL | 31HA07BC8142C5A171749A60D979B6E4 |
| Valute configurate per 3D Versione 2 | EUR, USD, SEK |
| Valute configurate per 3D Versione 1 | GBP, CZK, CHF |
L'endpoint di a porta di sistema hè
Passerella SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - Latin-15 codificatu
- https://test-heidelpay.hpcgw.net/sgw/gtwu - UTF-8 codificatu
Porta NGW:
- https://test-heidelpay.hpcgw.net/ngw/post
Dati di a carta di creditu per questa prova:
| marche | numeri di carta | CVV | data di scadenza | nota |
| MasterCard | 5453010000059543 | 123 | data futura | 3D - password: secret3 |
| Visa | 4711100000000000 | 123 | data futura | 3DS - password: secret! 33 |
Da nutà: Per 3D Secure Version 2, ùn hè micca necessariu inserisce una password, ma basta à cliccà nantu à u ligame "Cliccate quì per cumplettà l'autenticazione.
L'unicu modu per simulare un errore cù 3D Secure Version 2 hè di lascià a pagina cù u ligame fora di tempu (circa 18 minuti).
Leghjite più nantu à stu manuale è scaricate PDF:
Documenti / Risorse
 |
Guida di Integrazione 3D Secure di Software [pdfDocumentazione Unzer, Guida di Integrazione, 3D Secure |
