Ridurre lo scope PCI DSS nell’ecommerce: hosted fields e tokenizzazione

Lo scope si riduce con l’architettura, non con un badge

Hosted fields e tokenizzazione possono ridurre il perimetro PCI DSS di un ecommerce quando i dati carta grezzi vengono raccolti e trattati dal provider, senza attraversare server, API o database del merchant. Un vero hosted field è un campo o frame isolato erogato dal provider, non un input del merchant che invia il PAN al proprio backend. Non eliminano però lo scope e non certificano l’integrazione. Il merchant continua a gestire pagina di checkout, codice, configurazioni, accessi, ordini, integrazioni e rapporto con i fornitori. La domanda corretta non è quindi «il provider è conforme?», ma «quali persone, processi e tecnologie possono influire sul pagamento o incontrare dati di account?».

Mappare dati, confini e copie prima dell’integrazione

Seguire il dato primario e i sistemi secondari

Disegna il percorso dal browser al provider e dal provider ai servizi merchant. Per ogni passaggio registra origine del codice, dominio di destinazione, payload, identificatore restituito, cifratura, retention e proprietario. Includi frontend, backend, code, webhook, strumenti antifrode e assistenza. Marca separatamente PAN, data di scadenza, nome titolare, codici di sicurezza e token: non sono equivalenti e non devono essere trattati con una generica etichetta «dati pagamento».

Estendi l’inventario a log applicativi, APM, session replay, analytics, crash report, data lake, ticket, email e backup. Un errore che serializza il body della richiesta o uno strumento che registra il DOM può creare una copia inattesa anche se il database principale è pulito. Cerca inoltre export manuali, screenshot e variabili di debug. Per ciascun sistema definisci una prova negativa: configurazione di redazione, campione di log, query di ricerca e responsabile della verifica.

Confrontare i modelli di checkout senza confonderli

Controllo dell’esperienza e superficie tecnica

Un redirect o checkout interamente ospitato sposta il cliente su una pagina del provider e tende a creare il confine più netto. Un checkout ospitato ma incorporato mantiene parte dell’esperienza nel sito. Gli hosted fields inseriscono nella pagina merchant singoli campi o componenti isolati, offrendo più controllo sul layout ma lasciando al merchant la sicurezza della pagina che li contiene. La raccolta raw, infine, fa transitare i dati carta nell’applicazione merchant e amplia fortemente sistemi, persone e controlli coinvolti.

Non dedurre automaticamente SAQ A dal nome del prodotto. Dal 1 aprile 2025 il criterio rivisto richiamato dal PCI SSC distingue le pagine con moduli di pagamento incorporati, per le quali il merchant deve confermare la protezione dagli attacchi via script, dai casi di redirect o pagamento completamente esternalizzato ai quali quel criterio specifico non si applica. È una distinzione di eleggibilità, non una garanzia generale.

Progettare il flusso browser, provider e token

Il dato sensibile non deve raggiungere il server merchant

Il backend crea una sessione di pagamento con importo e valuta derivati dall’ordine e restituisce al browser soltanto dati di inizializzazione limitati. Il browser carica il componente dal dominio e dalla libreria ufficiale del provider. Il cliente inserisce i dati negli hosted fields; il componente li invia direttamente al provider, che restituisce un token, un identificatore del metodo o un riferimento di sessione. Il browser passa al backend questo riferimento, non il PAN né il codice di sicurezza.

Le implementazioni concrete differiscono. Stripe documenta che Elements tokenizza i dati sensibili all’interno del componente senza farli arrivare al server del merchant. Adyen descrive flussi client-side e una vault in cui il token rappresenta i dettagli di pagamento conservati dal provider. Sono esempi specifici, non una semantica universale: formato, durata, riutilizzabilità, ambito per merchant e permessi del token devono essere letti nel contratto dell’integrazione scelta.

Mantenere il server autorevole su ordine ed esito

Tokenizzare la carta non protegge la logica commerciale

Il client non deve decidere prezzo, sconto, valuta, spedizione o quantità. Prima di inizializzare il pagamento, il server rilegge catalogo e carrello da fonti fidate, applica le regole e calcola il totale. Memorizza ordine, versione del calcolo, importo atteso, valuta e identificatore del provider. Se il browser invia un importo, trattalo come indicazione non affidabile e non come fonte contabile.

