Segurança de pagamentos na sua loja online: PCI, card testing e o que o seu fornecedor de alojamento faz
Quem recebe pagamentos online tem de lidar com as regras de segurança das empresas de cartões (PCI DSS), com criminosos que querem roubar dados de cartões e com card testing: testar cartões roubados na sua loja. Este artigo explica o que isso significa para uma pequena loja online, o que o próprio comerciante faz e o que o seu alojador trata e não trata por si.
A regra principal: os dados do cartão nunca entram na sua loja
Um número de cartão, a data de validade e o código de segurança são introduzidos pelo cliente no seu fornecedor de pagamentos, nunca na sua própria loja. A sua loja apenas recebe a informação de que o pagamento foi efetuado. Isto significa também:
- nunca ter um campo de formulário próprio para números de cartão, nem sequer para uma encomenda por telefone;
- nunca aceitar dados de cartões por email, chat ou telefone e guardá-los numa nota associada a uma encomenda;
- não utilizar nenhum plugin que guarde dados de cartões na sua própria base de dados.
PCI DSS e SAQ A em linguagem simples
O PCI DSS (Payment Card Industry Data Security Standard) é a norma de segurança das empresas de cartões; a versão atual é a v4.0.1. Uma empresa que processa diretamente dados de cartões fica sujeita a um conjunto alargado de requisitos. Uma pequena loja que terceiriza totalmente o pagamento comprova a conformidade através de um questionário simplificado: o SAQ A (Self-Assessment Questionnaire A). O seu fornecedor de pagamentos pode solicitá-lo.
A terceirização pode ser feita de duas formas:
- Redirecionamento: após finalizar a encomenda, o cliente é encaminhado para a página de pagamento do fornecedor e depois regressa à loja.
- Um campo de pagamento incorporado: o campo de pagamento está na sua página de checkout, mas é um elemento de página (iframe) do fornecedor.
Desde 31 de março de 2025 está em vigor uma nova versão do SAQ A. Quem utiliza um campo de pagamento incorporado tem de confirmar que o seu site não é vulnerável a ataques através de scripts que possam afetar o pagamento. Quem utiliza redirecionamento não está sujeito a essa condição. Pergunte ao seu fornecedor de pagamentos qual o questionário aplicável à sua integração.
Proteger a página de checkout
- Mantenha a página de checkout simples. Em princípio, qualquer script presente nessa página pode ler o que o cliente introduz (e-skimming): widgets de chat, gestores de tags, pixels publicitários. Carregue apenas o que é necessário para o pagamento.
- Poucos plugins, sempre atualizados. Os scripts maliciosos entram normalmente através de uma vulnerabilidade num plugin ou de uma palavra-passe de administrador roubada.
- https em todo o site, com redirecionamento de http para https e HSTS. Consulte Redirecionar obrigatoriamente os visitantes para https e HSTS e cabeçalhos de segurança para o seu site.
Reconhecer e limitar o card testing
No card testing, os criminosos colocam automaticamente muitas pequenas encomendas para verificar quais os cartões roubados que funcionam. Reconhece-se isto por um grande número de encomendas num curto espaço de tempo, muitas vezes do mesmo produto barato, com nomes diferentes e muitas encomendas com o estado Falhou. Isto gera custos de transação e estornos e, no pior dos casos, o seu fornecedor de pagamentos pode bloquear a sua conta.
- Rate limiting (um limite ao número de pedidos por período de tempo). O WooCommerce tem esta funcionalidade incorporada para os blocos de checkout, mas está desativada por predefinição. Ative-a em WooCommerce > Definições > Avançado > Funcionalidades, opção Rate limiting Checkout block and Store API.
- Um captcha no checkout. Os atacantes mudam frequentemente de endereço IP; a combinação de rate limiting com captcha funciona melhor.
- Os filtros antifraude do seu fornecedor de pagamentos. Ative-os e verifique o que reportam.
- 3-D Secure, a confirmação adicional na aplicação do banco, dificulta a utilização indevida de cartões roubados.
O que o seu alojador trata, e o que não trata
Tratado pela WebOké:
- Um certificado Let's Encrypt gratuito para https
- O HSTS está ativado por predefinição na maioria dos servidores
- A Web Application Firewall está ativada por predefinição e bloqueia ataques conhecidos
- O Imunify360 verifica os novos ficheiros imediatamente em busca de malware e analisa o seu pacote regularmente
- Uma cópia de segurança de todo o seu pacote todas as noites, guardada durante 30 dias, num centro de dados diferente
Fica ao seu cuidado (ou ao do seu criador de sites):
- Atualizar o WordPress, o WooCommerce, o tema e os plugins (o Installatron pode fazer isto automaticamente, consulte Atualizações e atualizações automáticas)
- A integração e as definições antifraude junto do seu fornecedor de pagamentos
- Quais os scripts presentes na sua página de checkout
- Palavras-passe fortes e autenticação em dois passos para administradores
- Rate limiting, captcha e a verificação de encomendas suspeitas
O software que instala por sua conta, mesmo através do Installatron, é da sua responsabilidade. Se, ainda assim, o seu site for atacado, siga o plano de ação O meu site foi pirateado: plano de ação. Se uma invasão afetar dados pessoais de clientes, consulte também Isto é uma violação de dados e tenho de a comunicar?
Saber mais
- Curso gratuito Seguro online, lição 4.2 O seu site: https, HSTS e cabeçalhos de segurança
- PCI Security Standards Council sobre o SAQ A (em inglês)
- WooCommerce sobre card testing e rate limiting (em inglês)
Quer saber mais? Siga o curso gratuito Uma loja online com WooCommerce, lição 6.3 Segurança dos pagamentos: PCI e fraude.