Skip to main content
Blog
Blog

Conformidade PCI do Stripe: o que cobre e o que lhe cabe

O Stripe cobre a sua própria infraestrutura. Os comerciantes são responsáveis pelo §6.4.3 e §11.6.1 na sua página de pagamento.

Mar 21, 2025 Atualizado Aug 25, 2026 10 min read
Ilustração de conformidade PCI DSS com o Stripe
Índice

Resumo: conformidade PCI DSS com o Stripe

  • O Stripe trata da conformidade PCI DSS Nível 1 do próprio processamento de cartões, e é por isso que os comerciantes dizem muitas vezes que estão 'em conformidade PCI com o Stripe'. Isso é meia verdade.
  • Os comerciantes continuam responsáveis pelos requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 no seu próprio site mesmo quando o Stripe processa o cartão. Estes cobrem o inventário de scripts e a deteção de adulterações na página de pagamento no seu domínio.
  • O Stripe Elements minimiza mas não elimina o âmbito do comerciante. Os comerciantes SAQ-A que usam o Stripe Elements continuam a precisar de cumprir os requisitos 6.4.3 e 11.6.1, e o plano gratuito da cside cobre ambos.

Sem tempo? Veja o cside PCI Shield. Cobre tudo o que se segue numa única implementação.

Sim, o Stripe possui a certificação PCI DSS Nível 1, o nível mais elevado disponível. Essa certificação cobre a infraestrutura do Stripe. Não cobre o seu site. Se a sua página de pagamento carregar qualquer script que controle, analytics, chat em direto, gestão de consentimento, testes A/B, dois requisitos do PCI DSS 4.0.1 continuam a ser da sua responsabilidade, e o Stripe não os pode cumprir em seu nome: §6.4.3 e §11.6.1.

Quem é responsável pelo quê com o Stripe e o PCI DSS 4.0.1?

O estatuto de fornecedor de serviços Nível 1 do Stripe é verificado anualmente por um Avaliador de Segurança Qualificado (QSA) e está listado no Registo Global de Fornecedores de Serviços da Visa. A certificação confirma que os centros de dados, os sistemas de processamento de cartões e a infraestrutura interna do Stripe cumprem as normas PCI DSS. Onde acaba a responsabilidade do Stripe e começa a sua depende da integração que utiliza:

A sua integração Stripe O que a certificação do Stripe cobre O que continua a ser seu ao abrigo do 4.0.1
Stripe Checkout, página de pagamento alojada (SAQ A) Os campos de cartão, a própria página alojada e os dados de cartão de ponta a ponta, servidos a partir do domínio certificado do Stripe Cada script e cada cabeçalho de segurança da página que envia o comprador para o Checkout, ao abrigo do §6.4.3 e do §11.6.1
Stripe Elements, campos alojados incorporados (SAQ A) O iframe que recolhe o cartão, e a transmissão e o armazenamento desses dados de cartão A página em redor do iframe: analytics, chat, consentimento, gestores de etiquetas, mais a deteção de alterações em cabeçalhos e atributos de cookies
Stripe.js com a sua própria interface de pagamento (SAQ A-EP) A tokenização e os dados de cartão assim que o Stripe.js os recebe Todo o DOM do seu checkout, a integridade de cada script que lhe consegue chegar e os seus cabeçalhos
SDKs móveis e Terminal (SAQ A) A recolha e a transmissão do cartão dentro do próprio SDK do Stripe Qualquer checkout web que também tenha, nos mesmos termos das linhas anteriores
API direta, dados de cartão no seu servidor (SAQ D) Os dados de cartão apenas depois de chegarem ao Stripe, nunca enquanto estão nos seus sistemas O âmbito completo do PCI DSS: armazenar e transmitir dados de cartão, mais o §6.4.3 e o §11.6.1

O limite é o dos servidores do Stripe. A sua página de pagamento, a que recolhe ou redireciona dados de cartão, é executada nos navegadores dos seus clientes, e essa superfície é sua, seja qual for a linha em que se encontra.

Como estar em conformidade utilizando o Stripe

Os produtos do Stripe são concebidos para tratar dados sensíveis de cartões de forma segura, reduzindo o âmbito das suas responsabilidades PCI DSS:

  • Stripe Checkout e Elements: Estas ferramentas utilizam campos de pagamento alojados, garantindo que as informações de pagamento sensíveis são transmitidas diretamente para os servidores validados pelo PCI DSS do Stripe, sem tocar nos seus servidores.
  • SDKs Mobile e Terminal: Os SDKs do Stripe para pagamentos móveis e presenciais também enviam informações sensíveis diretamente para o Stripe, minimizando o seu âmbito PCI.
