Pular para o conteúdo principal

Conformidade com PCI-DSS para comércio eletrônico: segurança de pagamento e tokenização

Guia completo de conformidade com PCI-DSS v4.0 para empresas de comércio eletrônico, abrangendo tokenização, 3D Secure, seleção de SAQ, verificação de vulnerabilidades e testes de penetração.

E
ECOSIRE Research and Development Team
|15 de março de 202613 min de leitura2.6k Palavras|

As perdas com fraudes em pagamentos com cartão ultrapassaram US$ 33 bilhões globalmente em 2025, e o comércio eletrônico é responsável por 73% de todas as fraudes com cartões.

Parte da nossa série Conformidade e regulamentação

Leia o guia completo

As perdas com fraudes em pagamentos com cartão ultrapassaram US$ 33 bilhões globalmente em 2025, e o comércio eletrônico é responsável por 73% de todas as fraudes com cartões. O Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI-DSS) existe para combater isso, e a versão 4.0 --- que se tornou obrigatória em março de 2025 --- introduziu novos requisitos significativos que muitas empresas de comércio eletrônico ainda estão lutando para implementar.

A boa notícia: se você usar uma solução de pagamento hospedada como Shopify Payments ou Stripe Checkout, seu escopo de PCI será drasticamente reduzido. A má notícia: nunca é zero. Toda empresa de comércio eletrônico que aceita pagamentos com cartão tem obrigações PCI-DSS, mesmo que nunca veja o número do cartão.

Principais conclusões

  • PCI-DSS v4.0 introduz abordagens de validação personalizadas e MFA obrigatório para todo acesso aos dados do titular do cartão
  • A tokenização elimina 80-90% do escopo do PCI, substituindo os números dos cartões por tokens não reversíveis
  • A seleção do SAQ determina sua carga de conformidade --- escolher o SAQ certo economiza meses de trabalho
  • Varreduras ASV trimestrais e testes de penetração anuais são requisitos não negociáveis

PCI-DSS v4.0: O que mudou

PCI-DSS v4.0, lançado em 2022 e totalmente obrigatório desde 31 de março de 2025, representa a atualização mais significativa do padrão em mais de uma década. As principais mudanças afetam todos os negócios de comércio eletrônico.

Principais mudanças na v4.0

AlterarImpactoPrazo
Abordagem personalizada permitidaAs empresas podem projetar controles alternativos que atendam aos objetivosAtivo agora
Análise de risco específicaFrequência baseada no risco para alguns controlos (por exemplo, revisões de registos)Ativo agora
Autenticação aprimoradaMFA necessário para TODOS os acessos ao CDE (não apenas remoto)Março 2025
Revisão automatizada de registrosMecanismos automatizados para detecção de anomalias em logs de auditoriaMarço 2025
Gerenciamento de roteirosMonitoramento de inventário e integridade de scripts de páginas de pagamentoMarço 2025
Prevenção de skimming no comércio eletrônicoMecanismos para detectar alterações não autorizadas nas páginas de pagamentoMarço 2025
Requisitos de senha direcionadaMínimo de 12 caracteres (ou 8 se o sistema não suportar 12)Março 2025
Criptografia do SAD antes da autorizaçãoOs dados de autenticação confidenciais devem ser criptografados se armazenados pré-autenticaçãoMarço 2025

O requisito de gerenciamento de script

O requisito 6.4.3 é particularmente impactante para o comércio eletrônico: você deve manter um inventário de todos os scripts nas páginas de pagamento e implementar um mecanismo para detectar alterações não autorizadas. Isso significa:

  • Cada arquivo JavaScript carregado na sua página de checkout deve ser documentado
  • Os cabeçalhos da Política de Segurança de Conteúdo (CSP) devem restringir as fontes de script
  • Hashes de integridade de sub-recursos (SRI) devem verificar o conteúdo do script
  • Um mecanismo de monitoramento deve alertar sobre alterações não autorizadas no script

