PCI DSS e gateways cripto não custodiais

Primeiro os critérios PCI DSS: o que conta como exposição de dados de cartão

PCI DSS começa com uma pergunta simples: o fluxo de pagamento toca dados do titular do cartão? Se a resposta for não, talvez o PCI DSS nem entre em cena para esse fluxo. Se a resposta for sim, o escopo pode crescer rápido, até mesmo por causa de uma única chamada de API ou de um único ticket de suporte.

Dados do titular do cartão são o teste restrito aqui. Isso normalmente significa o número da conta principal, ou PAN, além de dados sensíveis de autenticação relacionados, como o CVV. Um fluxo que armazena, transmite ou pode afetar a segurança desses dados é o tipo de fluxo com o qual o PCI DSS se importa.

A custódia cripto não é o fator decisivo. Um PCI DSS gateway cripto não custodial ainda pode ficar próximo de dados de cartão em uma stack de checkout maior, e isso muda a pergunta imediatamente. A expressão “não custodial” soa definitiva. Não é.

Para um comerciante, isso importa porque uma única página de pagamento pode esconder duas atividades muito diferentes. Uma fatura em cripto talvez nunca veja um número de cartão. Um botão de pagamento com cartão na mesma página pode mudar o cenário de conformidade em um passo.

Lado a lado: gateway cripto não custodial vs. tratamento de dados de cartão

Compare dois fluxos. No primeiro, o cliente paga em cripto, o gateway gera um endereço de carteira, aguarda confirmações e envia um webhook assinado quando o pagamento cai. No segundo, o mesmo checkout também aceita cartões, talvez por meio de um formulário incorporado ou de um redirecionamento para um processador de cartões.

O primeiro fluxo pode ficar fora do escopo do PCI DSS para essa atividade cripto. O segundo pode colocar o comerciante, o operador do gateway ou ambos sob obrigações do PCI DSS se qualquer dado de cartão tocar os sistemas deles. Essa diferença não é cosmética. É o jogo inteiro.

Checkout híbrido é comum. Uma loja pode oferecer USDC no checkout e uma opção de cartão ao lado, porque os clientes querem escolha ou porque o financeiro quer menos pedidos com falha. Assim que o caminho do cartão aparece, o checkout cripto entra no escopo PCI DSS se houver qualquer ponto em que dados de cartão passem pelo mesmo ambiente ou pelas mesmas ferramentas.

Um detalhe importa mais do que a marca: onde o número do cartão entra na stack? Se os dados do cartão entram em uma página do comerciante, em um script do navegador, em um painel de suporte ou em um iframe de pagamento hospedado que ainda faz parte do domínio do comerciante, o escopo do PCI pode se ampliar. Se ele nunca entra nesses sistemas, o escopo pode continuar mais restrito.

A fronteira decisiva: apenas pagamento cripto, sem coleta de cartão

Este é o caso que muitos comerciantes realmente querem. O gateway apenas cria um endereço cripto, detecta o pagamento na blockchain, assina webhooks e marca o pedido como pago. Sem PAN. Sem CVV. Sem formulário de cartão. Nesse cenário, um gateway de pagamento cripto não custodial é um gateway de pagamento cripto não custodial sujeito ao PCI DSS apenas se dados de cartão aparecerem em outra parte do fluxo.

Essa frase não é uma pegadinha. É a fronteira. Se o checkout cripto do comerciante nunca coleta dados de cartão e o gateway nunca lida com dados de cartão, o PCI DSS não se aplica a esse fluxo cripto por si só.

Pense em uma loja de itens digitais aceitando 0,05 BTC ou 120 USDT por um pedido. O gateway confirma o pagamento na cadeia, o pedido é liberado e o cliente nunca digita um número de cartão. O PCI DSS não tem nada a inspecionar nessa troca exata.

Ainda assim, mantenha os sistemas ao redor honestos. Um comerciante pode usar o mesmo painel administrativo para pedidos em cripto e pedidos com cartão, e esse painel compartilhado pode se tornar relevante se expuser dados do titular do cartão ou relatórios relacionados ao cartão. Um painel pode carregar duas histórias de conformidade.

