Campos de cartão hospedados pelo gateway resolvem tudo?

Não. Os campos de cartão hospedados pelo gateway (exibidos dentro de uma janela embutida na página, servida pelo provedor de pagamento) tiram os dados do cartão do alcance do seu servidor e do código da sua página e, por isso, reduzem bastante o escopo do PCI DSS. Mas a página ao redor continua sendo sua, e é nela que o ataque pode acontecer: um formulário falso antes do verdadeiro, a troca da janela por outra, um botão que leva a outro lugar. O próprio PCI Security Standards Council diz que a página que embute o formulário do provedor continua no escopo.

O que os campos hospedados resolvem

Nesse modelo, os campos de número, validade e código de segurança não fazem parte da sua página: eles vivem numa pequena janela embutida (um iframe) cujo conteúdo vem do endereço do provedor. O navegador isola conteúdos de endereços diferentes, então o código que roda na sua página (inclusive um código malicioso) não consegue ler o que o cliente digita dentro dessa janela. Os dados vão direto para o provedor.

É um ganho real. Menos dados passam pela loja, menos requisitos se aplicam e muitos lojistas podem usar o questionário de autoavaliação mais simples, o SAQ A, se cumprirem os critérios de elegibilidade. Quem usa campos hospedados deve continuar usando. A questão é não confundir reduzir o escopo com eliminar o risco.

Onde o risco continua

O guia do PCI SSC sobre segurança da página de pagamento, de março de 2025, é direto: embutir o formulário de um terceiro não tira completamente do escopo a página que o exibe, nem torna inaplicáveis os requisitos 6.4.3 e 11.6.1. Cabe à loja cuidar dos scripts dessa página e, quando a janela é criada por um script, esse script também entra nos requisitos. Na prática, o criminoso tem vários caminhos sem precisar tocar nos campos do provedor:

• Formulário falso antes do verdadeiro. Em fevereiro de 2026, a empresa de pesquisa Sansec relatou o caso de uma rede de supermercados com presença internacional em que o formulário real era do provedor de pagamento. O código injetado na página da loja mostrava antes um formulário falso; o cliente digitava ali, depois via o formulário legítimo e digitava de novo. Segundo a Sansec, justamente porque o cartão passou a ser digitado em formulários dos provedores, os criminosos têm preferido esse tipo de sobreposição.
• Troca ou cobertura da janela. É a sua página que diz ao navegador de onde carregar a janela de pagamento. Se o código que faz isso for alterado, a janela pode vir de um endereço parecido, ou ficar escondida sob uma camada idêntica.
• Desvio no botão. O botão de pagar e os passos anteriores também são da sua página e podem ser alterados para levar o cliente a outro lugar.
• Dados fora da janela. Nome, e-mail, telefone e endereço costumam ser digitados na sua página, não na do provedor.
• Sites de página única. Quando o navegador não recarrega entre as etapas, scripts carregados no início da visita continuam ativos no pagamento; o guia considera todas as telas no escopo.

O que mudou no SAQ A e o que continua valendo

Em janeiro de 2025, o PCI SSC retirou os requisitos 6.4.3 e 11.6.1 do SAQ A, mas acrescentou um critério de elegibilidade: o lojista precisa confirmar que o seu site não está suscetível a ataques de scripts que possam afetar seus sistemas de comércio eletrônico. O Conselho frisou que a mudança não remove nem enfraquece os requisitos de fundo do PCI DSS.

Em fevereiro de 2025, a FAQ 1588 explicou que esse critério vale para lojas cuja página embute o formulário do provedor, e não para as que redirecionam o cliente para o site do provedor. Há dois caminhos para cumpri-lo: aplicar técnicas como as dos requisitos 6.4.3 e 11.6.1 para proteger a página contra scripts que buscam dados de conta, por conta própria ou com um terceiro; ou obter do provedor, em conformidade com o PCI DSS, a confirmação de que a solução dele inclui essa proteção para a página da loja, desde que implementada conforme as instruções. Ou seja: o questionário ficou mais curto, mas a pergunta sobre a sua página continua lá.

Checklist para quem usa campos hospedados

• Pergunte ao provedor, por escrito, se a solução inclui proteção da sua página contra scripts e em que condições, e siga as instruções de implementação à risca.
• Trate a página que exibe o formulário como sensível. Mantenha nela só os scripts indispensáveis e saiba quem pode alterá-la.
• Inventarie e vigie os scripts dessa página, como o navegador do cliente a recebe.
• Confira na tela do comprador que a janela de pagamento vem do endereço do provedor e que não há outro formulário de cartão antes ou por cima dela.
• Proteja o que fica fora da janela, como nome, e-mail e endereço.
• Leve a sério relatos de dupla digitação do cartão.
• Confirme com a adquirente qual questionário se aplica à sua loja.

O Proteside protege justamente a página ao redor dos campos do provedor: confere, no navegador do comprador, que o formulário exibido é o legítimo e que vem do endereço certo, bloqueia sobreposições e gera a evidência dos requisitos 6.4.3 e 11.6.1. Conheça a proteção para pagamentos com cartão e a solução para conformidade com o PCI DSS, e teste grátis por 14 dias.