Este requisito visa diretamente ataques de skimming no estilo Magecart, onde os invasores injetam scripts maliciosos em páginas de pagamento para roubar dados de cartões.


Compreendendo a tokenização

A tokenização é a tecnologia mais impactante para reduzir o escopo do PCI. Ele substitui os dados confidenciais do cartão por um token não confidencial que não terá valor explorável se violado.

Como funciona a tokenização

  1. O cliente insere os detalhes do cartão no formulário hospedado pelo provedor de pagamento (nunca no seu servidor)
  2. O provedor de pagamento cria um token representando o cartão
  3. Seu sistema armazena apenas o token (por exemplo, tok_1MqLkJLkdIwHu7ixUAuBjz5Y)
  4. Para cobranças subsequentes, você envia o token ao provedor de pagamento
  5. O provedor mapeia o token de volta aos detalhes reais do cartão e processa o pagamento

Tokenização vs. criptografia

AspectoTokenizaçãoCriptografia
ReversibilidadeNão reversível (o token é aleatório)Reversível com chave
Escopo PCIRemove sistemas do escopoOs sistemas permanecem no escopo
Gestão de chavesSem chaves para gerenciarÉ necessária gestão de chaves
DesempenhoBaseado em pesquisa, rápidoBaseado em computação, um pouco mais lento
Impacto da violaçãoOs tokens são inúteis para os invasoresOs dados criptografados são valiosos se a chave for comprometida

Implementação com as principais plataformas

Shopify: A tokenização é feita inteiramente pelo Shopify Payments. Os comerciantes nunca mexem nos dados do cartão. A conformidade com PCI é coberta pela certificação Nível 1 da Shopify. Você é responsável pelo SAQ-A.

Stripe: use o Stripe Elements ou o Stripe Checkout para garantir que os dados do cartão vão diretamente para os servidores do Stripe. Seu backend só recebe tokens. Isso qualifica você para SAQ-A ou SAQ-A-EP dependendo da implementação.

Integração de pagamento personalizado com Odoo: Se você estiver criando uma solução de comércio eletrônico personalizada no Odoo, integre-a a um gateway de pagamento compatível com PCI (Stripe, Adyen, Authorize.net) usando seus campos hospedados ou abordagem de redirecionamento. Nunca processe dados brutos do cartão em seu servidor Odoo.


Guia de seleção de SAQ

O Questionário de Autoavaliação (SAQ) que você deve preencher depende de como você lida com os dados do cartão. Escolher o SAQ certo --- e arquitetar seu fluxo de pagamento para se qualificar para um SAQ mais simples --- é a decisão de PCI mais importante que você tomará.

Guia de seleção do tipo SAQ

Tipo SAQPara quem se destinaNº de perguntasRequisitos
SAQ-ATotalmente terceirizado (página de pagamento hospedada/iframe)~25Os dados do cartão nunca chegam aos seus sistemas
SAQ-A-EPPagamento terceirizado, mas seu site controla a página~140Página de pagamento em seu domínio, dados enviados diretamente ao processador
SAQ-BSomente terminal impresso ou autônomo~40Sem armazenamento eletrônico de dados do titular do cartão
SAQ-B-IPTerminais PTS autônomos com conexão IP~80Terminal se conecta ao processador pela rede
SAQ-CAplicativo de pagamento conectado à internet~160Aplicativo processa cartões, mas não armazena dados
SAQ-C-VTTerminal virtual (entrada manual de chave, baseado na web)~80Uma transação por vez, sem armazenamento eletrônico
SAQ-DTodos os demais (armazenam, processam ou transmitem)~330É necessária avaliação PCI completa

Fluxo de decisão

Você redireciona os clientes para uma página de pagamento hospedada (Shopify Checkout, Stripe Checkout, PayPal)? Se sim, SAQ-A.

