Aggiungere il supporto di 3DS1 e 3DS2

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 valori
    • acquirer_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:

Figura 1: diagramma del processo 3DS1
Figura 1: diagramma del processo 3DS1