Gestão dos valores de autenticação 3-D Secure em plataformas de iGaming

Um valor de autenticação do 3-D Secure (3DS) não é o mesmo elemento de dados que um código de verificação de cartão. Essa diferença importa quando uma plataforma de pagamentos decide o que armazenar depois da autorização — e não significa que todo campo 3DS deva ser retido.

Para um operador, processador ou fornecedor que integra o 3DS, a decisão prática é associar cada valor a uma finalidade definida, a um sistema e a funções que realmente precisem dele, além de uma regra de retenção que possa ser revisada. A classificação do PCI DSS é uma entrada desse projeto, não uma política completa de armazenamento.

O PCI SSC distingue valores 3DS dos dados de autenticação sensíveis do PCI DSS

A FAQ 1603 do PCI SSC, publicada em setembro de 2026, afirma que os valores de autenticação 3DS não são dados de autenticação sensíveis (SAD) para o PCI DSS. A FAQ identifica como SAD do PCI DSS os dados completos da tarja magnética, códigos ou valores de verificação de cartão e PINs ou blocos de PIN; o PCI DSS proíbe o armazenamento de SAD após a autorização. Também afirma que o PCI DSS não proíbe o armazenamento de dados 3DS depois de concluído o processo de autorização. Consulte a íntegra da FAQ do PCI SSC sobre valores de autenticação 3DS.

Essa é uma declaração de classificação específica. “Não proíbe” não significa “deve armazenar”, “é seguro guardar indefinidamente” nem representa aprovação para a avaliação de um comerciante específico. A afirmação não afasta a proibição separada de armazenar SAD após a autorização, nem resolve obrigações de privacidade, contrato, bandeira de pagamento ou outros controles de segurança aplicáveis a um dado ou fluxo específico.

Retenha um valor somente para um fluxo de pagamento definido

Um uso futuro documentado pode justificar a retenção de determinados dados 3DS. A orientação da EMVCo para transações recorrentes e parceladas descreve um 3DS Requestor mantendo o ID de transação do Directory Server (DS) e/ou do Access Control Server (ACS), junto com o valor de autenticação, para uma autenticação 3RI posterior. O fluxo técnico da EMVCo é um exemplo delimitado; não é uma regra para reter esses campos em todo pagamento ou para todo cliente.

Para cada campo armazenado, registre a próxima operação que o utilizará e o componente responsável por ela. Mantenha a referência de autenticação separada da autorização do pagamento, do registro de liquidação e do lançamento na carteira. O guia de orquestração de pagamentos explica por que esses estados são distintos em uma integração de plataforma.

Defina os limites de dados, acesso e exclusão

Um mapa de campo e finalidade permite que uma pessoa revisora responda a estas perguntas sem depender de um rótulo vago como “dados 3DS”:

Decisão	O que registrar
Elemento de dados	O valor ou identificador específico, sua origem e formato — não uma carga 3DS genérica.
Finalidade	O fluxo de autenticação que precisa dele, como uma solicitação 3RI posterior definida, e o serviço que o consome.
Funções e cópias	Qual comerciante, 3DS Requestor, processador ou componente 3DS o armazena ou recebe; inclua réplicas, exportações de suporte e backups. Não presuma que todo operador executa funções de ACS, DS ou 3DSS.
Acesso	Quais pessoas e serviços podem lê-lo ou exportá-lo e o motivo operacional de cada caminho.
Retenção e exclusão	A finalidade, o gatilho de revisão ou expiração, a pessoa responsável e como o valor é removido dos armazenamentos ativos e das cópias posteriores. Não invente um prazo universal.
Aplicabilidade	As questões de bandeira de pagamento, provedor, contrato, privacidade e avaliação que ainda precisam de uma resposta responsável.

Se a organização executar ou fornecer funções de ACS, DS ou servidor 3DS (3DSS), o PCI SSC recomenda confirmar com as bandeiras de pagamento pertinentes se o PCI 3DS Core Security Standard se aplica. O padrão destina-se a ambientes nos quais essas funções são executadas; seu escopo não é automaticamente igual ao escopo PCI DSS de todo operador.

Mantenha a telemetria rotineira separada da carga útil

Trate como dados de pagamento controlados qualquer valor que possa ser retido para um fluxo definido, mesmo que o PCI SSC não o classifique como SAD do PCI DSS. Um projeto conservador mantém o valor bruto fora de registros comuns da aplicação, rastros, análises e chamados de suporte, salvo quando uma necessidade operacional revisada exigir o contrário. Use uma referência de correlação limitada quando ela bastar para relacionar eventos e restrinja o sistema que guarda o valor original aos serviços e pessoas que precisam dele.

Essa é uma recomendação de engenharia, não um novo requisito do PCI DSS. O guia de registro de segurança e evidência de auditoria explica como preservar registros úteis para uma investigação sem copiar cargas sensíveis para logs gerais.

Teste o ciclo de vida, não apenas a resposta do 3DS

A aceitação deve percorrer todo o caminho de retenção. Por exemplo, teste se uma implementação de fluxo recorrente fornece somente os campos necessários para a próxima autenticação documentada; se um fluxo de uso único não acumula valores sem finalidade futura; se uma mudança de campo do provedor não mapeia silenciosamente o valor errado; se logs e exportações rotineiros não expõem a carga bruta; e se o fim da finalidade aciona o processo acordado de revisão e exclusão.

Teste também quem pode recuperar o campo armazenado, como o acesso fica registrado e se o registro de pagamento continua distinguindo autenticação, autorização e liquidação. Essas verificações tornam a decisão de dados da plataforma revisável; não certificam um sistema nem determinam o status de conformidade de um comerciante.

Se você estiver definindo uma integração de plataforma ou pagamentos, fale com a Wizards sobre os sistemas e o fluxo que precisa conectar.

Perguntas frequentes

Valores de autenticação 3DS são dados de autenticação sensíveis do PCI DSS?

Não. A FAQ 1603 do PCI SSC afirma que valores de autenticação 3DS não são SAD do PCI DSS. SAD do PCI DSS inclui dados completos da tarja magnética, códigos ou valores de verificação de cartão e PINs ou blocos de PIN; o PCI DSS proíbe retê-los após a autorização.

O PCI DSS exige que um valor de autenticação 3DS seja armazenado?

Não. O PCI SSC afirma que o PCI DSS não proíbe o armazenamento de dados 3DS após a autorização, mas isso não é uma obrigação de retê-los. Defina uma finalidade específica, um limite de acesso e uma regra de revisão ou exclusão antes de guardá-los.

Quando um valor 3DS pode ser usado em uma autenticação futura?

A EMVCo descreve um fluxo 3RI recorrente ou parcelado no qual um 3DS Requestor mantém o ID de transação do DS e/ou do ACS e o valor de autenticação para uma autenticação futura. O exemplo é específico desse fluxo definido e não deve ser generalizado para pagamentos sem relação.

O PCI 3DS Core Security Standard se aplica a todo operador de iGaming?

Não automaticamente. O PCI SSC descreve o padrão para ambientes que executam funções de ACS, DS ou servidor 3DS e recomenda que essas entidades confirmem a aplicabilidade com as bandeiras de pagamento pertinentes. Um operador não deve deduzir o próprio escopo a partir de um artigo geral.