Sia 3DS1 che 3DS2 sono disponibili per l'integrazione end-to-end degli appuntamenti del Centro azioni. Puoi implementare una di queste opzioni (o entrambe) per la tua integrazione.
3DS1 o 3DS2 soddisfano il requisito dell'autenticazione forte del cliente della PSD2, ma ci sono alcune differenze fondamentali:
- 3DS1: puoi decidere di attivare 3DS1 per una transazione quando hai
segnali 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 direttiva 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 l'aggiunta di altri campi al
feed del commerciante all'interno del messaggio TokenizationConfig. Se
tutti i pagamenti vengono inviati allo stesso account, dovrai ripetere il valore all'interno di ogni
voce del commerciante. Se i pagamenti vengono effettuati su conti diversi, i valori di ogni voce del commerciante dovranno essere relativi all'account che ha acquisito i fondi durante la transazione.
Modifiche al feed del commerciante
merchant_of_record_name: nome del commerciante registrato (MOR). Questo nome visibile all'utente verrà mostrato nelle verifiche 3DS2.payment_country_code: paese in cui verrà elaborata la transazione, in formato ISO 3166-1 alpha-2.- Messaggio
CardNetworkParameters: questo messaggio viene ripetuto con i valori specifici di reti diverse (necessario 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 della banca acquirente utilizzata per l'elaborazione della carta.acquirer_merchant_id: l'identificatore del commerciante assegnato dall'acquirente al commerciante per essere utilizzato nell'autorizzazione delle transazioni (per le transazioni Visa e American Express).
Se aggiungi questi campi al tuo feed del commerciante, riceverai un crittogramma 3DS2 entro i unparsed_payment_method_token ricevuti dal tuo server di prenotazione ogni volta che la direttiva PSD2 si applica alla transazione. Devi trasferire unparsed_payment_method_token e il relativo crittogramma incorporato al tuo partner di elaborazione in conformità con la sua specifica.
Implementazione di 3DS1
Modifiche al server di prenotazione
Effettueremo una richiesta CreateBooking e, se stabilisci che 3DS1 è necessario per la transazione, restituisci un elemento Booking Failure dal metodo CreateBooking e specifichi PAYMENT_REQUIRES_3DS1 come causa. In questa 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 PaymentAutenticazione. Da pubblicare sul modulo ACSUrl.transaction_id= un identificatore utilizzato dal provider ACS. Da pubblicare nel modulo ACSUrl.md_merchant_data= dati che il Centro azioni condividere con il provider ACS, se forniti.
Quindi, invieremo nuovamente la richiesta
CreateBooking
originale con l'elemento pa_response che si trova all'interno del
messaggio PaymentInformation. Il campo pa_response conterrà il payload che ci viene restituito da un provider ACS e deve essere utilizzato da te per autorizzare la transazione con il tuo processore.
Ecco un diagramma che descrive il flusso 3DS1:
