La continua evoluzione tecnologica e l’aumento del numero di transazioni online ha reso necessario un aggiornamento dell’infrastruttura di autenticazione in modo da incrementare l’affidabilità di tutto il sistema e, allo stesso tempo, migliorare customer experience e tassi di conversione dei carrelli.

La collaborazione tra Circuiti, autorità europee e gli altri player di settore ha portato alla definizione del nuovo standard di autenticazione 3D Secure 2.

Il nuovo protocollo garantisce continuità come previsto dalle normative vigenti (Revised Payment Services Directive, conosciuta come PSD2), riduce l’impatto sui sistemi dei merchant e migliora l’esperienza d’acquisto che viene ottimizzata su tutti i dispositivi.

3DS2 e la Strong Customer Authentication (SCA)

EMV 3D Secure è il modo ottimale per essere conformi con la normativa PSD2 RTS.

Mentre con il 3D Secure 1.0 ogni transazione passava da un’autenticazione che richiedeva un’azione del buyer, l’applicazione del 3DS2 può esplicitarsi in due risultati: challenge flow o frictionless flow.

La PSD2 introduce l’obbligo per le banche europee di autenticare gli acquirenti all’interno dell’Area Economica Europea (EEA) in fase di acquisto online. Quando occorre un challenge flow, l’Issuer richiede una Strong Customer Authentication (SCA).

La SCA consiste in un’autenticazione con almeno due tra questi tre fattori:

Knowledge : qualcosa di conosciuto dal buyer (es. password, PIN)
Possession : qualcosa di posseduto dal buyer (es. smarpthone, Token OTC, dispositivo indossabile)
Inherence : qualcosa che contraddistingue il buyer (es. impronte digitali, riconoscimento facciale, riconoscimento vocale)

Un esempio di SCA è l’autenticazione fatta con una OTP (one-time-password) ricevuta dall’acquirente sul suo smartphone (fattore 1: possession) a una password statica (fattore 2: knowledge).

La PSD2 richiede quindi la strong customer authentication del buyer per acquisti da remoto ma sono previste alcune esenzioni.

Quando viene applicata un’esenzione, si parla di frictionless flow. Maggiori sono le informazioni comunicate all’Issuer, maggiore sarà la probabilità che la transazione rientri in un frictionless flow.

In questo scenario, l’autenticazione non richiede il coinvolgimento del buyer.

Nel caso delle carte non abilitate al 3DS2, il sistema richiede un’autenticazione secondo gli standard 3DS 1.0 e se questo tentativo dovesse fallire, la transazione eviterà la fase di autenticazione passando direttamente a quella di autorizzazione del pagamento.

Esenzioni ed eccezioni alla SCA

Per alcuni tipi di transazione l’applicazione della SCA può essere evitata; in questi casi si parla di eccezioni (out-of-scope) ed esenzioni.

Le eccezioni sono transazioni che non sono soggette alla normativa, infatti a questi pagamenti non vengono applicate le regole definite dalla PSD2.

Vengono considerate eccezioni:

one leg transactions : transazioni nelle quali acquirer o Issuer coinvolti non sono all’interno della EEA.
Merchant-initiated transactions (MIT): pagamenti inviati dall’esercente senza la presenza – remota, considerato che parliamo di pagamenti online – del buyer in quel momento
M.O.T.O (Mail Order Telephone Order): ordini di pagamento, effettuati dal buyer tramite telefono, email o posta, in cui il merchant inserisce manualmente i dati di carta forniti.
Carte anonime : pagamenti effettuati con carte identificabili solo dall’Issuer.

Queste transazioni possono essere processate senza autenticazione perché, come detto in precedenza, non sono soggette alla PSD2.

Le esenzioni si dividono in due categorie, a seconda che siano dell’Issuer o dell’Acquirer, e possono essere applicate dall’Issuer in questi casi:

Low value transactions: transazioni di valore pari o inferiore a 30 €
Transaction Risk Analysis : l’Issuer effettua un’analisi di rischio del pagamento basata sulle informazioni in suo possesso e, nel caso la transazione venga riconosciuta come sicura, può decidere di procedere con un frictionless flow (senza autenticazione).
White listing o trusted beneficiaries : se l’Issuer supporta questa funzione, permette al compratore di segnalare l’Ecommerce da cui sta comprando come facente parte di una whitelist di siti sui quali richiede che le transazioni non vengano autenticate, purché ci sia stata una SCA in precedenza.
Secure Corporate Payments : sono pagamenti iniziati da aziende che adottano processi dedicati e usano protocolli di sicurezza almeno equivalenti a quelli introdotti dalla SCA.

Le esenzioni degli Acquirer vengono richieste dal merchant dopo un accordo con l’Acquirer stesso.

Mentre le prime esenzioni descritte vengono applicate direttamente dall’Issuer, quelle dell’Acquirer sono richieste nel flusso di autenticazione e l’Issuer può decidere di non accettarle. Se un’esenzione dell’Acquirer viene accettata, la responsabilità di questo pagamento passa dall’Issuer all’Acquirer che ne risponderà in caso di frode.

Di seguito le esenzioni dell’Acquirer che possono essere richieste:

Low value transactions : transazioni di valore pari o inferiore a 30 €. Se vengono superate le soglie di attenzione, l’esenzione potrebbe essere rifiutata.
Transaction Risk Analysis : se il tasso di frodi dell’Acquirer rientra entro determinate soglie, è possibile richiedere l’esenzione a fronte di un’analisi del rischio effettuata dal merchant o da un provider specifico di sua scelta.
Recurring transactions : sono transazioni periodiche riconducibili allo stesso prodotto/servizio venduto e di stesso importo.

Transazioni e tipi di integrazione

Le tipologie di transazione descritte in questo capitolo fanno riferimento ad Fabrick Payment Orchestra [transDetails.type]:

Ecommerce : sono transazioni effettuate in "presenza" del compratore. È possibile salvare i dati della carta all’interno di un token (card on file) che verrà usato per le transazioni future. Sono soggette a SCA – escluse le transazioni che rientrano nelle eccezioni – e possono essere oggetto di esenzione.
M.O.T.O. : questa categoria include sia i pagamenti Mail Order sia i Telephone Order. Considerato che questi pagamenti sono eccezioni (out-of-scope), la strong customer authetication non viene applicata.
Recurring transactions : sono pagamenti ricorrenti per l’esecuzione dei quali viene stipulato un contratto tra merchant e titolare di carta durante la prima transazione della serie:
- Recurring First – è la prima transazione della serie e il titolare deve essere autenticato secondo i principi della SCA. In questa fase vengono anche definiti i giorni minimi tra un pagamento e l’altro e la scadenza dell’ultimo pagamento dovuto.
- Recurring Next – sono i pagamenti successivi. Sono dei pagamenti MIT e per questo non richiedono l’autenticazione.
MIT non programmate: ci sono casi in cui l’accordo tra il merchant e il suo cliente non definisce l’ammontare e le periodicità dei pagamenti ricorrenti, per esempio nei modelli di business pay-per-use, e questa tipologia di MIT permette all’esercente di richiedere pagamenti proprio in questo contesto.
- MIT non programmate First - nel corso della prima transazione l’acquirente deve essere autenticato con la SCA. La transazione deve essere autenticata ed autorizzata immediatamente per la somma dovuta.
- MIT non programmate Next – sono le transazioni che seguono la “First” e non richiedono l’autenticazione.
Authentication only : è l’operazione che viene effettuata per autenticare l’acquirente.

A seconda del tipo di interazione con il Payments Service Provider (PSP), possono essere effettuate queste operazioni:

Virtual POS : tutte le transazioni fatte in questo ambiente sono M.O.T.O.
Payment page : sono i pagamenti in cui è richiesta la presenza (si intende sempre da remoto) del buyer. Dalla payment page (pagina di pagamento) possono essere eseguite le transazioni: recurring first, unscheduled MIT first, Ecommerce e authentication only. Nel caso in cui nessun tipo di transazione venga specificato, il sistema assegna il valore Ecommerce di default.
Server to Server : questo tipo di integrazione permette qualsiasi tipo di transazione. Se non viene specificata la tipologia, il sistema assegna di default il valore configurato nel registro dell’esercente per lo shop login. Con l’integrazione server to server è inoltre possibile:
- Richiedere l’autenticazione per una transazione che verrà autorizzata più tardi da un altro PSP. In questo caso, il parametro transTypeReq deve essere settato su "A" e il messaggio di risposta conterrà l’informazione da usare per l’autorizzazione. Sarebbe anche possibile autorizzare la transazione attraverso Fabrick.
- Autorizzare un pagamento preventivamente autenticato da un provider di servizio 3D Secure threeDSAuthResult. In questo caso, la risposta raccolta dal provider deve essere inviata a Fabrick.

Fabrick gestisce ogni transazione secondo la configurazione e i parametri di transazione dell’esercente che deve esprimere una preferenza per ogni transazione in merito a:

Volontà di escludere ogni possibilità di esenzione ad una specifica transazione e di richiedere la SCA obbligatoria [esenzione = "SKIP"].

La richiesta di esenzione in base all’analisi del rischio della transazione effettuata da un soggetto terzo o proprietario [esenzione = "FORCE"].

È possibile trovare maggiori informazioni tecniche sull’integrazione in API documetation api link e nell’infografica dedicata external link .

Gestire transazioni 3D Secure

Eccezioni ed esenzioni