Para comerciantes planejando integrações, o caminho mais limpo é a separação. Mantenha a trilha de pagamento cripto isolada de qualquer trilha de captura de cartão. Se você também precisar de um processador de cartão, trate isso como um fluxo diferente, com seus próprios controles e sua própria revisão de fornecedor. Se quiser um ponto de referência técnico para construir esse lado, a documentação para desenvolvedores, API de gateway de pagamento cripto é o lugar para conferir os objetos de pagamento e o comportamento dos webhooks.

O gatilho oculto do PCI: checkout hospedado, campos de cartão incorporados e redirecionamento

O escopo do PCI costuma aparecer pela porta da frente, não pelo livro razão. Uma página de checkout hospedada pode coletar dados de cartão. Campos de cartão incorporados, bibliotecas JavaScript, widgets de redirecionamento, serviços de tokenização e até ferramentas de chat ou suporte que conseguem ver o que o cliente digita também podem fazer isso.

Esses detalhes importam porque, às vezes, os comerciantes presumem que “só fazemos redirecionamento” significa “estamos fora do escopo”. Isso é arriscado. Se o redirecionamento ainda passar dados de cartão pela sua página, pelo seu código ou pelos seus logs, o PCI DSS ainda pode importar. Se um campo de terceiro estiver incorporado no seu site, o ambiente do navegador ainda precisa de revisão.

O suporte ao cliente é um ponto cego comum. Um agente de suporte pedindo ao cliente que leia os dados do cartão por chat, e-mail ou formulário de chamado cria exposição fora da página de checkout. Um formulário esquecido pode ampliar o escopo. Um PAN copiado faz o mesmo, e também expõe dados de cartão em checkout híbrido em sistemas que ninguém havia considerado no desenho inicial.

Scripts de navegador merecem cuidado especial. Uma biblioteca de pagamento carregada na página pode ler mais do que o comerciante pretendia se não for rigidamente controlada. Por isso, os comerciantes devem revisar qualquer checkout hospedado, iframe ou script do lado do cliente antes de assumir que o ambiente cripto continua separado.

Se o site também aceita cartões em outros produtos, uma revisão de segurança deve cobrir os dois fluxos juntos. Nosso artigo sobre boas práticas de segurança para gateways de pagamento cripto é útil aqui, porque o escopo do PCI muitas vezes depende dos mesmos hábitos operacionais que mantêm as páginas de pagamento limpas desde o início.

Comerciante vs. operador do gateway: de quem é a responsabilidade PCI?

A responsabilidade PCI segue os dados do titular do cartão, não rótulos de marketing. O comerciante que captura o cartão, o operador do gateway que hospeda os campos do cartão, o processador que recebe a transação e o provedor de hospedagem que executa a stack podem ter um papel.

Para um checkout puramente cripto, o operador do gateway talvez nunca toque em dados de cartão. Nesse caso, as obrigações PCI para esse fluxo específico podem não existir. Para um checkout misto, o papel do operador depende de onde o PAN entra, quem o armazena e quais sistemas podem afetar sua segurança.

Os comerciantes costumam perguntar quem precisa validar a conformidade. A resposta é: quem estiver no escopo de tratamento de dados do titular do cartão. Isso pode significar apenas o comerciante, apenas o provedor do gateway ou ambos, dependendo da arquitetura e dos contratos.

A hospedagem também faz parte do quadro. Um servidor que armazena logs relacionados a cartão ou serve um formulário de pagamento não é apenas “infraestrutura”. Ele pode virar parte do ambiente PCI se dados do cartão puderem alcançá-lo. É por isso que o operador, o comerciante e qualquer processador devem mapear o fluxo antes de alguém preencher um questionário de conformidade.

