Tokenização de pagamentos

O que está sendo substituído e o que um token realmente é

O que está sob proteção é o número da conta principal — o PAN, o número longo na frente do cartão — juntamente com a data de validade e, no momento da entrada, o código de segurança. Esses três valores são dados do titular do cartão, e mantê-los é o que arrasta um negócio para o lado caro do PCI DSS.

Um token substitui o PAN por um valor que não tem relação matemática com ele. Essa é a distinção da criptografia, e não é pedante: um texto cifrado pode ser revertido por qualquer pessoa que obtenha a chave, enquanto um token só pode ser resolvido pelo cofre que detém o mapeamento. Roubar um banco de dados de tokens não rende nada sem também comprometer o cofre, que é um sistema separado sob controle separado.

Tokens vêm em dois formatos e são constantemente confundidos. Tokens que preservam o formato parecem números de cartão — mesmo comprimento, passando o mesmo checksum — para que possam viajar por sistemas construídos para transportar um PAN. Tokens opacos são identificadores arbitrários, as strings no estilo `tok_`- e `pm_`- familiares de APIs modernas, e não podem se passar por um cartão em lugar nenhum.

A confusão mais importante é entre uso único e multiuso. O valor que um campo de pagamento do lado do cliente entrega ao seu servidor é geralmente um token de uso único: ele existe para transportar uma entrada de cartão do navegador para o processador sem tocar em sua infraestrutura, e ele morre no primeiro uso. O valor que você armazena para futuras cobranças é um objeto totalmente diferente — uma referência de cofre durável, criada deliberadamente, que sobrevive para ser cobrada novamente. Tratar o primeiro como o segundo é como as equipes descobrem na primeira renovação que nunca salvaram nada.

Três tipos de token, e eles não são intercambiáveis

A palavra abrange vários arranjos que diferem em quem detém o mapeamento, e esse único fato determina tudo sobre portabilidade, resiliência e o que acontece quando o cartão é reemitido.

Um token de cofre de gateway ou PSP é o caso comum e o mais confinado: o mapeamento reside no banco de dados de um provedor e não significa nada fora dele. Um provedor de serviço de token independente tem o mesmo formato com o cofre sob um teto diferente, escolhido precisamente para que o cofre não seja de propriedade da parte que você talvez queira deixar. Um token de rede, descrito em sua própria entrada, é emitido pela rede de cartões e é o único dos três que as próprias redes mantêm.

Como ele reduz o escopo do PCI, e onde o escopo não desaparece

O escopo do PCI DSS segue os dados do titular do cartão. Sistemas que armazenam, processam ou transmitem um PAN estão no escopo; sistemas que apenas detêm tokens não estão, porque um token não é dado do titular do cartão. A tokenização é, portanto, uma técnica de redução de escopo antes de ser qualquer outra coisa.

A redução só se materializa se o número do cartão realmente nunca chegar aos seus servidores. É para isso que existem campos hospedados, um iframe do processador, tokenização do lado do cliente e redirecionamentos completos. Uma integração que envia o cartão para o seu backend e o tokeniza lá moveu o armazenamento para fora do escopo, mas deixou o processamento e a transmissão firmemente dentro dele, o que é uma economia muito menor do que o diagrama de arquitetura sugere.

O que sobrevive é a própria página de pagamento. Você ainda controla a página que carrega o campo de pagamento, e um script injetado nessa página pode ler um cartão antes que o processador o veja. O PCI DSS v4 aborda isso diretamente com requisitos que cobrem o gerenciamento de scripts em páginas de pagamento e a detecção de adulteração nessas páginas — 6.4.3 e 11.6.1. Nenhum deles é dispensado pela tokenização.

O resumo honesto é que a tokenização move um comerciante de provar a segurança de um cofre de cartões para provar a integridade de uma página de checkout. Essa é uma troca muito melhor, e não é o mesmo que não ter obrigações.

A armadilha da portabilidade: um token de gateway não se move

A propriedade que torna um token seguro é que ele não tem significado fora do contexto que o emitiu. Essa propriedade não distingue entre um atacante e seu próximo provedor de pagamentos.

Migrar um livro de credenciais armazenadas, portanto, requer uma transferência de cofre para cofre: o provedor que perde exporta os dados do cartão sob condições compatíveis com PCI para o provedor que ganha, que os tokeniza novamente. Este é um procedimento bem estabelecido, ambas as partes podem fazê-lo, e requer a cooperação de uma empresa cujo interesse comercial é servido pela não ocorrência da transferência. A alternativa é pedir a cada assinante ativo para reinserir um cartão, e uma parcela significativa deles simplesmente não o fará — isso não é churn que você recupera, é churn que você causou.

A cláusula a ser garantida é o direito de exportar credenciais armazenadas para um provedor alternativo nomeado, mediante solicitação, dentro de um período declarado, a um custo declarado. Não custa nada negociar antes de ter uma base de assinantes e é quase impossível de obter uma vez que a base existe.

Armazenando uma credencial para cobrança recorrente

Um token sozinho não é suficiente para cobrar um cliente novamente. O que torna uma cobrança posterior válida é o registro de consentimento que o acompanha, e esse registro tem várias partes que uma migração ingênua deixa para trás.

A credencial armazenada precisa do mandato: o que o cliente concordou, quando concordou, a versão dos termos que aceitou, e a cadência e o valor aos quais consentiu. Precisa do tipo de transação — recorrente, parcelada ou não programada — porque as redes as tratam de forma diferente. E precisa do identificador de transação de rede retornado pela autorização original iniciada pelo cliente, que as cobranças subsequentes iniciadas pelo comerciante devem referenciar para serem reconhecidas como continuações autorizadas, em vez de cobranças não vinculadas a um cartão.

Esse último campo é o que se perde. Uma migração que move tokens, mas não os identificadores originais de transação da rede, deixa o processador receptor incapaz de apresentar renovações como transações válidas iniciadas pelo comerciante, e o resultado é uma taxa de autorização que cai no primeiro ciclo de faturamento após a mudança por razões que ninguém no plano do projeto antecipou.

Junto com a própria credencial, vale a pena reter o que você tem permissão para manter para exibição e para previsão: bandeira do cartão, os últimos quatro dígitos e a data de validade. São esses dados que permitem ao cliente reconhecer qual cartão está cadastrado e o que permite identificar as credenciais que expirarão antes da próxima renovação e contatar esses clientes antes que a cobrança falhe.