Sia 3DS1 che 3DS2 sono disponibili per l'integrazione di Prenotazioni end-to-end di Actions Center. Puoi implementare una o entrambe queste opzioni per l'integrazione.
Sia 3DS1 che 3DS2 soddisfano il requisito di autenticazione forte del cliente della direttiva PSD2, ma esistono alcune differenze fondamentali:
- 3DS1: puoi decidere di attivare 3DS1 per una transazione quando hai indicatori che indicano che l'addebito è fraudolento.
- L'implementazione di 3DS1 richiede modifiche al server di prenotazione.
- 3DS2: 3DS2 verrà utilizzato solo per le transazioni in cui si applica la PSD2 (la banca acquirente e la banca del cliente si trovano nel SEE).
- L'implementazione di 3DS2 richiede modifiche al feed del commerciante.
Implementazione di 3DS2
L'implementazione di 3DS2 richiede di aggiungere altri campi al feed del commerciante all'interno del messaggio TokenizationConfig
. Se tutti i pagamenti vanno allo stesso account, dovrai ripetere il valore in ogni voce del commerciante. Se i pagamenti vanno su account diversi, i valori in ogni voce del commerciante dovranno essere per l'account che acquisisce i fondi all'interno della transazione.
Modifiche al feed dei commercianti
merchant_of_record_name
: nome del commerciante registrato (MOR). Questo nome visibile all'utente verrà mostrato nelle sfide 3DS2.payment_country_code
: il paese in cui verrà elaborata la transazione, in formato ISO 3166-1 alpha-2.- Messaggio
CardNetworkParameters
: questo messaggio viene ripetuto con i valori specifici per le diverse emittenti (obbligatorio solo per Visa e American Express)card_network
: la rete (Visa, American Express) a cui si applicano questi valoriacquirer_bin
: il numero di identificazione della banca acquiring utilizzato per l'elaborazione della carta.acquirer_merchant_id
: l'identificatore del commerciante assegnato dall'acquirente al commerciante per l'utilizzo nell'autorizzazione delle transazioni (per le transazioni Visa e American Express).
Aggiungendo questi campi al feed del commerciante, riceverai un criptgramma 3DS2
all'interno del unparsed_payment_method_token
ricevuto dal
tuo server di prenotazione ogni volta che PSD2 si applica alla transazione. Devi
passare unparsed_payment_method_token
e il relativo
criptogramma incorporato al tuo partner di elaborazione in conformità con le sue
specifiche.
Implementazione di 3DS1
Modifiche al server di prenotazione
Effetteremo una richiesta CreateBooking
e, se stabilisci che 3DS1 è necessario per la transazione, restituisci un
Booking Failure
dal tuo metodo CreateBooking
e specifica
PAYMENT_REQUIRES_3DS1
come causa. Nella risposta di errore
dovrai anche specificare il messaggio ThreeDS1Parameters
all'interno del messaggio PaymentFailureInformation
:
acs_url
= l'URL da cui caricare un modulo da presentare all'utente per l'autenticazione.pa_req
= una richiesta di autenticazione pagamenti. Da pubblicare nel modulo ACSUrl.transaction_id
= un identificatore utilizzato dal provider ACS. Da pubblicare nel modulo ACSUrl.md_merchant_data
= dati da condividere da parte di Actions Center con il fornitore ACS, se fornito.
Invieremo di nuovo la richiesta CreateBooking
originale con il valore pa_response
all'interno del messaggio PaymentInformation. Il campo pa_response
conterrà il payload che ci viene restituito da un fornitore ACS e deve essere utilizzato per autorizzare la transazione con l'elaboratore.
Ecco un diagramma che descrive il flusso 3DS1: