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.
O que a conformidade PCI do Stripe realmente cobre
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.
O que isto cobre:
- Transmissão e armazenamento de dados de cartão dentro dos sistemas do Stripe
- Os iframes do Stripe Checkout e do Elements, que carregam a partir do domínio certificado PCI do Stripe
- Os SDKs móveis e Terminal do Stripe
O que isto não cobre:
- O JavaScript executado nas suas páginas web nos navegadores dos seus clientes
- Analytics, chat, consentimento ou qualquer outro script de terceiros em páginas que redirecionam para, ou carregam, um formulário de pagamento
- Os seus cabeçalhos de segurança HTTP ou as configurações de cookies
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.
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.
