Os dados de cartão são uma responsabilidade conhecida das empresas. O custo médio global de uma violação de dados foi de US$ 4,44 milhões em 2025. Cada servidor, arquivo de log e backup que armazena um número de conta principal (PAN) passa a fazer parte do que o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) chama de ambiente de dados do titular do cartão (CDE, na sigla em inglês), e todos os aspectos desse ambiente estão sujeitos aos requisitos de conformidade.

A tokenização muda o que está de fato nesse ambiente, substituindo o PAN por um valor substituto que não carrega valor passível de exploração por conta própria. Se a tokenização for implementada corretamente, as obrigações de conformidade poderão ser reduzidas a uma fração do que seriam caso contrário. Abaixo, abordamos como funciona a tokenização para conformidade com PCI, os limites de suas proteções, onde outros controles de segurança precisam ser implementados e o que o Conselho de Padrões de Segurança do PCI exige de um sistema de tokens em conformidade.

Principais conclusões

• A tokenização pode remover sistemas inteiros do escopo de conformidade do Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS, na sigla em inglês), mas somente se a geração de tokens, a segurança do cofre e os controles de destokenização atenderem a padrões técnicos específicos.

• A criptografia e a tokenização protegem dados de cartão de forma diferente de acordo com o PCI DSS, e muitas arquiteturas em conformidade dependem de ambas, e não da escolha de uma ou outra.

• A qualificação para o questionário de autoavaliação de conformidade com PCI mais simples depende de como os dados de cartão fluem por meio de uma integração, e não apenas de haver tokenização em alguma parte do sistema.

O que é conformidade PCI DSS

A conformidade com o PCI DSS significa cumprir os requisitos de segurança definidos pelo Conselho de Padrões de Segurança do PCI, aplicáveis a qualquer empresa que armazena, processa ou transmite dados do titular do cartão. O padrão abrange 12 requisitos fundamentais sobre segurança de rede, controle de acesso, criptografia e monitoramento. Aplica-se a empresas que gerenciam um único terminal de pagamentos ou que processam milhões de transações por ano.

O que diz o PCI DSS a respeito da tokenização

As diretrizes do PCI DSS em relação à tokenização afirmam que, se um token não tiver valor fora do sistema em que foi criado e esse sistema estiver devidamente isolado e seguro, os ambientes em que o token permanece não precisarão ser avaliados como se contivessem dados reais de cartão. O PAN continua existindo em algum lugar (geralmente em um cofre criptografado), mas a tokenização significa que ele existe apenas nesse local único, e não distribuído por diversos sistemas.

Como a tokenização reduz o escopo da conformidade com PCI

A tokenização reduz o escopo da conformidade com PCI limitando o número de locais em que dados legíveis de cartão são armazenados ou transmitidos. Isso é verdade desde que ninguém fora do sistema de tokenização consiga usar o token para reverter ao PAN original. Se alguém puder calcular o PAN a partir do token usando uma lógica conhecida, o token não reduzirá o escopo.

Diretrizes e requisitos de tokenização do PCI DSS para redução de escopo

As diretrizes do Conselho de Padrões de Segurança do PCI incluem expectativas técnicas específicas para qualquer sistema que alegue redução de escopo. Elas se dividem em duas categorias principais: geração de tokens e cofres de tokens.

Geração de token

A geração de tokens deve resistir à engenharia reversa. Tokens que preservam o formato e imitam o tamanho e a estrutura de um determinado número de cartão estarão seguros se a substituição em si for imprevisível, em vez de derivada de uma fórmula reversível.

Tokens criados por um processo unidirecional, em que não há função matemática inversa, se qualificam com mais segurança para redução de escopo do que tokens gerados por meio de criptografia com uma chave recuperável. Os valores criptografados ainda são considerados dados do titular do cartão de acordo com as definições do PCI DSS, mesmo quando formatados para se parecer com tokens. A maneira como os tokens são gerados determina como o avaliador classificará o sistema. As diretrizes do PCI DSS também abordam a resistência a força bruta. Se o algoritmo de tokenização puder ser adivinhado ou revertido por meio de repetidas tentativas, o token não se qualificará para redução de escopo, não importa como seja gerado.

Cofres de tokens

O sistema que armazena os tokens é chamado de cofre. O cofre de tokens precisa ficar em uma zona de rede segmentada, aplicar um rigoroso controle de acesso baseado em função a dados que mapeiam os tokens ao PAN original e registrar todas as ocorrências de destokenização em log com nível de detalhamento que permita a análise forense. Os avaliadores de PCI DSS costumam seguir o padrão de que a destokenização deve ser rara, deliberada e auditável. A diretriz também exige que o provedor de tokenização (seja uma equipe interna, seja de terceiros) passe por sua própria avaliação de PCI DSS. Um cofre comprometido acaba com o objetivo da tokenização.

A documentação precisa provar a alegação de redução de escopo aos avaliadores e deve incluir um diagrama de fluxo de dados mostrando exatamente onde os PANs existem em texto simples (ou seja, dados legíveis não criptografados), onde a tokenização ocorre e onde os tokens assumem o controle nos sistemas. O diagrama deve ser atualizado sempre que um novo sistema entrar no caminho de pagamento. Caso contrário, a alegação de redução de escopo não corresponderá mais à realidade, mesmo se nada mais mudar.

Como a tokenização se compara com a criptografia de acordo com o PCI DSS

Tanto a tokenização quanto a criptografia protegem os mesmos dados subjacentes, mas o PCI DSS as trata de forma bem diferente quando se trata de escopo. Um PAN criptografado costuma permanecer no escopo, a menos que o sistema de armazenamento não tenha acesso às chaves de descriptografia necessárias para ler o texto cifrado (o formato criptografado). O sistema que contém o texto cifrado deve atender aos mesmos requisitos de controle de acesso, registro de atividades em log e gestão de vulnerabilidades de um sistema que armazena o PAN em texto simples, mesmo que o risco prático seja menor.

