Integration Types
Altre funzionalità
Card Payments
Mobile Wallets
Alternative Payment Methods
Resources
EMV 3DS, noto anche come 3DS2 nel gateway, è la nuova versione progettata per migliorare la sicurezza degli acquisti online, offrendo al contempo checkout senza problemi ai paganti che sono considerati a basso rischio dal server di Controllo dell'accesso (ACS). L'ACS può determinare il rischio utilizzando le informazioni fornite dall'esercente, l'impronta digitale del browser e/o le precedenti interazioni con il pagante. L'ACS sottopone il pagante a una verifica (ad esempio, l'immissione di un PIN) solo quando è richiesta un'ulteriore verifica per autenticare il pagante fornendo quindi tassi di conversione più elevati. I circuiti di autenticazione supportati per JCB includono Mastercard SecureCode™, Verified by Visa™, American Express SafeKey™, Diners Club/Discover ProtectBuy e JCB J/Secure.
Per i mercati a cui è stata concessa un'estensione 3DS1, fare clic Qui.
Di seguito sono riportati alcuni termini chiave utilizzati nella documentazione di integrazione di 3DS.
Termine | Descrizione |
---|---|
Server di Controllo dell'accesso (ACS) | Un componente che opera nel dominio dell'issuer, verifica se è disponibile l'autenticazione per un determinato numero di carta e tipo di dispositivo e autentica specifiche transazioni. |
Chiamata metodo ACS | Si applica all'autenticazione 3DS2. È una chiamata che consente all'ACS di raccogliere dati aggiuntivi per determinare la valutazione del rischio per il pagante. Quando 3DS2 è disponibile e quando i dettagli della chiamata ACS vengono restituiti nella risposta dopo aver avviato l'autenticazione, questi dettagli vengono passati al browser del pagante, che vengono inviati come post della form in un iframe nascosto, in modo che ACS possa raccogliere ulteriori dati. |
Flusso senza intoppi | Un flusso di autenticazione in cui il pagante non è tenuto a rispondere a una verifica perché l'ACS considera il pagante come a basso rischio. |
Flusso di verifica | Un flusso di autenticazione in cui il pagante viene reindirizzato all'ACS ed è tenuto a rispondere a una verifica per identificarsi, poiché l'ACS non dispone di informazioni sufficienti per ritenere il pagante come a basso rischio. |
Sessione di pagamento | Una sessione di pagamento, o semplicemente sessione, è un contenitore temporaneo per i campi e i valori delle richieste delle operazioni che fanno riferimento a una sessione. È possibile utilizzare una sessione in un'operazione per fare riferimento ai campi e ai valori delle richieste anziché fornirli direttamente nella richiesta di operazione. Quando il gateway riceve un'operazione che fa riferimento a una sessione, formula la richiesta finale combinando i campi della richiesta nella sessione con quelli forniti direttamente nella richiesta. Per ulteriori informazioni, vedere sessione di pagamento. |
Autenticazione della sessione | Autenticazione tramite una sessione di pagamento. Questa autenticazione consente ai paganti di fornire i propri dettagli di pagamento direttamente al gateway tramite un'interazione lato client con il gateway, tramite il browser di un pagante o un'app sul dispositivo mobile del pagante. Utilizza un meccanismo di autenticazione HTTP di base (simile all'autenticazione con password) in cui è necessario fornire "merchant.<your gateway merchant ID>" nella parte userid e l'ID sessione nella parte password. Per utilizzare questo tipo di autenticazione, è innanzitutto necessario creare una sessione inviando una richiesta di sessione (vedere Create Session [REST][NVP]) dal proprio server al server del gateway. |
Autenticazione esercente | Un meccanismo che consente all'esercente di autenticare le richieste API al gateway, ad esempio, autenticazione password/certificato/sessione. |
API di autenticazione | Un'API lato server composta da due operazioni, Initiate Authentication e Authenticate Payer, che deve essere inviata dal proprio server al server del gateway. Può anche essere utilizzata come API lato client usando l'autenticazione basata sulla sessione. |
API JavaScript 3DS | Un'API JavaScript lato client che consente di avviare l'autenticazione 3DS dal browser del pagante utilizzando autenticazione basata sulla sessione. |
Canale di autenticazione | Indica dove si sta verificando l'autenticazione 3DS, nel browser del pagante, in un'app sul dispositivo mobile del pagante o nel proprio sistema, in cui non è presente nessun pagante per interagire. Questi canali hanno implicazioni in termini di tipi e flussi di autenticazione disponibili, ad esempio 3DS1 può essere supportato solo nel browser con un pagante disponibile per l'interazione con l'ACS. |
Scopo autenticazione |
|
Per utilizzare il servizio di autenticazione 3DS del gateway:
Il diagramma seguente illustra il flusso di autenticazione per un pagamento in cui il pagante è autenticato utilizzando 3DS2.
Il flusso di autenticazione per una corretta autenticazione è il seguente:
Il gateway supporta le seguenti modalità di autenticazione 3DS:
Per le domande frequenti generali su 3-D Secure, vedere Domande frequenti sull'autenticazione.
Il gateway supporta le seguenti opzioni di integrazione per 3DS.
Opzione di integrazione | Quando utilizzarlo | Modalità di transazione supportate |
---|---|---|
Hosted Checkout | Questa è l'opzione di integrazione più semplice. Per avviare l'autenticazione 3DS e altre operazioni 3DS direttamente dal browser del pagante, è innanzitutto necessario stabilire il canale di autenticazione in cui il server dell'esercente deve comunicare con il server del gateway per creare una sessione sul gateway. L'ID sessione generato dal gateway viene quindi incluso in tutte le richieste di autenticazione avviate dal browser come parametro della password (vedere autenticazione basata sulla sessione) |
Autenticazione e transazione di pagamento |
API JavaScript 3DS | Si tratta di un'integrazione JavaScript lato client che consente all'esercente di avviare l'autenticazione 3DS dalla pagina di pagamento del proprio sito Web. Utilizzare questa opzione se si desidera consentire al pagante di inviare i propri dettagli di pagamento direttamente al gateway dal browser. Per avviare l'autenticazione 3DS e altre operazioni 3DS direttamente dal browser del pagante, è innanzitutto necessario stabilire il canale di autenticazione in cui il server dell'esercente deve comunicare con il server del gateway per creare una sessione sul gateway. L'ID sessione generato dal gateway viene quindi incluso in tutte le richieste di autenticazione avviate dal browser come parametro della password (vedere autenticazione basata sulla sessione). |
Solo autenticazione Autenticazione e transazione di pagamento |
API di autenticazione | Si tratta di un'opzione di integrazione lato server che consente il controllo totale sulla propria integrazione, ma che richiede il massimo sforzo di integrazione. Utilizzare questa opzione se viene richiesto di personalizzare le interazioni API tra il browser del pagante e il gateway. È necessario eseguire le operazioni necessarie per la gestione dei flussi di integrazione 3DS direttamente dal server dell'esercente al server del gateway. Può anche essere utilizzata come API lato client usando l'autenticazione basata sulla sessione. |
Solo autenticazione Autenticazione e transazione di pagamento. |