Chiunque gestisca subscription billing o pagamenti ricorrenti con carta è automaticamente in scope per il PCI DSS. Il motivo è strutturale: per addebitare una carta in assenza del titolare (pagamento recurring), il merchant deve conservare un riferimento ai dati carta che permetta l'autorizzazione futura. Questo riferimento, che sia un PAN in chiaro o un token, determina il perimetro di compliance. La card-on-file tokenization è la risposta tecnica che permette di gestire abbonamenti scalabili senza costruire un vault proprietario.
Abbonamenti e PCI DSS: perché sei automaticamente in scope
Un abbonamento richiede che il merchant conservi un riferimento alla carta del cliente per addebitarla periodicamente senza una nuova autorizzazione esplicita del titolare. Questo è definito dal PCI DSS come scenario card-on-file: la carta è "in archivio" presso il merchant. Se il merchant conserva il PAN direttamente, tutti i sistemi che accedono a quell'archivio sono in scope. Se il merchant conserva il token di un vault certificato, lo scope si riduce ai componenti che inviano il token al vault per ottenere l'autorizzazione.
Un errore frequente è pensare che usare un PSP per i pagamenti ricorrenti elimini gli obblighi PCI. Se il PSP conserva la carta e il merchant usa i propri token interni per richiamare i pagamenti, il merchant è ancora in scope per la gestione di quei token e per il flusso che li invia al PSP. La riduzione effettiva dello scope dipende da come è strutturata l'integrazione tecnica e da quali dati transitano effettivamente nell'infrastruttura del merchant.
Card-on-file tokenization per il subscription billing
Con la card-on-file tokenization di PCI Proxy EU, il flusso per gli abbonamenti funziona in questo modo: al momento della prima registrazione, il cliente inserisce i dati carta nella payment page ospitata da PCI Proxy EU. Il sistema restituisce al merchant un token persistente legato a quella carta. Il merchant archivia il token nel proprio database insieme al profilo del cliente e al piano di abbonamento. Nelle scadenze successive, il merchant invia il token a PCI Proxy EU che recupera il PAN e lo trasmette al PSP per l'autorizzazione.
Questo approccio permette al merchant di gestire la logica di billing (calcolo degli importi, gestione dei periodi, notifiche di scadenza, retry in caso di fallimento) nei propri sistemi senza mai toccare il PAN. Il database del merchant contiene solo token, identificatori di cliente e dati del piano: nessuno di questi elementi costituisce un dato sensibile PCI. La flessibilità nella logica di billing rimane piena perché il token è persistente e può essere riutilizzato per un numero illimitato di autorizzazioni successive.
Cosa rimane a carico del merchant anche con la tokenizzazione
La tokenizzazione non azzera tutti gli obblighi PCI del merchant. I componenti che inviano il token a PCI Proxy EU per l'autorizzazione (server applicativo, job scheduler, sistema di billing) rimangono in scope per la parte connessa all'API del vault. Questi sistemi devono avere controlli di accesso appropriati, log degli accessi alle API, gestione sicura delle credenziali API e procedure documentate per la rotazione delle chiavi di autenticazione. Il SAQ applicabile in questo scenario è tipicamente il SAQ D for Merchants, ma con un numero di sistemi in scope molto ridotto rispetto a un'architettura senza tokenizzazione.
Anche la gestione delle carte scadute richiede un processo definito: quando una carta scade, il merchant deve avere un flusso per aggiornare il token con la nuova carta del cliente (via redirect a una nuova payment page) o per attivare la cancellazione dell'abbonamento. PCI Proxy EU supporta aggiornamenti automatici delle carte per i circuiti che li mettono a disposizione, riducendo il churn involontario senza richiedere al cliente di reinserire manualmente i dati.
Domande frequenti
Posso usare il token PCI Proxy EU per riprocessare un abbonamento scaduto?
Sì, il token è persistente e può essere usato per tentativi successivi di addebito finché la carta sottostante è valida nel vault. Se un addebito fallisce per carta scaduta, il token diventa inutilizzabile per nuove autorizzazioni. Il merchant deve attivare un flusso di aggiornamento carta: PCI Proxy EU supporta l'Account Updater per i circuiti che lo permettono, oppure il merchant può inviare al cliente un link per aggiornare manualmente i dati.
Come gestisco l'aggiornamento dei dati carta in un abbonamento?
Il flusso standard prevede l'invio di una notifica al cliente con un link alla payment page di PCI Proxy EU per inserire i nuovi dati carta. Una volta completato, il sistema emette un nuovo token che il merchant associa al profilo cliente esistente. Il vecchio token viene invalidato. Questo processo non richiede alcuna modifica alla logica di billing del merchant: solo l'ID del token nel database viene aggiornato.
Il mandato SEPA elimina gli obblighi PCI DSS?
Sì, ma solo se i pagamenti ricorrenti vengono gestiti esclusivamente tramite addebito diretto SEPA (SDD). Il mandato SEPA non usa dati carta ma IBAN, che non rientra nel perimetro PCI DSS. Se però l'azienda accetta sia SEPA che carta di credito per gli abbonamenti, i pagamenti con carta rimangono in scope PCI. Molte aziende usano i due strumenti in parallelo, per cui il SEPA non elimina gli obblighi PCI ma può ridurre il volume di transazioni carta in scope.
Abbonamenti senza PAN nel tuo stack: gestisci la logica di billing, noi custodiamo i dati carta. Scopri PCI Proxy EU.