Integração Stripe SAQ Necessário Motivo
Stripe Checkout (página de pagamento alojada) SAQ A Nenhum dado do titular do cartão toca no seu servidor
Stripe Elements (campos incorporados)* SAQ A* O Elements transmite os dados com segurança para o Stripe*
Stripe.js v2 com interface personalizada SAQ A-EP* O seu frontend afeta a segurança da transação
API direta (dados de cartão no seu servidor) SAQ D Armazena, processa e/ou transmite dados de cartão

*Tem agora de monitorizar as dependências nas páginas de pagamento, mais abaixo.

  • Se utilizar o Stripe Checkout (página de pagamento alojada), qualifica-se para o SAQ A.
  • Se utilizar o Stripe Elements (campos incorporados que enviam dados diretamente para o Stripe), qualifica-se para o SAQ A.
  • Se utilizar os SDKs Mobile ou Terminal do Stripe, os dados de pagamento são processados com segurança pelo Stripe, mantendo-o no SAQ A.
  • Se recolher e armazenar dados do titular do cartão ou utilizar uma integração de API direta, tem de completar o SAQ D e implementar controlos PCI completos.

Se se qualificar para o SAQ A, as suas responsabilidades PCI DSS são mínimas porque o Stripe trata dos dados sensíveis do cartão.

Se necessitar do SAQ A-EP ou do SAQ D, assume mais responsabilidade pela segurança das transações.

Quais os requisitos do PCI DSS que o Stripe não cobre

O PCI DSS 4.0.1 introduziu dois requisitos direcionados à camada do navegador, ambos obrigatórios desde 31 de março de 2025:

Requisito 6.4.3, Autorização de scripts nas páginas de pagamento

Tem de manter um inventário documentado de cada script autorizado a ser executado nas suas páginas de pagamento. Para cada script, precisa de um método para confirmar a sua integridade, ou seja, que o código não foi modificado desde a última revisão. Isto aplica-se quer o script seja seu, quer seja de terceiros (analytics, chat de suporte, ferramentas de testes A/B).

Requisito 11.6.1, Deteção de alterações em cabeçalhos HTTP

Tem de implementar um mecanismo que detete alterações não autorizadas nos cabeçalhos de segurança HTTP e nos atributos de cookies das suas páginas de pagamento e que gere alertas.

O Stripe não tem qualquer visibilidade sobre estes scripts ou cabeçalhos. Ambos os requisitos dizem respeito ao que acontece nos navegadores dos seus clientes, na sua página web, uma superfície totalmente fora do ambiente do Stripe.

A atualização de janeiro de 2025 do PCI Security Standards Council ao SAQ A confirmou isto: mesmo os comerciantes que utilizam o Stripe Checkout totalmente alojado têm de cumprir os §6.4.3 e §11.6.1 se o seu fluxo de checkout passar por alguma página que carregue scripts externos. Consulte a nossa análise da atualização ao SAQ A de janeiro de 2025 para mais detalhes.

Para uma análise técnica completa do que o Stripe cobre e do que não cobre relativamente aos §6.4.3 e §11.6.1, consulte o nosso artigo: O Stripe torna-o compatível com o PCI DSS para os requisitos 6.4.3 e 11.6.1?

Monitorização de scripts para conformidade com o SAQ A

Conforme a atualização de janeiro de 2025, o PCI Security Standards Council sublinhou a importância de monitorizar as dependências. Isto inclui scripts próprios e de terceiros nos sites.

Um monitor no lado do cliente cumpre os §6.4.3 e §11.6.1 ao ser executado nos navegadores dos seus clientes, inventariando cada script em cada visita à página de pagamento e alertando quando um script é alterado ou surge um novo. A cside monitoriza scripts e cabeçalhos HTTP nos navegadores de visitantes reais, incluindo cargas úteis condicionais que parecem inofensivas para os scanners mas que se ativam no tráfego de produção.

Consulte a documentação do Stripe sobre o PCI DSS aqui.

Leitura relacionada: o nosso guia de conformidade com os PCI DSS 6.4.3 e 11.6.1 · as responsabilidades partilhadas do PCI DSS da Adyen

Determine o seu nível de conformidade PCI