Você incorpora o formulário do provedor de pagamento em sua página (Stripe Elements, Braintree Hosted Fields)? Se sim, SAQ-A-EP. Sua página hospeda o formulário, mas os dados do cartão vão diretamente para o provedor.

Os dados do cartão chegam ao seu servidor, mesmo que temporariamente? Em caso afirmativo, SAQ-D. Esta é a avaliação completa e você deve considerar fortemente a re-arquitetura para se qualificar para o SAQ-A ou SAQ-A-EP.

Implicações de custos

Tipo SAQCusto anual típico de conformidadeNível de esforço
SAQ-AUS$ 2.000 - US$ 5.000Dias
SAQ-A-EPUS$ 10.000 - US$ 30.000Semanas
SAQ-CUS$ 20.000 - US$ 50.000Semanas a meses
SAQ-DUS$ 50.000 - US$ 300.000 +Meses

A decisão de arquitetura de usar formulários de pagamento hospedados em vez de processar você mesmo os dados do cartão pode economizar entre US$ 50.000 e US$ 250.000 anualmente em custos de conformidade.


3D Secure 2.0: mudança de responsabilidade e prevenção de fraudes

O 3D Secure 2.0 (3DS2) adiciona uma camada de autenticação às transações online com cartão. Quando devidamente implementado, transfere a responsabilidade por fraude do comerciante para o emissor do cartão.

Como funciona o 3DS2

  1. O cliente inicia o pagamento em seu site
  2. Seu provedor de pagamento envia dados de transação ao emissor do cartão
  3. O mecanismo de risco do emissor avalia a transação (impressão digital do dispositivo, histórico de transações, valor)
  4. Fluxo sem atrito: As transações de baixo risco são autenticadas silenciosamente (nenhuma ação do cliente é necessária)
  5. Fluxo de desafio: Transações de alto risco exigem autenticação adicional (biométrica, OTP, confirmação de aplicativo)
  6. O resultado da autenticação é retornado e o pagamento é processado

Benefícios 3DS2

  • Mudança de responsabilidade: Transferências de responsabilidade por fraude para o banco emissor para transações autenticadas
  • Fraude reduzida: 3DS2 reduz as taxas de fraude em 40-60% em comparação com transações não autenticadas
  • Melhor UX: Autenticação simples significa que 85-95% das transações não exigem nenhuma ação adicional do cliente
  • Conformidade regulatória: PSD2 Strong Customer Authentication (SCA) requer 3DS2 para transações na UE

Considerações de implementação

  • Habilite o 3DS2 através do seu provedor de pagamento (Stripe, Adyen e a maioria dos provedores oferecem suporte nativo)
  • Configurar limites de autenticação baseados em risco: aplique 3DS2 a transações de alto risco, isentando as de baixo valor ou baixo risco
  • Monitore as taxas de autenticação: se muitas transações forem contestadas, revise seus sinais de risco
  • Teste minuciosamente os fluxos sem atrito e de desafio antes de ir ao ar

Verificação de vulnerabilidades e testes de penetração

O PCI-DSS exige verificação automatizada de vulnerabilidades (trimestralmente) e testes de penetração manuais (anualmente) para todos os ambientes no escopo.

Verificações ASV trimestrais

Um fornecedor de verificação aprovado (ASV) deve realizar verificações de vulnerabilidades externas a cada trimestre. Requisitos:

  • As verificações devem abranger todos os endereços IP e domínios externos no ambiente de dados do titular do cartão (CDE).
  • Todas as vulnerabilidades de alta gravidade (CVSS 4.0+) devem ser corrigidas e verificadas novamente antes que a verificação seja aprovada
  • Os relatórios de verificação aprovados devem ser retidos para fins de auditoria
  • ASVs comuns: Qualys, Tenable, SecurityMetrics, Trustwave

Teste Anual de Penetração

O requisito 11.4 exige testes de penetração anuais de:

  • Controles de segmentação de rede (se usados para reduzir o escopo)
  • Perímetro externo do CDE
  • Sistemas internos dentro do CDE
  • Testes na camada de aplicativos de aplicativos de pagamento