Com a tokenização, não há chave a ser protegida. Quando um token é gerado por meio de um processo unidirecional devidamente implementado, não pode ser revertido matematicamente, o que significa que os sistemas que o mantêm existem fora do CDE.

Na prática, muitas arquiteturas em conformidade com PCI usam a criptografia e a tokenização porque cada uma adiciona diferentes salvaguardas. A criptografia protege o PAN dentro do cofre de autorização e liquidação de fundos, e a tokenização protege o PAN em qualquer outro lugar (por exemplo, nos sistemas que precisam consultar uma transação, emitir um reembolso ou exibir ao cliente os quatro últimos dígitos, sem a necessidade de acessar o número real). Em suma, a criptografia protege dados utilizáveis e a tokenização os remove totalmente do sistema.

De quem é a responsabilidade por manter a conformidade da tokenização após a implementação?

A conformidade com o PCI DSS exige validação contínua, e a tokenização adiciona seus próprios requisitos de manutenção além do ciclo habitual de aplicação de patches (ou seja, atualizações de segurança) e monitoramento do padrão. Se você usa um provedor de tokenização terceirizado, ainda assim a responsabilidade de confirmar que ele mantém a própria validação do PCI DSS e de revisar anualmente o Atestado de Conformidade do provedor é sua. Uma certificação expirada do lado do fornecedor coloca em risco sua própria alegação de redução de escopo, mesmo que nada tenha mudado do seu lado.

Internamente, alguém precisa ser o proprietário do diagrama de fluxo de dados e atualizá-lo sempre que um novo sistema entrar no caminho de pagamento. A redução de escopo pode se perder de forma silenciosa, por exemplo, quando se conecta uma nova ferramenta de análise de dados ou uma equipe de suporte exporta dados de transações para uma planilha a fim de realizar a solução de problemas e encontra um PAN em texto simples que não havia sido contabilizado na última avaliação. Os logs de acesso ao cofre também devem ser revisados de tempos em tempos para se identificar as solicitações de destokenização incompatíveis com os processos de negócios previstos.

Em muitas empresas de médio porte, essa responsabilidade recai sobre quem gerencia a infraestrutura de pagamento (geralmente do departamento financeiro ou de engenharia), com a ajuda de um avaliador de segurança qualificado (QSA, na sigla em inglês) no ciclo de avaliação anual. As empresas de pequeno porte que usam provedores de pagamentos que gerenciam a tokenização de ponta a ponta têm menos trabalho, mas ainda devem confirmar que não reintroduziram PANs nos próprios sistemas com exportações, capturas de tela ou fluxos de trabalho de atendimento ao cliente que não faziam parte da redução de escopo original.

A tokenização por si só é suficiente para garantir a conformidade com o PCI DSS?

A tokenização reduz o escopo, mas não elimina as obrigações de conformidade no que diz respeito aos sistemas que permanecem no escopo. O cofre continua precisando estar em total conformidade: a lógica de geração, os dados de mapeamento de token para PAN e os controles de destokenização devem todos atender aos padrões completos do PCI DSS.

Os pontos de contato de pré-tokenização também devem permanecer no escopo. Todo sistema que lida com um PAN antes da tokenização, como uma página de checkout ou um ponto de venda (POS), precisa de criptografia em trânsito, segmentação de rede e verificação de vulnerabilidades.

A lacuna de qualificação do questionário de autoavaliação (SAQ)

Muitas empresas presumem que qualquer solução de tokenização as qualifica a usar o Questionário de autoavaliação A (SAQ A), a modalidade mais simples do questionário. No entanto, isso só é verdade se o sistema de tokenização impedir que a empresa lide com os PANs, os transmita ou armazene de alguma forma (em geral por meio de uma página de pagamento hospedada ou de um componente integrado em que os dados de cartão são enviados diretamente do navegador do cliente para o provedor de pagamentos). Uma abordagem de tokenização em que dados brutos de cartão ainda passam pelo servidor da empresa, mesmo que de forma rápida, antes de serem tokenizados mantém o servidor em um escopo mais amplo, não importa o nível de eficácia da tokenização a partir de então.

Como o Stripe Payments pode ajudar

O Stripe Payments oferece uma solução global e unificada de pagamentos que ajuda qualquer empresa — de startups em crescimento a corporações globais — a aceitar pagamentos online, presenciais e em todo o mundo.

O Stripe Payments pode ajudar você a:

• Otimize a experiência de checkout: crie uma experiência fluida para o cliente e poupe o tempo da equipe de engenharia com as interfaces de usuário para pagamento pré-criadas, o acesso a mais de 125 formas de pagamento e o Link (a carteira criada pela Stripe).

• Expanda para novos mercados mais rapidamente: alcance clientes em todo o mundo e reduza a complexidade e o custo da gestão multimoedas com opções de pagamento internacional, disponíveis em 195 países e mais de 135 moedas.

• Unifique pagamentos presenciais e online: desenvolva uma experiência de unified commerce entre canais online e presenciais para personalizar interações, recompensar a fidelidade e aumentar a receita.

• Melhorar o desempenho dos pagamentos: aumente a receita com ferramentas configuráveis, proteção contra fraudes no-code e recursos avançados que elevam as taxas de autorização.

• Avançar mais rápido com uma plataforma flexível e confiável para crescer: desenvolva sobre uma plataforma projetada para crescer junto com o seu negócio, com 99,999% de disponibilidade histórica e confiabilidade líder do setor.

Saiba mais sobre como o Stripe Payments pode potencializar seus pagamentos presenciais e online ou comece já.