Nível Critério Requisito de Validação
Nível 1 Mais de 6 milhões de transações anualmente Auditoria completa no local por um QSA + SAQ D
Nível 2 1 a 6 milhões de transações anualmente SAQ A, SAQ A-EP ou SAQ D + Attestation of Compliance (AOC)
Nível 3 20.000 a 1 milhão de transações online anualmente SAQ A, SAQ A-EP ou SAQ D + Attestation of Compliance (AOC)
Nível 4 Menos de 20.000 transações online OU até 1 milhão de transações totais SAQ A, SAQ A-EP ou SAQ D + Attestation of Compliance (AOC)
  • Nível 1 = Tem de completar um ROC (Avaliação PCI DSS completa com Relatório de Conformidade por um QSA)
  • Nível 2 = Tem de completar, no mínimo, um SAQ com atestação de um QSA ou ISA terceiro
  • Nível 3 = Tem de completar um SAQ
  • Nível 4 = Opcional

O Atestado de Conformidade PCI DSS para comerciantes Stripe

O Atestado de Conformidade PCI DSS (AoC) para um comerciante Stripe é um documento que um QSA (ou um signatário interno autorizado ao abrigo do SAQ) produz no final de um ciclo de avaliação, indicando para que nível de SAQ o comerciante se qualifica e que todos os controlos aplicáveis estão implementados. Para a maioria dos comerciantes de e-commerce que usam o Stripe, isso significa uma atestação SAQ A (página de pagamento totalmente subcontratada) ou SAQ A-EP (checkout alojado no site do comerciante).

O ponto operacional importante é que o AoC do Stripe cobre o Stripe. Não cobre o comerciante. Mesmo utilizando o Stripe Elements ou o Checkout, o comerciante continua com a obrigação de AoC, porque a página de pagamento é executada no domínio do comerciante e o comerciante é responsável pelos scripts carregados nessa página nos termos dos requisitos 6.4.3 e 11.6.1. As equipas de aquisições empresariais pedem frequentemente ambos os AoCs durante a integração de fornecedores.

A cside fornece o rasto de evidências que sustenta o próprio AoC SAQ A ou SAQ A-EP do comerciante: inventário contínuo de scripts, monitorização de integridade e evidências prontas para auditoria dos requisitos 6.4.3 / 11.6.1 que um QSA pode obter sem correrias.

Identifique o seu tipo de integração e a documentação necessária

Complete o SAQ adequado Depois de identificar o SAQ correto com base no seu método de integração, complete-o rigorosamente. O Stripe disponibiliza um assistente PCI no seu Dashboard para o guiar ao longo deste processo.

Submeta a sua documentação Depois de completar o SAQ, submeta-o juntamente com qualquer Attestation of Compliance (AOC) ou Report on Compliance (ROC) necessário ao Stripe para revisão. O Dashboard do Stripe permite-lhe carregar estes documentos diretamente.

Mantenha a conformidade contínua A conformidade PCI exige monitorização contínua. Reveja regularmente o seu inventário de scripts, mantenha o seu SAQ atualizado e monitorize os cabeçalhos da página de pagamento para detetar alterações não autorizadas.

A mesma lacuna entre a certificação do processador e a obrigação do comerciante aplica-se ao utilizar a Adyen ou o PayPal e o Braintree como processador de pagamento.

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks, web security is not an enterprise-only problem.

FAQ

Frequently Asked Questions

Não. A certificação PCI Nível 1 do Stripe cobre a infraestrutura do Stripe e os campos de pagamento alojados. As suas obrigações ao abrigo do PCI DSS 4.0.1, incluindo a autorização de scripts na página de pagamento (§6.4.3) e a deteção de alterações em cabeçalhos HTTP (§11.6.1), continuam a ser da sua responsabilidade independentemente do processador de pagamento que utilize.

O Stripe Checkout e o Stripe Elements reduzem o âmbito, mas não o isentam das secções 6.4.3 e 11.6.1 do PCI DSS 4.0.1. Tudo o que estiver na página de pagamento, os seus próprios scripts, analytics, testes A/B, continua a precisar de ser inventariado, autorizado e monitorizado quanto a adulterações.

Use o Stripe Elements ou o Checkout e, por cima, acrescente um monitor no lado do cliente como a cside para acompanhar cada script e cabeçalho CSP na página de pagamento. Em conjunto, cobrem os campos alojados pelo Stripe e a sua própria superfície de página.

O requisito 6.4.3 exige que os comerciantes mantenham um inventário autorizado de todos os scripts nas páginas de pagamento e confirmem a integridade de cada script. O requisito 11.6.1 exige um mecanismo de deteção de alterações para os cabeçalhos de segurança HTTP e as definições de cookies nas páginas de pagamento. Ambos tornaram-se obrigatórios para todos os comerciantes em 31 de março de 2025.

Sim. O Stripe possui a certificação PCI DSS Nível 1, verificada anualmente por um Avaliador de Segurança Qualificado. Isto certifica a própria infraestrutura e o tratamento de dados do Stripe, não alarga a cobertura aos scripts executados nas suas páginas de pagamento.