Para comerciantes que operam sites WordPress, a arquitetura de checkout merece uma revisão separada. O artigo sobre aceitar pagamentos cripto no WordPress pode ajudar quando o site precisa de lógica de pagamento cripto sem trazer exposição desnecessária de cartão para a mesma stack de plugins.

Controles operacionais que importam se houver dados de cartão em qualquer ponto do fluxo

Ambientes mistos exigem disciplina. Comece pela segmentação de rede para que os sistemas que podem tocar dados de cartão não fiquem na mesma rede plana que todo o resto. Depois, limite o acesso por função, não por conveniência. Uma conta de administrador não deve ver tudo.

Logs importam, mas podem virar passivo se capturarem PAN ou CVV por engano. Regras de codificação segura devem bloquear isso. Mascaramento, redaction e validação de entrada não são extras bonitos; são a diferença entre um trilho de auditoria limpo e um incidente de conformidade.

Gestão de fornecedores também conta. Se um processador, provedor de iframe, ferramenta de analytics ou plataforma de suporte puder ver dados de cartão, o comerciante precisa saber disso. Contratos não substituem a revisão técnica. Um acordo assinado não impede um script de navegador de coletar demais.

Mantenha os dados de cartão fora dos sistemas do comerciante sempre que possível. Esse princípio reduz a carga do PCI mais do que quase qualquer outra coisa. Uma página de cartão hospedada que nunca devolve números de cartão ao comerciante costuma ser muito mais fácil de governar do que um formulário caseiro copiado de um modelo antigo.

Alguns comerciantes também operam cobrança SaaS junto com pagamentos cripto, o que torna as fronteiras de pagamento mais difusas. Se esse for o seu caso, veja gateway de pagamento cripto para SaaS para a parte do modelo de pagamento e, depois, mapeie a parte de cartão separadamente antes do lançamento.

Veredito honesto: quando a resposta é “não”, “talvez” ou “sim”

Para um gateway não custodial focado apenas em cripto, a resposta normalmente é “não” para esse fluxo. Se o gateway nunca toca dados do titular do cartão, o PCI DSS geralmente não é o framework relevante para o checkout cripto em si. A separação limpa é o motivo.

Para um gateway próximo a checkout com cartão ou a dados de cartão armazenados, a resposta vira “talvez” e muitas vezes passa para “sim” quando a arquitetura é inspecionada. O escopo exato depende de onde os dados do cartão entram, se são armazenados e se algum sistema pode influenciar sua segurança. Um único campo incorporado pode bastar.

Para um operador de gateway ou comerciante que processa pagamentos com cartão, a resposta provavelmente é “sim”. As obrigações do PCI DSS muito provavelmente se aplicam, mesmo que o mesmo negócio também ofereça pagamentos em cripto. Cripto não cancela a conformidade de cartão. Só fica ao lado dela.

Essa divisão importa para planejamento, equipe e preparação para auditoria. Uma equipe pode construir um checkout cripto não custodial e ainda assim ser responsável pelo PCI DSS em outra linha de produto. Dois métodos de pagamento. Duas revisões. Uma empresa.

Tabela rápida de decisão para comerciantes e integradores

Antes do lançamento, mapeie o fluxo de pagamento em cinco etapas: ponto de entrada, tipo de dado, ponto de armazenamento, caminho de transmissão e quem pode alterar o código. Se alguma etapa incluir dados do titular do cartão, o PCI DSS merece uma análise completa. Se não, mantenha o fluxo cripto separado e documente essa separação com clareza.

Para equipes que constroem programas pesados de payout junto com o checkout, o mapa de pagamento pode ficar confuso rapidamente. O artigo relacionado sobre cripto para programas globais de afiliados é útil para o lado de payouts, porque operações de pagamento e aceitação de cartão não são o mesmo problema de conformidade.

Um último ponto prático: faça a mesma pergunta para cada plugin, widget e script que carrega na página de pagamento. Três linhas de JavaScript podem importar mais do que trinta linhas de texto de política. Mantenha essa página sem surpresas. Esse costuma ser o resultado mais seguro.