Dopo il pagamento, non evadere l’ordine sulla sola pagina di ritorno. Verifica lo stato tramite API o notifica server-to-server autenticata secondo il provider, confronta ordine, importo e valuta e rendi idempotente la transizione a pagato. Gestisci callback duplicate, fuori ordine o in ritardo. Un token valido prova soltanto che esiste un riferimento utilizzabile nel suo contesto; non prova che l’ordine sia corretto o che il pagamento sia definitivo.

Tenere PAN e dati di autenticazione fuori dai sistemi secondari

Definisci una regola esplicita: backend, database, log, analytics, APM, ticket, email e backup non devono ricevere PAN completo o dati di autenticazione sensibili. Evita di copiare il DOM dei campi, inviare errori completi a strumenti terzi o aggiungere proprietà di pagamento a eventi analytics. Nelle interfacce operative mostra solo attributi consentiti e necessari, come brand dichiarato dal provider, ultime cifre quando appropriate e riferimento di transazione.

Il token riduce l’esposizione perché sostituisce un valore sensibile nel flusso applicativo, ma non è anonimo né universalmente innocuo. Può essere collegabile a cliente, ordine o metodo di pagamento e può autorizzare operazioni entro determinati permessi. Proteggilo con controllo accessi, segregazione per ambiente, cifratura dove richiesta, retention limitata e log privi di segreti. Non trasformarlo in un identificatore pubblico prevedibile.

Controllare script e responsabilità condivise

La pagina che ospita i campi resta una superficie del merchant

Un componente isolato può impedire al codice merchant di leggere direttamente il contenuto del campo, ma script malevoli possono alterare la pagina, sostituire il componente o deviare il cliente. Mantieni inventario e approvazione degli script, dipendenze aggiornate, cambi controllati e monitoraggio dell’integrità. Per nonce, direttive e rollout progressivo, usa il nostro approfondimento sulla Content Security Policy nel checkout ecommerce senza duplicare qui l’intera configurazione.

Raccogli il contratto di responsabilità: integrazione approvata, istruzioni applicate, attestazione del provider quando richiesta, domini e versioni autorizzati, matrice dei flussi, revisioni degli accessi, evidenze sui log e risultati dei test. L’esternalizzazione trasferisce alcune funzioni, non la responsabilità ultima del merchant. Riesamina documentazione e stato del fornitore, assegna proprietari interni e conserva le prove con data e versione.

Testare manomissioni, errori e perdite

In ambiente di test prova modifica di importo e valuta, token di un altro ordine, riuso del riferimento, callback senza firma, webhook duplicato e ritorno browser falsificato. Interrompi la rete durante tokenizzazione e conferma, simula timeout e ricaricamenti, verifica che nessun retry crei due ordini o due evasioni. Controlla che un componente non caricato blocchi il pagamento in modo comprensibile e che il fallback non attivi campi raw.

Esegui poi test di perdita: cerca pattern di carte di test nei log, nei dump APM, negli eventi analytics, nelle code, nei ticket e nei backup creati durante il percorso. Verifica redazione di errori e payload, accessi ai token e separazione tra test e produzione. Ogni esito deve produrre una prova archiviabile, una persona responsabile e un’azione di correzione, non soltanto uno screenshot di successo.

Misurare il confine e mantenere un runbook

Monitora quota di pagamenti che usano il flusso approvato, errori di caricamento dei componenti, tokenizzazioni fallite, mismatch di importo o valuta, callback rifiutate, duplicati, ordini sospesi e rilevazioni di dati sensibili nei sistemi secondari. Aggiungi età dell’attestazione del provider, dipendenze di checkout non revisionate e tempo di chiusura delle eccezioni. Le soglie vanno costruite sulla baseline interna, non su benchmark universali.

Il runbook deve indicare come disabilitare il checkout, ripristinare una versione nota, ruotare credenziali, isolare log sospetti, sospendere l’evasione e contattare provider, acquirer e responsabili interni. Per progettare una separazione verificabile tra browser, provider e sistemi ordine, scopri i nostri servizi per ecommerce e sistemi. Se vuoi validare flussi, prove e responsabilità prima del rilascio, contatta AE Digital Agency: la decisione su SAQ e conformità resta comunque dell’acquirer o del QSA competente.