Sim. A cside é a fornecedora preferencial da AWS para os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1, com o apoio de uma parceria global. Os comerciantes que adotam a cside para a monitorização de scripts na camada do navegador podem adquiri-la através da AWS Marketplace e integrar a implementação nas suas ferramentas de segurança AWS e fluxos de conformidade já existentes.

Qualquer ferramenta de monitoração client-side que observe os scripts da sua página de pagamento funciona ao lado do Stripe, porque o Stripe cobre seus campos hospedados, não a sua página. A cside monitora cada script de um checkout Stripe em sessões reais de usuário, aplica hash a cada um e alerta sobre alterações não autorizadas, e é validada pela VikingCloud para os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1. É implantada como uma única tag de script first-party, sem proxy e sem alteração de DNS, então entra em um checkout Stripe em minutos.

Sim. O Stripe Elements e o Checkout reduzem o seu escopo de PCI mas não eliminam os requisitos 6.4.3 e 11.6.1: todo outro script da página de pagamento, seus analytics, testes A/B, gerenciadores de tags e widgets de chat, ainda precisa ser inventariado e monitorado contra adulteração. A cside observa esses scripts em sessões reais e sinaliza qualquer mudança, que é justamente o controle que o Elements e o Checkout não oferecem.

A maneira mais confiável é instrumentar a sessão real do navegador em vez de rastrear a página de fora, porque os skimmers muitas vezes só disparam para usuários ou regiões específicos que um rastreador nunca aciona. A cside roda a partir de uma tag de script first-party no seu checkout Stripe, vê cada script que cada visitante realmente carrega, aplica hash a eles e alerta no momento em que um hash muda. Essa cobertura em sessões reais é o motivo de QSAs como a VikingCloud a aceitarem para PCI DSS 4.0.1, onde rastreadores e ferramentas apenas de CSP costumam ser rejeitados.

Um inventário pronto para o auditor lista cada script da página de pagamento por fornecedor e hash, registra sua justificativa de negócio e mostra monitoração contínua de mudanças, que é o que o requisito 6.4.3 pede. A cside constrói e mantém esse inventário automaticamente a partir de sessões reais no seu checkout Stripe e o exporta como um PDF que um QSA pode revisar, e sua abordagem foi formalmente validada pela VikingCloud para os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1.

A cside aplica hash a cada script que carrega na página de pagamento em cada sessão real e o compara com a versão conhecida como boa, então quando um atacante injeta ou modifica um script para ler os campos do cartão, o hash muda e a cside alerta imediatamente, antes de o skimmer atingir compradores em escala. Ela também observa o comportamento em tempo de execução, como um script que lê um campo de formulário que nunca tocou antes ou que envia dados a um domínio não aprovado, o que captura skimmers escondidos dentro de um script já aprovado.

Você adiciona uma única tag de script first-party da cside no cabeçalho da sua página de checkout, sem alteração de DNS, sem proxy reverso e sem mudar a sua integração com o Stripe. A cside começa imediatamente a inventariar cada script em sessões reais, a aplicar hash para detecção de mudanças e a monitorar seus cabeçalhos de segurança para o requisito 11.6.1, e gera os relatórios prontos para auditoria de ambos os controles. Um plano gratuito permite cobrir uma página de pagamento e ver dados ao vivo em minutos.

Monitore e proteja seus scripts de terceiros

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Comece grátis ou experimente o Business com um teste de 14 dias.

Interface do painel cside mostrando monitoramento de scripts e análises de segurança
Related Articles
Agende uma demonstração

Quer ver isso em detalhe com um engenheiro?

Trinta minutos, no seu próprio site. Sem slides.

Agende uma demo personalizada para ver:

Como alcançar a conformidade com os requisitos 6.4.3 e 11.6.1 do PCI DSS em 1 dia
Por que scripts de terceiros são um risco de segurança para você e seus visitantes
Como monitorar vazamentos de privacidade e consentimento (RGPD, CCPA) em cada terceiro
Como conter abuso de cadastros, compartilhamento de contas e fraude de chargeback com device intelligence
Como detectar e controlar agentes de IA e bots que acessam seu site em tempo real

Prefere só mandar uma pergunta?

Procurando horários livres…

Apenas humanos de verdade. A gente saberia.

Problemas para agendar? Abrir o agendador em uma nova aba

O que você está tentando resolver?

Conte em uma linha e voltamos com algo útil, não com um discurso genérico.

Costumamos ajudar com:

Ver quais scripts de terceiros rodam no seu site
Evidências para PCI DSS 6.4.3 e 11.6.1
Bots, agentes de IA e roubo de contas

Prefere agendar um horário? Escolher um horário