PCI DSS para um diretorio de anuncios adultos: o que decide de verdade quanto trabalho de conformidade voce carrega
Conseguir que uma processadora de pagamentos aceite um site de anuncios adultos ja e uma batalha por si so, e uma vez vencida, quase todo operador presume que a parte dificil terminou. Nao terminou. A conta que finalmente diz sim vem com uma obrigacao permanente que nao tem nada a ver com verificacao de idade, moderacao, ou qualquer regra que um estado ou um buscador possa impor. E um padrao de seguranca escrito pelas proprias bandeiras de cartao, e vale a partir do momento em que um numero de cartao toca qualquer parte do seu negocio, por menor que ele seja.
O que vem a seguir nao e aconselhamento juridico, e quem realmente lida com dados de cartao deveria ter o caso revisado por um Qualified Security Assessor. E o formato de uma decisao que quase nenhum operador percebe estar tomando, porque quem a toma por ele costuma ser um desenvolvedor tentando construir uma pagina de pagamento mais bonita, bem antes de a questao chegar ao lado comercial da empresa.
A regra que voce assinou sem ler
O PCI DSS, o padrao de seguranca de dados da industria de cartoes de pagamento, nao e uma lei e nenhum orgao estatal o fiscaliza. E uma obrigacao contratual escrita no acordo que todo lojista assina com um banco adquirente ou um facilitador de pagamentos, e existe porque Visa, Mastercard e as demais bandeiras exigem que seus adquirentes repassem essa obrigacao a qualquer negocio que armazene, processe ou transmita um numero de cartao. O proprio orgao responsavel pelo padrao e explicito: ele vale para qualquer entidade que lide com dados de cartao, seja diretamente ou por meio de terceiros, sem excecao por tamanho ou volume de transacoes.
Essa e uma pergunta diferente da que uma processadora faz antes de concordar em abrir sua conta. O que uma processadora quer saber antes de aceitar trabalhar com voce e sobre o negocio em si: quem e o dono, como os anuncios sao revisados, como os anunciantes sao verificados. O PCI DSS comeca depois que essa conta existe, e na pratica nunca termina de verdade. Ele e renovado todo ano enquanto o negocio aceitar cartoes, e muda de forma sempre que muda o modo como os cartoes sao aceitos.
O volume de transacoes importa sim, so que nao do jeito que se costuma imaginar. Ele define um "nivel" de lojista, de um a quatro, e esse nivel decide como a conformidade e validada: um pequeno operador preenche um questionario de autoavaliacao, enquanto um negocio que processa milhoes de transacoes por ano precisa de um auditor externo. O que o volume nao faz e isentar ninguem. Um lojista de alto risco processando algumas centenas de transacoes por mes esta sujeito exatamente ao mesmo padrao de fundo que uma grande rede, apenas validado por um formulario mais curto.
A unica decisao que define sua carga de trabalho por anos
O formulario que se aplica a um determinado negocio nao e escolhido livremente. E determinado inteiramente por um fato tecnico: o numero do cartao, em algum ponto do trajeto, passa ou nao por um sistema controlado pelo operador. Enviar o cliente para uma pagina de pagamento hospedada pela processadora, ou embutir um iframe de pagamento corretamente isolado fornecido por essa processadora, faz com que o numero do cartao nunca toque o proprio servidor do operador. Construir em vez disso um formulario de pagamento que coleta o numero do cartao e o envia para o proprio backend antes de repassa-lo adiante, mesmo que por um instante, faz com que ele toque.
Esse unico fato separa o questionario mais leve do mais pesado por uma ordem de grandeza. O caminho totalmente terceirizado, conhecido como SAQ A, gira em torno de vinte requisitos. O caminho em que a propria pagina do operador entrega ou influencia parte do processo de pagamento, mesmo sem tocar diretamente no numero do cartao, como um formulario hospedado pelo proprio operador cujos campos repassam os dados adiante, cai no SAQ A-EP, perto de duzentos requisitos. Armazenar, processar ou transmitir de fato os dados do cartao nos proprios sistemas cai no SAQ D, que cobre o conjunto completo de controles do padrao: criptografia, gestao de chaves, segmentacao de rede, registro de acessos, controle de acesso, tudo, somando varias centenas de itens.
Vale a pena desfazer logo de cara um mal-entendido comum. Usar um iframe de um fornecedor conforme nao joga automaticamente um site para o nivel mais pesado do SAQ A-EP: um iframe de terceiros corretamente isolado, no qual a propria pagina do operador nao contribui com nenhum codigo capaz de ver ou tocar os campos de pagamento, geralmente continua se qualificando para o caminho leve do SAQ A. O que sobe um negocio de nivel e o proprio codigo do operador alcancando aquela pagina, seja um formulario construido internamente, um script adicionado para "melhorar" o pagamento, ou uma integracao de estilo antigo em que o navegador envia os dados do cartao por meio de codigo escrito pelo operador em vez de pela processadora.
O que o caminho leve ainda exige, desde o ano passado
Vale corrigir uma crenca que antes era verdadeira e ja nao e mais. Operadores que escolheram o caminho terceirizado aprenderam, com razao, que isso os mantinha fora da maior parte do peso tecnico do padrao, e alguns ainda acham que isso significa nenhuma verificacao de seguranca recorrente. Desde a versao 4.0.1 do PCI DSS, exigivel desde abril de 2025, isso nao e mais verdade. O SAQ A agora inclui um requisito de varreduras trimestrais de vulnerabilidade externa por um Approved Scanning Vendor, executadas contra o proprio site do operador, aquele que hospeda o redirecionamento ou o iframe, mesmo que esse site nunca veja um numero de cartao.
O raciocinio por tras da mudanca e simples uma vez dito em voz alta: a pagina que envia o cliente para a processadora de pagamentos ainda faz parte da superficie de ataque. Uma pagina de pagamento comprometida pode redirecionar um cliente para um lugar diferente da processadora real, ou carregar um script malicioso que le os dados do cartao direto do navegador antes mesmo de o iframe carregar, um padrao de ataque que ja atingiu lojistas reais. Da mesma logica decorrem dois requisitos relacionados: o operador precisa manter um inventario de cada script que roda na pagina de pagamento, e detectar alteracoes nao autorizadas no conteudo dessa pagina, obrigacoes que valem no SAQ A justamente porque a pagina de pagamento e do operador, mesmo quando o numero do cartao nunca foi.
O que o caminho leve continua evitando, e essa e a lacuna que realmente importa, e o teste de invasao anual exigido pelo SAQ A-EP e pelo SAQ D, junto com os controles internos profundos que esses niveis exigem: criptografar os dados de cartao armazenados, gerenciar as chaves que os protegem, segmentar a rede em torno de qualquer sistema que os toque, e registrar em detalhe todo acesso. Escolher o caminho terceirizado nao significa nenhum trabalho de seguranca. Significa algumas horas de varredura e higiene de scripts por ano, em vez de um programa de seguranca permanente construido em torno de dados que o negocio de outro modo estaria armazenando.
O que custa errar isso
Nada disso e fiscalizado por um tribunal ou um regulador, e essa e parte do motivo pelo qual e facil subestimar. As bandeiras multam o banco adquirente quando um lojista da sua carteira nao esta em conformidade, e o adquirente repassa esse custo direto ao lojista pelo contrato, tipicamente comecando com valores modestos e subindo quanto mais tempo a nao conformidade continuar. Nao existe uma tabela publica que fixe esses valores para cada adquirente, porque o acordo esta dentro de contratos privados, nao de regras publicas, mas a direcao e constante: a multa cresce com o tempo, nao com o quao bem o negocio explica o atraso.
Esse e o custo de simplesmente estar fora de conformidade. Uma violacao de verdade, em que numeros de cartao armazenados sao expostos porque um operador estava lidando com dados que o SAQ A foi desenhado justamente para evitar, e uma despesa de outra ordem completamente diferente. As bandeiras podem exigir uma investigacao forense por uma empresa especializada antes que alguem tenha permissao para reabrir a conta, paga pelo lojista independentemente do resultado, e os cartoes afetados sao reemitidos as custas do lojista. Um seguro de responsabilidade cibernetica raramente cobre esse tipo de lacuna para um negocio como este, ja que conteudo adulto aparece na lista de setores excluidos de mais de uma apolice cibernetica de grandes seguradoras, o que significa que a exposicao aqui descrita esta muito frequentemente sem seguro, nao apenas cara.
A consequencia mais duradoura nao e a multa nem mesmo a investigacao. E a decisao do adquirente, uma vez que uma violacao ou uma nao conformidade prolongada consta no registro, de encerrar a conta em vez de continuar assumindo o risco, e de registrar esse encerramento de um jeito que outros adquirentes podem ver antes de abrir uma nova. Uma relacao de pagamentos que levou meses para ser construida da primeira vez fica consideravelmente mais dificil de reconstruir com esse historico grudado ao negocio.
O que fazer este mes
Comece descobrindo, por escrito, qual questionario realmente se aplica hoje. Pergunte diretamente a processadora de pagamentos em vez de presumir a resposta: confirme se o pagamento atual e um redirecionamento, um iframe corretamente isolado, ou algo que toca o proprio servidor do operador em algum ponto do trajeto, porque a resposta a essa pergunta e todo o programa de conformidade resumido em uma frase. Consiga isso por e-mail, nao por telefone, ja que e o ponto de referencia para cada decisao seguinte.
Trate qualquer pedido de mudar como os cartoes sao coletados como uma questao de conformidade antes de ser uma questao de design. Um desenvolvedor que quer construir um formulario de pagamento personalizado porque a pagina hospedada parece generica, ou que adiciona um chat ou um script de analytics na mesma pagina que hospeda o iframe de pagamento, esta tomando uma decisao PCI, quer alguem enquadre assim ou nao. Revise esse tipo de mudanca antes de ela ir ao ar, nao depois que uma varredura acusar o problema.
Envie a atestacao anual dentro do prazo e guarde os resultados de cada varredura trimestral, ate as chatas em que nada muda, porque uma atestacao vencida se le, aos olhos de um adquirente, exatamente como nunca ter sido enviada. Nada disso e dificil quando a arquitetura de base esta certa. Um pagamento construido desde o inicio em torno de uma pagina hospedada ou de um iframe corretamente isolado transforma tudo isso em uma tarde de papelada, repetida uma vez por ano. Um pagamento que foi silenciosamente adquirindo o habito de tocar dados de cartao transforma a mesma obrigacao em um programa de seguranca permanente que o negocio nunca planejou administrar.