Novidade na v4.0: O teste de penetração agora deve verificar explicitamente se os controles de segmentação estão funcionando e se o CDE está devidamente isolado do resto da rede.

Monitoramento Contínuo

Além dos testes trimestrais e anuais, o PCI-DSS v4.0 enfatiza o monitoramento contínuo:

  • Monitoramento de integridade de arquivos (FIM) em arquivos críticos do sistema e scripts de páginas de pagamento
  • Sistemas de detecção/prevenção de intrusão (IDS/IPS) nos limites da rede CDE
  • Revisão automatizada de logs para detecção de anomalias (novo requisito v4.0)
  • Alerta em tempo real para tentativas de acesso não autorizado

Construindo uma arquitetura de comércio eletrônico compatível com PCI

A abordagem mais eficaz para a conformidade com PCI é minimizar o escopo por meio de decisões de arquitetura.

Arquitetura recomendada

Nível 1: página de pagamento (escopo mínimo). Use campos de pagamento hospedados (Stripe Elements, Adyen Drop-in) incorporados em um iframe em sua página de checkout. Os dados do cartão fluem diretamente do navegador do cliente para o provedor de pagamento. Seu servidor nunca vê isso.

Nível 2: Servidor de aplicativos (fora do escopo). Seu aplicativo de comércio eletrônico (Shopify, Odoo, personalizado) lida com gerenciamento de pedidos, estoque e dados de clientes. Ele se comunica com o provedor de pagamento apenas por meio de tokens.

Nível 3: Armazenamento de dados (fora do escopo dos dados do cartão). Seu banco de dados armazena detalhes de pedidos, informações de clientes e tokens de pagamento --- mas nunca números de cartão, CVVs ou datas de vencimento.

Segmentação de rede

Se alguma parte da sua infraestrutura processa dados de cartão, a segmentação da rede é crítica:

  • Isole o CDE em um segmento de rede separado (VLAN, sub-rede ou VPC)
  • Implementar regras de firewall que restrinjam o tráfego de e para o CDE
  • Monitore todo o tráfego que cruza o limite de segmentação
  • Teste controles de segmentação durante testes de penetração

Para obter orientações abrangentes sobre arquitetura de conformidade que vão além do PCI-DSS, consulte nosso manual de conformidade empresarial.


Perguntas frequentes

Preciso de conformidade com PCI se vender apenas no Shopify?

Sim, mas seu escopo é mínimo. Shopify é um provedor de serviços certificado PCI-DSS Nível 1, o que significa que Shopify cuida do trabalho pesado. No entanto, você ainda é responsável por preencher o SAQ-A anualmente e manter práticas básicas de segurança: senhas fortes, MFA no admin da Shopify, não armazenar dados de cartão fora da Shopify e treinar a equipe em segurança.

O que acontece se minha verificação ASV trimestral falhar?

Você tem a oportunidade de corrigir as vulnerabilidades identificadas e solicitar uma nova verificação. Não há penalidade por uma verificação com falha – apenas por não ter uma verificação aprovada dentro da janela trimestral. No entanto, se você falhar consistentemente nas verificações e não conseguir demonstrar conformidade, seu banco adquirente poderá aumentar suas taxas de processamento, exigir uma avaliação mais rigorosa ou, em casos extremos, encerrar sua conta de comerciante.

A conformidade com PCI é exigida por lei?

PCI-DSS não é uma regulamentação governamental – é uma exigência contratual das bandeiras de cartão (Visa, Mastercard, American Express, Discover, JCB). A conformidade é aplicada por meio de seu contrato comercial com o banco adquirente. O não cumprimento pode resultar em multas das bandeiras de cartão (US$ 5.000 a US$ 100.000/mês), aumento de taxas de transação e responsabilidade por transações fraudulentas. Algumas jurisdições (Nevada, Minnesota, Washington) promulgaram leis que incorporam os requisitos do PCI-DSS.

