Pagamenti
Tokenizzazione dei pagamenti
La tokenizzazione dei pagamenti sostituisce i dettagli della carta con un token di riferimento in modo che un commerciante possa addebitare una credenziale memorizzata ripetutamente senza detenere il numero della carta stesso.
È ciò che rende possibile la fatturazione ricorrente senza che ogni commerciante diventi un caveau di carte nell'ambito PCI. Il token è privo di significato al di fuori del contesto che lo ha emesso, che è la proprietà di sicurezza.
La stessa proprietà è quella commerciale. Un token emesso da una piattaforma o un fornitore di app generalmente non può essere utilizzato da nessun altro, quindi chiunque lo detenga detiene la tua capacità di fatturare. Stabilisci la portabilità per iscritto prima di avere una base di abbonati abbastanza grande da renderla rilevante.
Cosa viene sostituito e cos'è realmente un token
La cosa sotto protezione è il numero di conto primario — il PAN, il numero lungo sulla parte anteriore della carta — insieme alla data di scadenza e, al momento dell'inserimento, il codice di sicurezza. Questi tre valori sono dati del titolare della carta, e detenerli è ciò che trascina un'attività nella fascia costosa del PCI DSS.
Un token sostituisce il PAN con un valore che non ha alcuna relazione matematica con esso. Questa è la distinzione dalla crittografia, e non è una distinzione pedante: il testo cifrato può essere invertito da chiunque ottenga la chiave, mentre un token può essere risolto solo dal caveau che detiene la mappatura. Rubare un database di token non produce nulla senza compromettere anche il caveau, che è un sistema separato sotto controllo separato.
I token si presentano in due forme e vengono costantemente confusi. I token che preservano il formato assomigliano a numeri di carta — stessa lunghezza, superano lo stesso checksum — in modo che possano viaggiare attraverso sistemi costruiti per trasportare un PAN. I token opachi sono identificatori arbitrari, le stringhe in stile `tok_` e `pm_` familiari dalle API moderne, e non possono mascherarsi da carta da nessuna parte.
La confusione più importante è tra monouso e multiuso. Il valore che un campo di pagamento lato client consegna al tuo server è solitamente un token monouso: esiste per trasportare un inserimento di carta dal browser al processore senza toccare la tua infrastruttura, e muore al primo utilizzo. Il valore che memorizzi per la fatturazione futura è un oggetto completamente diverso — un riferimento di caveau durevole, creato deliberatamente, che sopravvive per essere addebitato di nuovo. Trattare il primo come il secondo è il modo in cui i team scoprono al primo rinnovo di non aver mai salvato nulla.
Tre tipi di token, e non sono intercambiabili
Il termine copre diverse configurazioni che differiscono in chi detiene la mappatura, e questo singolo fatto determina tutto sulla portabilità, la resilienza e cosa succede quando la carta viene riemessa.
Un token di caveau di gateway o PSP è il caso comune e il più confinato: la mappatura risiede nel database di un unico fornitore e non significa nulla al di fuori di esso. Un fornitore di servizi di token indipendente ha la stessa forma con il caveau sotto un tetto diverso, scelto proprio in modo che il caveau non sia di proprietà della parte che potresti voler lasciare. Un token di rete, descritto nella sua voce, è emesso dal circuito della carta ed è l'unico dei tre che i circuiti stessi mantengono.
| Tipo | Chi detiene la mappatura | Sopravvive alla riemissione della carta | Utilizzabile da un altro processore |
|---|---|---|---|
| Token di checkout monouso | Il processore, brevemente | Non applicabile — scade all'uso | No |
| Token di caveau di gateway o PSP | Il fornitore di pagamenti | No, senza un aggiornatore di account | No — è richiesto un trasferimento del caveau |
| Fornitore di servizi di token indipendente | Un fornitore di caveau con cui stipuli un contratto direttamente | No, senza un aggiornatore di account | Sì — questo è il motivo per usarne uno |
| Token di rete | Il circuito della carta | Sì, automaticamente | Dipende dall'accordo con il richiedente del token |
Come riduce l'ambito PCI e dove l'ambito non scompare
L'ambito PCI DSS segue i dati del titolare della carta. I sistemi che memorizzano, elaborano o trasmettono un PAN rientrano nell'ambito; i sistemi che detengono solo token non lo sono, perché un token non è un dato del titolare della carta. La tokenizzazione è quindi una tecnica di riduzione dell'ambito prima di essere qualsiasi altra cosa.
La riduzione si materializza solo se il numero della carta non raggiunge mai realmente i tuoi server. Questo è ciò che i campi ospitati, un iframe dal processore, la tokenizzazione lato client e i reindirizzamenti completi esistono per ottenere. Un'integrazione che invia la carta al tuo backend e la tokenizza lì ha spostato l'archiviazione fuori dall'ambito lasciando l'elaborazione e la trasmissione saldamente al suo interno, il che è un risparmio molto minore di quanto suggerisca il diagramma di architettura.
Ciò che sopravvive è la pagina di pagamento stessa. Controlli ancora la pagina che carica il campo di pagamento, e uno script iniettato in quella pagina può leggere una carta prima che il processore la veda. PCI DSS v4 affronta questo direttamente con requisiti che coprono la gestione degli script sulle pagine di pagamento e il rilevamento di manomissioni su tali pagine — 6.4.3 e 11.6.1. Nessuno dei due è assolto dalla tokenizzazione.
Il riassunto onesto è che la tokenizzazione sposta un commerciante dal dimostrare la sicurezza di un caveau di carte al dimostrare l'integrità di una pagina di checkout. Questo è uno scambio molto migliore, e non è lo stesso che non avere obblighi.
La trappola della portabilità: un token di gateway non si sposta
La proprietà che rende un token sicuro è che è privo di significato al di fuori del contesto che lo ha emesso. Questa proprietà non distingue tra un attaccante e il tuo prossimo fornitore di pagamenti.
La migrazione di un registro di credenziali memorizzate richiede quindi un trasferimento da caveau a caveau: il fornitore uscente esporta i dati della carta in condizioni conformi al PCI al fornitore ricevente, che li tokenizza nuovamente. Questa è una procedura ben consolidata, entrambe le parti possono farlo, e richiede la cooperazione di un'azienda il cui interesse commerciale è servito dal fatto che il trasferimento non avvenga. L'alternativa è chiedere a ogni abbonato attivo di reinserire una carta, e una parte significativa di essi semplicemente non lo farà — questo non è un abbandono che recuperi, è un abbandono che hai causato.
La clausola da assicurare è il diritto di esportare le credenziali memorizzate a un fornitore alternativo nominato, su richiesta, entro un periodo stabilito, a un costo stabilito. Non costa nulla negoziare prima di avere una base di abbonati ed è quasi impossibile da ottenere una volta che la base esiste.
Memorizzare una credenziale in un caveau per la fatturazione ricorrente
Un token da solo non è sufficiente per addebitare nuovamente un cliente. Ciò che rende valido un addebito successivo è il registro del consenso che lo accompagna, e quel registro ha diverse parti che una migrazione ingenua lascia indietro.
La credenziale memorizzata necessita del mandato: a cosa il cliente ha acconsentito, quando ha acconsentito, la versione dei termini che ha accettato, e la frequenza e l'importo a cui ha acconsentito. Necessita del tipo di transazione — ricorrente, a rate o non programmata — perché i circuiti li trattano in modo diverso. E necessita dell'identificatore di transazione di rete restituito dall'autorizzazione originale avviata dal cliente, che gli addebiti successivi avviati dal commerciante devono referenziare per essere riconosciuti come continuazioni autorizzate piuttosto che come addebiti non collegati a una carta.
Quell'ultimo campo è quello che va perso. Una migrazione che sposta i token ma non gli identificatori di transazione di rete originali impedisce al processore ricevente di presentare i rinnovi come transazioni valide avviate dal commerciante, e il risultato è un tasso di autorizzazione che cala nel primo ciclo di fatturazione dopo il trasferimento per ragioni che nessuno nel piano di progetto aveva previsto.
Oltre alla credenziale stessa, vale la pena conservare ciò che ti è permesso mantenere per la visualizzazione e per la previsione: il brand della carta, le ultime quattro cifre e la data di scadenza. Questi sono gli elementi che permettono a un cliente di riconoscere quale carta è registrata, e che ti permettono di identificare le credenziali che scadranno prima del prossimo rinnovo e di contattare quei clienti prima che l'addebito fallisca.
Domande frequenti
- Cos'è la tokenizzazione dei pagamenti?
- La tokenizzazione dei pagamenti sostituisce un numero di carta con un valore sostitutivo, un token, che non ha alcuna relazione matematica con la carta. Un vault contiene la mappatura tra i due. Il commerciante memorizza solo il token e lo presenta per addebitare nuovamente il cliente, così i dati della carta non risiedono mai nei sistemi del commerciante mentre la fatturazione ricorrente continua a funzionare.
- Qual è la differenza tra tokenizzazione e crittografia?
- La crittografia trasforma un numero di carta in un testo cifrato che chiunque detenga la chiave può invertire, quindi la protezione viaggia con i dati e dipende dalla gestione delle chiavi. La tokenizzazione sostituisce un valore non correlato e mantiene la mappatura in un vault separato, quindi un database di token rubato non produce nulla di per sé. La crittografia protegge i dati in transito; la tokenizzazione li rimuove completamente dai tuoi sistemi.
- La tokenizzazione dei pagamenti riduce l'ambito PCI?
- Sì, se il numero della carta non raggiunge mai i tuoi server. I sistemi che contengono solo token sono fuori ambito perché i token non sono dati del titolare della carta, motivo per cui esistono i campi ospitati (hosted fields), gli iframe e la tokenizzazione lato client. L'ambito non scompare: la pagina di pagamento rimane tua, e i requisiti PCI DSS v4 6.4.3 e 11.6.1 coprono la gestione degli script e il rilevamento di manomissioni su quella pagina.
- I token di pagamento possono essere spostati a un altro provider?
- Non direttamente. Un token di gateway è privo di significato al di fuori del vault che lo ha emesso, quindi la migrazione richiede un trasferimento da vault a vault in cui il provider attuale esporta i dati della carta sottostanti al nuovo provider in condizioni conformi al PCI. Entrambe le parti possono farlo, ma il provider uscente non ha alcun incentivo commerciale, quindi il diritto di esportazione deve essere incluso nel contratto prima della firma.
- La tokenizzazione dei pagamenti è la stessa cosa di un token di rete?
- Un token di rete è un tipo di token di pagamento, emesso da Visa, Mastercard o American Express anziché da un provider di pagamenti. È l'unico tipo che rimane valido quando la carta viene riemessa e l'unico tipo con una qualsiasi via verso un altro processore. Un token di vault di gateway è il tipo più comune e non possiede nessuna delle due proprietà.
- Cos'altro, oltre al token, ti serve per fatturare un abbonamento?
- Hai bisogno del record di consenso: a cosa ha acconsentito il cliente, quando, la versione dei termini accettati, il tipo di transazione e l'identificatore di transazione di rete restituito dall'autorizzazione originale avviata dal cliente. Gli addebiti successivi avviati dal commerciante fanno riferimento a quell'identificatore per essere riconosciuti come continuazioni autorizzate. La migrazione dei token senza di esso di solito fa calare i tassi di autorizzazione nel primo ciclo dopo il trasferimento.