Desenhe o limite real de pagamento
Mapeie o caminho do comprador desde a página do produto até a confirmação. Marque a entrada do cartão, redirecionamentos, frames, scripts, APIs, plugins, gerenciadores de tags, redes de distribuição de conteúdo e contas de administrador que podem influenciá-lo. Inclua logs relacionados, ferramentas de suporte e analytics. Este é um registro inicial para seu provedor ou avaliador, não uma decisão de conformidade.
Registre o domínio que serve cada elemento da página de pagamento. O PCI SSC diz que a elegibilidade para SAQ A exige que todos os elementos das páginas de pagamento sejam originados apenas por provedores de serviço compatíveis com PCI DSS e nenhum pelo site do comerciante. Para SAQ A-EP, cada elemento pode originar do comerciante ou de tal provedor, mas não de outra fonte. Todos os demais critérios ainda se aplicam.
Um repositório de código pode não mostrar injeções do gerenciador de tags e configurações da plataforma. Revise scripts, frames, domínios e cabeçalhos em uma sessão normal de checkout no navegador.
Reveja logs, analytics e fluxos de suporte para campos de pagamento. Nunca use dados reais de cartão em tickets de teste ou evidências compartilhadas.
Reduza a exposição com um modelo de pagamento explicável
Quando prático, use uma integração em que um provedor compatível com PCI DSS colete os dados do cartão em vez da sua aplicação recebê-los ou armazená-los. Um redirecionamento totalmente hospedado pelo provedor costuma ser mais simples que um formulário customizado, mas campos embutidos e iframes ainda podem permitir que seu site afete o pagamento. Documente a integração real em vez de confiar apenas em um rótulo de hospedeiro.
Evite reter números de conta primária, códigos de segurança, capturas de tela de erros no checkout ou detalhes de pagamento copiados, a menos que um desenho aprovado os exija. Criptografia ajuda a proteger dados, mas o PCI SSC adverte que apenas criptografia geralmente não remove um ambiente do escopo. Confirme o manuseio de tokens, chaves, webhooks, reembolsos e responsabilidades com o provedor e revisores qualificados.
Mantenha o guia de integração, informações de responsabilidade, documentação de conformidade relevante e o processo de notificação de mudanças junto ao registro de arquitetura.
Não adicione experimentos de marketing, ferramentas de replay, widgets de chat ou bibliotecas opcionais sem um proprietário nomeado e revisão do que eles podem acessar.
Controle scripts, tags e cabeçalhos
Código de terceiros no navegador pode introduzir mudança não controlada, execução arbitrária de código e divulgação para outras partes. Mantenha um inventário do checkout com o domínio de cada script, propósito, proprietário, aprovação e local de carregamento. Inclua regras do gerenciador de tags e código carregado por fornecedores, não apenas arquivos na árvore de código-fonte.
O PCI SSC foca em scripts autorizados, integridade, monitoramento de adulteração e cabeçalhos que impactam a segurança. Aprove um baseline, restrinja mudanças, detecte diferenças e investigue-as. Uma Content Security Policy (CSP) pode restringir origens de recursos. Quando apropriado, teste-a em modo apenas-relatório antes de aplicar. CSP é defesa em profundidade, não substituto para codificação segura ou revisão.
Subresource Integrity pode rejeitar um script externo alterado, mas requer configuração cross-origin compatível e pode quebrar após atualizações do fornecedor.
Limite papéis de publicação, exija autenticação forte, reveja a capacidade de código personalizado e mantenha trilha de auditoria.
Limite acessos e torne mudanças no checkout recuperáveis
Separe publicação rotineira de conteúdo do código do checkout, administração do provedor de pagamento, hosting, DNS e gerenciamento de tags. Use contas nomeadas, princípio do menor privilégio e autenticação de múltiplos fatores quando disponível. Reveja acessos após mudanças de função e remova ex-colaboradores, fornecedores e agências. A aplicabilidade exata do PCI DSS depende do ambiente, mas reduzir privilégios compartilhados e permanentes diminui o risco.
Use um processo de liberação para o checkout: proprietário nomeado, revisão, testes quando possível, método de rollback e verificação pós-lançamento no navegador. Teste caminhos de sucesso e falha, redirecionamentos e comportamento móvel. Status Is UP suporta preparação pró-ativa para lançamentos, otimização de desempenho e planejamento de rollback em torno de releases; não determina conformidade com PCI DSS.
Mantenha credenciais, códigos de backup e instruções de rollback em sistemas aprovados com controle de acesso; nunca em tickets, capturas de tela ou repositórios públicos.
Após a liberação, compare scripts, domínios e cabeçalhos visíveis no navegador com o inventário aprovado.
Atualize a pilha e verifique o resultado
Mantenha um inventário da plataforma de comércio, plugins, temas, componentes de servidor, bibliotecas, SDKs de pagamento, templates de tags e serviços que afetam o checkout. Assine avisos críticos dos fornecedores. O NIST descreve gestão de patch como identificar, priorizar, adquirir, instalar e verificar atualizações. Registre a mudança, teste a jornada de pagamento e confirme o que foi implantado.
Defina um caminho de emergência para problemas de alto risco e uma janela de manutenção para mudanças rotineiras. Priorize componentes expostos do checkout, mas não aplique patches cegamente em produção e quebre pagamentos. Use uma abordagem de rollback testada e a orientação de releases do provedor. Um componente desatualizado sem proprietário identificado é um risco a ser resolvido.
Mantenha o advisory, decisão de risco, resultado de teste, registro de implantação e verificação final juntos.
Mantenha evidências e use ajuda qualificada
Mantenha diagramas, informações de responsabilidade do provedor, justificativa de elegibilidade para SAQ, inventários de scripts e cabeçalhos, revisões de acesso, aprovações, resultados de testes, mudanças e contatos de fornecedores em um local controlado. Atualize-os quando arquitetura, propriedade, scripts ou provedores mudarem. A evidência deve ajudar um revisor autorizado sem expor dados de cartão, segredos ou registros de clientes.
Seu adquirente ou a bandeira do cartão define as expectativas de validação aplicáveis. O PCI SSC identifica Qualified Security Assessors (QSAs) como organizações independentes qualificadas para realizar avaliações PCI DSS e Approved Scanning Vendors (ASVs) como provedores qualificados de varredura externa sob os requisitos aplicáveis. Busque ajuda qualificada para checkout customizado, escopo incerto, suspeita de comprometimento ou seleção de SAQ.
Guarde o modelo de checkout, proprietários técnicos, contatos de escalonamento, data da última revisão e links para evidências juntos.