Documentazione della guida all'integrazione di software 3D Secure
Guida all'integrazione 3D Secure
Dal 01.01.2021 in poi l'autenticazione a due fattori sarà implementata come requisito obbligatorio per tutte le transazioni di pagamento con carta di e-commerce. Al fine di adempiere a tale obbligo, il
gli operatori di reti di carte di credito utilizzeranno la cosiddetta procedura 3D Secure. Per te come commerciante è obbligatorio poter eseguire questa procedura per i tuoi clienti da
01.01.2021. Di seguito troverai una descrizione delle diverse modalità di integrazione e di come la procedura 3D Secure deve essere implementata per loro.
Seleziona il metodo di integrazione che utilizzi
- Stai usando il modulo di checkout hCO?
- Stai usando il modulo di checkout hPF?
- Elaborate i pagamenti senza utilizzare un modulo fornito dal sistema Unzer?
Notare che: È anche importante il modo in cui vengono effettuati gli addebiti o le preautorizzazioni (prenotazioni). Anche se si utilizza un modulo di pagamento di Unzer GmbH per la registrazione dei dati della carta, il processo 3D Secure verrà eseguito senza un modulo di pagamento quando i dati della carta vengono addebitati per la prima volta o autorizzati per la prima volta. In questo caso si applica la terza modalità di integrazione senza modulo fornito da Unzer.
Si prega di notare anche:
Se utilizzi pagamenti ricorrenti (pagamenti in abbonamento), assicurati di leggere la sezione "3D Secure e pagamenti ricorrenti".
Procedura 3D Secure quando si utilizza il modulo di pagamento hCO
Il modulo di checkout hCO è già progettato per la procedura 3D Secure. Non è necessaria alcuna azione aggiuntiva da parte tua per l'attuazione della procedura. Tuttavia, tu
devi assicurarti che il tuo sistema possa gestire le risposte corrispondenti del nostro sistema di pagamento nel caso in cui venga avviato il processo 3D Secure. Nella risposta asincrona da
sistema di pagamento al tuo server, il risultato della transazione viene trasmesso e deve essere valutato lì prima di un reso URL viene trasmesso al sistema di pagamento.
A tal fine è necessario valutare i seguenti parametri.
- CODICE.RITORNO.ELABORAZIONE = 000.200.000
- PROCESSING.RETURN = Transazione + in sospeso
- RISULTATO ELABORAZIONE = ACK
Spiegazione: Lo stato della transazione è "in sospeso", il parametro PROCESSING.RESULT
rappresenta solo un risultato preliminare. Finché viene eseguito il processo 3D Secure, lo stato
rimangono in sospeso.
Il risultato finale della transazione è quindi
- CODICE.RITORNO.ELABORAZIONE = 000.000.000
- RISULTATO ELABORAZIONE = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 o 000.200.000
- RISULTATO DI ELABORAZIONE = NOK
Nel primo caso la transazione è stata completata con successo, nel secondo caso è fallita complessivamente. Quest'ultimo può avere vari motivi, tra cui il rifiuto di autenticare. Desideri
ricevere informazioni più dettagliate nei parametri “PROCESSING.RETURN” e “PROCESSING.RETURN.CODE”.
Ti consigliamo di eseguire un test per entrambi i messaggi. Per ulteriori informazioni su come eseguire un test e su quali dati della carta di credito è possibile utilizzare per un test, vedere di seguito.
Procedura 3D Secure quando si utilizza il modulo di pagamento hPF
Anche il modulo di pagamento hPF è progettato per utilizzare già la procedura 3DS. Non è necessaria alcuna azione aggiuntiva da parte tua per l'attuazione della procedura. Come descritto
per l'implementazione hCO la risposta dal sistema di pagamento avviene in due passaggi, motivo per cui il tuo sistema deve verificare il valore di PROCESSING.RETURN.CODE
parametro durante l'elaborazione della risposta.
A tal fine è necessario valutare i seguenti parametri.
- CODICE.RITORNO.ELABORAZIONE = 000.200.000
- PROCESSING.RETURN = Transazione + in sospeso
- RISULTATO ELABORAZIONE = ACK
Spiegazione: Lo stato della transazione è "in sospeso", il parametro PROCESSING.RESULT rappresenta solo un risultato preliminare. Finché viene eseguito il processo 3D Secure, lo stato
rimangono in sospeso.
Il risultato finale della transazione è quindi
- CODICE.RITORNO.ELABORAZIONE = 000.000.000
- RISULTATO ELABORAZIONE = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 o 000.200.000
- RISULTATO DI ELABORAZIONE = NOK
Nel primo caso la transazione è stata completata con successo, nel secondo caso è fallita complessivamente. Quest'ultimo può avere vari motivi, tra cui il rifiuto di autenticare. Desideri
ricevere informazioni più dettagliate nei parametri “PROCESSING.RETURN” e “PROCESSING.RETURN.CODE”.
Ti consigliamo di eseguire un test per entrambi i messaggi. Per ulteriori informazioni su come eseguire un test e su quali dati della carta di credito è possibile utilizzare per un test, vedere di seguito.
Procedura 3D Secure con connessione diretta
Se non utilizzi un modulo di pagamento fornito da Unzer (ex heidelpay) per elaborare i pagamenti con carta di credito, o se registri semplicemente una carta utilizzando uno dei moduli ed elabori la preautorizzazione (prenotazione) o l'addebito come riferimento alla registrazione come comunicazione diretta con il sistema di pagamento, è necessario implementare il processo 3D Secure.
Flusso delle transazioni asincrone:
Questo è un processo asincrono in cui il tuo server riceve un inoltro URL (Reindirizzare URL) dal nostro sistema di pagamento. Il tuo server deve inoltrare il cliente a questo URL in modo che possa effettuare l'autenticazione tramite procedura 3D Secure. Il risultato di questa autenticazione 3D Secure viene segnalato direttamente a Unzer dalla banca emittente della carta.
Dopo l'autenticazione con successo, la transazione viene ulteriormente elaborata nel sistema Unzer nel modo che già conosci inviando al tuo sistema un risultato complessivo alla fine, a cui rispondi
con un reindirizzamento URL. Il sistema di pagamento reindirizzerà quindi il cliente al tuo sistema utilizzando questo reindirizzamento URL dal sistema
Nota: in questo flusso di lavoro il tuo sistema riceve due risposte dal sistema di pagamento:
- Uno con lo stato "in sospeso" (PROCESSING.RETURN.CODE = 000.200.000 e PROCESSING.RETURN = Transaction + pending) e i parametri di reindirizzamento alla banca emittente della carta del cliente
- Uno con il risultato finale dell'addebito o della prenotazione. Esistono anche due reindirizzamenti URLÈ menzionato in questo processo, uno dal sistema di pagamento a cui il cliente deve essere reindirizzato per autenticarsi presso la banca emittente della sua carta e uno dal tuo sistema, quando riceve il risultato finale, per reindirizzare il cliente nel tuo sistema.
Le seguenti modifiche verranno apportate alla normale procedura. Si noti che a causa dell'implementazione di altri metodi di pagamento asincroni, come Paypal, alcuni di questi
processi potrebbero già esistere nella tua implementazione.
- Risposta URL
Nella prima chiamata (n.2 nello schema) al sistema di pagamento, un “Risposta URL"Deve essere passato nel gruppo frontend.
Notare che: Il parametro IDENTIFICATION.REFERENCEID è rilevante solo se si fa riferimento a una registrazione o ad un'altra transazione già esistente - Reindirizzamento in elaborazione URL Se è richiesta l'autenticazione, un reindirizzamento URL e altri parametri nel gruppo di reindirizzamento vengono trasferiti nella risposta dal sistema di pagamento (n. 5 nel diagramma).
- Inoltro del cliente al reindirizzamento URL
Se il gruppo di reindirizzamento risponde con un reindirizzamento URL, il browser del cliente deve essere reindirizzato a questo URL (N. 6 nel diagramma) per eseguire l'autenticazione. I parametri aggiuntivi dal gruppo di reindirizzamento devono essere trasferiti all'esterno website come parametri POST.
Nota: parametri aggiuntivi vengono restituiti nel gruppo "PROCESSING.REDIRECT.xxx" solo con 3D Secure Versione 1 (anche lì il numero e la denominazione possono variare), mentre con 3D Versione 2 solo PROCESSING.REDIRECT.URL viene restituito come mostrato di seguito: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run Ciò significa che indipendentemente dal tipo e dal numero di parametri, il browser del client deve reindirizzare a PROCESSING.REDIRECT.URL.
Di seguito troverai un semplice codice example di come un tale reindirizzamento può essere eseguito. Il parte ha lo scopo di informare i clienti finali i cui sistemi non supportano Javascript o lo hanno disabilitato. Si consiglia vivamente di eseguire il reindirizzamento all'interno della finestra del browser attiva del cliente e di non utilizzare finestre popup o nuove finestre del browser, poiché ciò potrebbe
irritare i clienti e indurli a chiudere la pagina a cui vengono reindirizzati.
- Controllo del risultato asincrono
Il risultato dell'autenticazione viene inviato in modo asincrono al tuo server. Il sistema di pagamento si aspetta un valido URL come risposta. (N. 12 e 13 nel diagramma). Per successo o rifiutato
pagamenti, un diverso URL può essere risposto qui dal tuo sistema. - Percorso di ritorno del cliente
Il sistema di pagamento reindirizza il cliente al file URL fornito dal sistema del commerciante dopo che il processo di autenticazione e la transazione di pagamento sono state completate.
Nota: i passaggi 4.) e 5.) procedono esattamente nello stesso modo in cui si ha già familiarità con le transazioni NONE 3D Secure esistenti.
Pagamento sicuro e ricorrente in 3D
Dal 1 ° gennaio 2021, 3D Secure sarà obbligatorio per tutte le transazioni con carta di e-commerce. Tuttavia, poiché questo è difficilmente applicabile per i pagamenti ricorrenti, il banking
i sistemi hanno un flusso di lavoro separato per questo.
A tal fine, le banche distinguono tra
- CIT = transazioni inizializzate dal cliente
- MIT = transazioni inizializzate dal commerciante
La prima transazione di una carta nel tuo account commerciante deve essere autenticata con 3D Secure dal 01.01.2021 in poi. Una tale autenticazione di successo è un requisito obbligatorio in
per poter inviare successivamente ulteriori prenotazioni sulla stessa carta senza 3D Secure. Il cliente deve quindi essere inoltrato alla banca che ha emesso la carta per il primo addebito
secondo la procedura sopra descritta e ivi autenticarsi come titolare della carta. Se non è previsto un addebito al momento dell'ordine, ad esample a causa di un periodo di prova, deve invece essere effettuata una prenotazione (pre-autorizzazione) di almeno un euro con 3D Secure in presenza del cliente. L'acquisizione di questa prenotazione non è necessaria.
Per i clienti esistenti, tuttavia, non è necessario eseguire l'autenticazione 3D Secure. Se il primo addebito andato a buon fine è avvenuto prima del 01.01.2021, si può presumere che lo sia anche il record del cliente
sono stati autenticati con successo. Per i nuovi clienti a partire dal 01.01.2021, invece, l'autenticazione 3D Secure è obbligatoria per il primo addebito o prenotazione (pre-autorizzazione).
Nota: a questo proposito, il sistema bancario esamina i dati della carta, non i dati del cliente. Quindi, se un cliente esistente utilizza una nuova carta dopo il 01.01.2021, ad esample perché il precedente
uno è scaduto o perché ha cambiato banca emittente della carta, questo è un nuovo ciclo ricorrente dal punto di vista delle banche view e deve essere autenticato con 3D Secure per la prima prenotazione.
Una volta che questa prima autenticazione è stata eseguita con successo, tutte le ulteriori transazioni sono esentate dall'obbligo di utilizzare 3D Secure.I prerequisiti per il pagamento ricorrente senza 3D Secure sono quindi:
- Esiste almeno un addebito o una prenotazione (pre-autorizzazione) avvenuta con successo con 3D Secure o avvenuta prima del 01.01.2021.
- fa riferimento a una registrazione esistente e addebita al momento della presentazione
Per far sapere al sistema di pagamento che si tratta di un pagamento ricorrente, è necessario inviare anche il parametro RECURRENCE.MODE = REPEATED. Questo segnala al sistema che a
il pagamento ricorrente deve essere segnalato ai sistemi bancari.
Nota: se il parametro RECURRENCE.MODE = REPEATED viene inserito quando una nuova carta viene caricata per la prima volta, l'inoltro 3D Secure verrà eseguito nonostante questo parametro.
Testare l'implementazione 3D Secure
Puoi testare la connessione 3D Secure in qualsiasi momento tramite il nostro sistema di pagamento. Per fare ciò, utilizzare la modalità "CONNECTOR_TEST" per una transazione, come mostrato nell'esempioample sopra.
Dati di connessione per questo test:
| SICUREZZA INVIATORE | 31HA07BC8142C5A171745D00AD63D182 |
| LOGIN UTENTE | 31ha07bc8142c5a171744e5aef11ffd3 |
| UTENTE.PWD | 93167DE7 |
| TRANSAZIONE.CANALE | 31HA07BC8142C5A171749A60D979B6E4 |
| Valute configurate per la versione 3D 2 | EUR, USD, SEK |
| Valute configurate per la versione 3D 1 | GBP, CZK, CHF |
L'endpoint del gateway di sistema è uno dei due
Gateway SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - con codifica Latin-15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - codificato UTF-8
Gateway NGW:
- https://test-heidelpay.hpcgw.net/ngw/post
Dati della carta di credito per questo test:
| marche | numeri di carta | Codice CVV | data di scadenza | nota |
| MasterCard | 5453010000059543 | 123 | data futura | 3D - password: secret3 |
| Visa | 4711100000000000 | 123 | data futura | 3DS - password: segreta! 33 |
Nota: per 3D Secure versione 2, non è necessario inserire una password, ma è sufficiente fare clic sul collegamento "Fare clic qui per completare l'autenticazione.
L'unico modo per simulare un errore con 3D Secure versione 2 è lasciare che la pagina con il collegamento scada (circa 18 minuti).
Leggi di più su questo manuale e scarica il PDF:
Documenti / Risorse
 |
Guida all'integrazione dei software 3D Secure [pdf] Documentazione Unzer, Guida all'integrazione, 3D Secure |
