La strong customer authentication pci DSS e la PSD2 sono tre normative distinte che si sovrappongono nei pagamenti online europei. Confonderle porta a lacune di compliance: chi implementa solo la SCA (Strong Customer Authentication) della PSD2 crede di essere a posto, ma ignora i requisiti PCI DSS sulla protezione dei dati carta. Questo articolo chiarisce le differenze, le sovrapposizioni e come 3DS2 si colloca in questo quadro.
SCA, PSD2 e PCI DSS: tre normative, un unico obiettivo
La PSD2 (Payment Services Directive 2) e un regolamento europeo che impone ai prestatori di servizi di pagamento di applicare la SCA per le transazioni online nell'Area Economica Europea. La SCA richiede almeno due dei tre fattori di autenticazione: qualcosa che il titolare conosce (PIN, password), qualcosa che possiede (smartphone, token fisico) e qualcosa che caratterizza biometricamente l'utente (impronta digitale, riconoscimento facciale). Il suo scopo e ridurre le frodi sui pagamenti online.
Il PCI DSS, invece, e uno standard tecnico definito dal PCI SSC che regola la protezione dei dati carta lungo tutto il ciclo di vita della transazione: raccolta, trasmissione, elaborazione e conservazione. Non si occupa di autenticazione del titolare, ma di come il dato carta viene gestito dai sistemi del merchant, del processore e dell'acquirer. I due framework hanno obiettivi complementari ma non si sostituiscono a vicenda: rispettare la SCA non significa essere PCI compliant e viceversa.
3DS2 e PCI DSS: come si integrano tecnicamente
Il protocollo 3DS2 (3-D Secure version 2) e il meccanismo tecnico con cui la SCA viene implementata per i pagamenti card-not-present. Durante il flusso 3DS2, dati aggiuntivi sulla transazione (indirizzo IP, device fingerprint, storico del titolare) vengono trasmessi all'ACS (Access Control Server) dell'emittente per una valutazione del rischio. Se il rischio e basso, la transazione procede senza interazione del titolare (frictionless flow); altrimenti viene richiesto un secondo fattore (challenge flow).
Dal punto di vista PCI DSS, il flusso 3DS2 non riduce il perimetro del merchant: il PAN viene comunque trattato durante la tokenizzazione iniziale e deve essere protetto secondo i requisiti dello standard. Tuttavia, combinare 3DS2 con la tokenizzazione di PCI Proxy EU permette di ottimizzare entrambi: il token viene usato nelle charge ricorrenti senza richiedere nuovamente la SCA (grazie alle esenzioni per le transazioni merchant-initiated), e il PAN non transita mai nei sistemi del merchant.
Esenzioni SCA e impatto sul perimetro PCI
La PSD2 prevede diverse esenzioni alla SCA che i merchant possono richiedere all'emittente. Le principali sono: transazioni di importo inferiore a 30 euro (low value transactions), transazioni con basso tasso di frode (transaction risk analysis), transazioni ricorrenti di importo fisso (merchant-initiated transactions) e pagamenti effettuati da mittenti trusted. L'utilizzo delle esenzioni deve essere concordato con il PSP (Payment Service Provider) e l'acquirer.
Le esenzioni SCA per le transazioni merchant-initiated hanno un impatto diretto sulla gestione del perimetro PCI nei pagamenti ricorrenti. Quando il merchant avvia un addebito su un token precedentemente autorizzato dal titolare, non serve una nuova SCA, ma serve che il token sia valido e che la prima autorizzazione abbia incluso il consenso per le charge future. PCI Proxy EU supporta questo flusso nativamente, permettendo di gestire le sottoscrizioni e gli abbonamenti in conformita sia con la SCA che con il PCI DSS.
Domande frequenti
Se implemento 3DS2 sono conforme al PCI DSS?
No. Il 3DS2 risponde ai requisiti SCA della PSD2, non ai requisiti PCI DSS. Sono due framework separati. Il PCI DSS richiede la protezione del dato carta (PAN, CVV, dati della banda magnetica) lungo tutto il ciclo di vita, indipendentemente dal protocollo di autenticazione usato. Un merchant puo implementare 3DS2 in modo corretto e allo stesso tempo avere gravi lacune PCI, ad esempio conservando i PAN in chiaro nel database.
Le esenzioni SCA aumentano il rischio di frode?
Le esenzioni SCA sono progettate per ridurre l'attrito sulle transazioni a basso rischio, non per abbassare la sicurezza complessiva. La responsabilita del chargeback in caso di frode si sposta sull'emittente quando questi approva l'esenzione. Per il merchant, il rischio principale e applicare esenzioni su transazioni ad alto rischio: e necessario monitorare i tassi di frode e calibrare la strategia di esenzione con il PSP.
PCI Proxy EU e compatibile con il flusso 3DS2?
PCI Proxy EU supporta il flusso 3DS2 sia in modalita frictionless che challenge. Il token generato al momento della prima transazione include le informazioni necessarie per le successive charge merchant-initiated senza richiedere nuova SCA. Il servizio e compatibile con i principali processori europei che supportano 3DS2 e con le API degli emittenti che gestiscono l'ACS.
Vuoi gestire SCA e PCI DSS con un'unica integrazione? Scopri come PCI Proxy EU supporta il flusso 3DS2 e la tokenizzazione. Scopri PCI Proxy EU.