L'ecommerce pci compliance è uno degli ambiti in cui i merchant commettono più errori di valutazione. Molti credono che usare Stripe, PayPal o un gateway di pagamento noto li esima automaticamente da ogni obbligo PCI DSS. La realtà è più sfumata: il tipo di integrazione scelto determina quale SAQ si applica e quanti controlli rimangono a carico del merchant. Capire questa distinzione permette di ridurre al minimo il perimetro di compliance scegliendo l'architettura giusta fin dall'inizio.
Checkout ecommerce e PCI DSS: cosa scatta quando accetti carte
Qualsiasi negozio online che accetti pagamenti con carta attiva gli obblighi PCI DSS per il merchant. La domanda non è se gli obblighi si applicano, ma quali e in che misura. Tutto dipende da come i dati carta fluiscono durante il checkout. Se il browser del cliente invia i dati carta direttamente ai server del merchant (anche solo per un istante), il merchant è soggetto agli obblighi più estesi del SAQ D, con oltre 200 controlli da soddisfare. Se invece i dati carta non toccano mai i server del merchant perché il form di pagamento è ospitato dal provider, il merchant può qualificarsi per il SAQ A, molto più semplice.
Esiste una via di mezzo rappresentata dall'approccio SAQ A-EP: il merchant usa JavaScript del provider per raccogliere i dati carta direttamente nel browser del cliente, senza che i dati transitino per i server del merchant. Questo riduce il scope rispetto al SAQ D ma richiede comunque più controlli del SAQ A, inclusa la gestione della sicurezza del server web e del codice JavaScript delle pagine di checkout. Con il PCI DSS v4, il requisito sugli script delle pagine di pagamento ha ulteriormente complicato la posizione dei merchant SAQ A-EP.
Le opzioni di integrazione e il loro impatto sul SAQ
Le principali opzioni di integrazione per un ecommerce sono tre, ordinate dalla più onerosa alla meno onerosa in termini di PCI DSS. La prima è il checkout nativo: il merchant sviluppa e gestisce internamente il form di inserimento dei dati carta. Questo comporta il SAQ D con il perimetro di compliance più ampio. La seconda opzione sono i hosted fields o JavaScript injection: il provider inietta campi di input nella pagina del merchant che raccolgono i dati carta direttamente nel browser e li inviano al provider. Questo porta al SAQ A-EP con scope intermedio. La terza e meno onerosa opzione è il redirect verso una hosted payment page: l'utente lascia il sito del merchant per completare il pagamento su una pagina ospitata dal provider, per poi tornare dopo la conferma. Questa architettura permette il SAQ A.
La tokenizzazione aggiunge un livello ulteriore di protezione in qualsiasi scenario. Quando un provider di tokenizzazione certificato intercetta il PAN prima che raggiunga i sistemi del merchant e restituisce un token non reversibile, il merchant non detiene mai dati carta sensibili. Il token può essere memorizzato liberamente per usi futuri (rinnovi di abbonamento, ordini ricorrenti) senza che questo comporti obblighi aggiuntivi di sicurezza relativi ai dati carta, perché il token non ha valore al di fuori del sistema del provider che lo gestisce.
Come PCI Proxy EU elimina il scope PCI dal tuo ecommerce
Con PCI Proxy EU, il checkout del merchant non vede mai i dati carta. Il form di pagamento è gestito dall'infrastruttura certificata PCI DSS Level 1 di PCI Proxy EU, che intercetta il PAN e restituisce al merchant un token prima che qualsiasi dato sensibile raggiunga i server del negozio online. Questo porta il merchant direttamente al SAQ A, eliminando la necessità di vulnerability scanning trimestrale dei server, penetration test estesi, gestione di certificati e policy di controllo accessi specifiche per il CDE.
Il vantaggio operativo è significativo anche per i negozi che gestiscono ordini ricorrenti o abbonamenti. Il token memorizzato dal merchant può essere usato per addebitare le carte future senza che il merchant conosca mai il PAN originale. Questo scenario, prima complesso da gestire in conformità PCI DSS, diventa lineare con un provider di tokenizzazione: il merchant chiede al provider di processare un addebito usando il token, e il provider usa il PAN che custodisce nel proprio vault certificato. Il merchant non vede mai il dato sensibile e mantiene il perimetro SAQ A in tutte le fasi del ciclo di vita del cliente.
Domande frequenti
Se uso Stripe o PayPal sono già conformi al PCI DSS?
Dipende dall'integrazione. Se usi il redirect verso la checkout page di Stripe o PayPal, il tuo scope è ridotto al SAQ A. Se usi le API o i loro elementi JavaScript con form ospitati sul tuo dominio, il tuo scope è SAQ A-EP. Se hai integrato direttamente le API passando i dati carta attraverso il tuo server, sei in SAQ D. Usare un gateway noto non equivale automaticamente a essere conformi: conta l'architettura dell'integrazione.
Un iframe di pagamento ospitato riduce il mio scope?
Sì, se l'iframe è caricato da un dominio del provider e i dati carta non transitano per i server del merchant. In questo caso la qualificazione tipica è SAQ A. Attenzione però: se il merchant ha JavaScript custom che gira nella stessa pagina dell'iframe e potrebbe teoricamente accedere ai dati, il PCI Council potrebbe ritenere che il merchant debba compilare il SAQ A-EP invece del SAQ A. Verifica sempre con il tuo acquirer la classificazione corretta.
Ho un negozio WooCommerce: cosa devo fare?
WooCommerce di per sé non determina il tuo scope PCI: conta quale gateway di pagamento usi e come lo hai integrato. Se usi il redirect verso una hosted payment page del tuo provider, puoi compilare il SAQ A. Se usi plugin che raccolgono dati carta direttamente nel checkout di WooCommerce e li passano via API, il tuo scope è più ampio. Verifica la documentazione del tuo plugin di pagamento e, se necessario, passa a una soluzione con hosted form.
Zero dati carta nel tuo ecommerce significa SAQ A, compliance semplificata e clienti più al sicuro. Scopri PCI Proxy EU.