Como o PCI-DSS se relaciona com o GDPR?

O PCI-DSS e o GDPR se sobrepõem em áreas como controle de acesso, criptografia e resposta a incidentes, mas têm focos diferentes. O PCI-DSS protege especificamente os dados dos cartões de pagamento, enquanto o GDPR protege todos os dados pessoais dos residentes da UE. O número do cartão de pagamento também é um dado pessoal de acordo com o GDPR, portanto, você precisa cumprir ambos. Consulte nosso guia de comparação de privacidade de dados para saber mais sobre como diferentes regulamentações interagem.


O que vem a seguir

A conformidade com PCI-DSS não é opcional para qualquer empresa que aceite pagamentos com cartão. A boa notícia é que as plataformas de pagamento modernas tornaram tudo muito mais fácil, lidando com os aspectos mais sensíveis do processamento de dados de cartão em seu nome. Seu trabalho é escolher a arquitetura certa, preencher o SAQ apropriado, manter práticas de segurança contínuas e manter-se atualizado à medida que o padrão evolui.

ECOSIRE ajuda empresas de comércio eletrônico a construir arquiteturas de pagamento compatíveis com PCI desde o início. Nossas implementações do Shopify aproveitam a certificação Nível 1 do Shopify para escopo mínimo de PCI, e nossas integrações Odoo ERP usam fluxos de pagamento tokenizados que mantêm seus sistemas fora do escopo do PCI. Entre em contato conosco para uma avaliação de segurança de pagamento.


Publicado por ECOSIRE — ajudando empresas a escalar com soluções baseadas em IA em Odoo ERP, Shopify eCommerce e OpenClaw AI.

E

Escrito por

ECOSIRE Team

Redação técnica

A equipe de redação técnica da ECOSIRE escreve sobre Odoo ERP, e-commerce com Shopify, agentes de IA, análise de dados com Power BI, automação com GoHighLevel e boas práticas de software empresarial. Nossos guias ajudam as empresas a tomar decisões de tecnologia bem fundamentadas.

ECOSIRE

Amplie sua loja Shopify

Serviços personalizados de desenvolvimento, otimização e migração para comércio eletrônico de alto crescimento.

Mais de Conformidade e regulamentação

Cibersegurança para comércio eletrônico: proteja sua empresa em 2026

Guia completo de segurança cibernética de comércio eletrônico para 2026. PCI DSS 4.0, configuração WAF, proteção de bot, prevenção de fraudes em pagamentos, cabeçalhos de segurança e resposta a incidentes.

ERP para Indústria Química: Segurança, Conformidade e Processamento em Lote

Como os sistemas ERP gerenciam documentos SDS, conformidade com REACH e GHS, processamento em lote, controle de qualidade, envio de materiais perigosos e gerenciamento de fórmulas para empresas químicas.

ERP para comércio de importação/exportação: multimoedas, logística e conformidade

Como os sistemas ERP lidam com cartas de crédito, documentação alfandegária, incoterms, lucros e perdas em várias moedas, rastreamento de contêineres e cálculo de taxas para empresas comerciais.

Relatórios de Sustentabilidade e ESG com ERP: Guia de Conformidade 2026

Navegue pela conformidade dos relatórios ESG em 2026 com sistemas ERP. Abrange emissões CSRD, GRI, SASB, escopo 1/2/3, rastreamento de carbono e sustentabilidade Odoo.

Lista de verificação de preparação para auditoria: preparando seus livros

Lista de verificação completa para preparação de auditoria, cobrindo a preparação das demonstrações financeiras, documentação de suporte, documentação de controles internos, listas de PBC de auditores e descobertas comuns de auditoria.

Guia GST australiano para empresas de comércio eletrônico

Guia completo de GST australiano para empresas de comércio eletrônico, cobrindo registro ATO, limite de US$ 75.000, importações de baixo valor, apresentação de BAS e GST para serviços digitais.