// artigo · pagamentos
Preciso de PCI-DSS para aceitar cartão no meu site?
A resposta curta: você não escapa do PCI-DSS, mas, se fizer a integração do jeito certo, cai no nível mais simples — um autoquestionário, não uma certificação cara. O que define isso é se o cartão toca (ou não) o seu servidor.
Resposta direta
Todo mundo que aceita cartão está sujeito ao PCI-DSS (o padrão de segurança da indústria de cartões). A pergunta certa não é "preciso?", e sim "qual é o meu nível de esforço?" — e isso depende de uma única decisão técnica: o número do cartão passa pelo seu servidor ou não?
Se você usa um gateway (Mercado Pago, Stripe, PagSeguro…) que captura o cartão de forma tokenizada, o dado vai direto para ele e nunca toca o seu servidor. Nesse caso, você fica no SAQ A — o questionário mais simples. Se o cartão passa pelo seu código, o escopo explode.
O que é PCI-DSS, sem juridiquês
PCI-DSS (Payment Card Industry Data Security Standard) é um conjunto de regras criado pelas bandeiras (Visa, Mastercard e cia.) para proteger os dados de cartão. Ele não é uma lei, mas é exigido por contrato pelos adquirentes e gateways — quem não cumpre fica sujeito a multas e ao descredenciamento.
A boa notícia: quanto menos você encostar no dado do cartão, menos o padrão exige de você. É por isso que a arquitetura da sua integração importa tanto quanto qualquer documento.
Os níveis de autoavaliação (SAQ)
Para a maioria dos pequenos e médios negócios, a conformidade é feita por um SAQ (Self-Assessment Questionnaire), um autoquestionário. Qual deles depende de como você captura o cartão:
| Cenário | SAQ | Esforço |
|---|---|---|
| Pagamento 100% no provedor (redirect ou tokenização no navegador) | SAQ A | Baixo — poucas perguntas |
| Página sua, mas o campo de cartão vem do provedor (iframe/JS) e você controla a página | SAQ A-EP | Médio |
| O cartão passa pelo seu servidor | SAQ D | Alto — centenas de requisitos |
O salto de esforço entre o SAQ A e o SAQ D é enorme. Praticamente todo o trabalho de uma boa integração é manter você no SAQ A (ou A-EP).
A chave de tudo: tokenização
Tokenizar significa trocar o número do cartão por um token — um código sem valor para um ladrão — ainda no navegador do cliente, antes de qualquer coisa chegar ao seu backend. O cartão real vai direto para o gateway; o seu sistema só vê e guarda o token.
Com a tokenização feita no lado do cliente, o dado sensível nunca trafega nem é armazenado por você. É isso que te mantém no SAQ A — tanto no Checkout Pro quanto no Transparente.
O que você ainda precisa garantir (mesmo no SAQ A)
Escopo menor não é escopo zero. Mesmo sem o cartão tocar o seu servidor, você ainda deve:
- Servir todo o checkout sob HTTPS, sem exceção;
- Nunca logar, imprimir ou salvar número de cartão, CVV ou validade — nem em log de erro;
- Manter o site e as dependências atualizados (o SAQ A cobra controles básicos de segurança da sua página);
- Usar apenas scripts de pagamento do próprio provedor, de origem confiável;
- Preencher e manter o SAQ A junto ao seu adquirente/gateway.
Erros que aumentam seu escopo sem você perceber
- Guardar o número do cartão "para facilitar a recompra" — guarde o token, nunca o cartão (PAN).
- Receber o cartão no seu backend para "só repassar" ao gateway — isso já te joga no SAQ D.
- Capturar CVV em campo próprio e enviá-lo pelo seu servidor.
- Logar o corpo das requisições de pagamento sem mascarar os dados.
Qualquer um desses transforma um projeto simples (SAQ A) em um projeto de compliance caro (SAQ D). O barato sai caríssimo.
Como a Mantis faz
Numa integração de pagamentos, a gente desenha o fluxo para manter o cartão fora do seu servidor (tokenização correta), confirma o pagamento por webhook e deixa você no menor escopo possível de PCI-DSS — sem CVV no seu backend, sem PAN no banco, sem susto na auditoria. No sistema que você já tem.
Perguntas frequentes
Preciso de certificação PCI-DSS para aceitar cartão no meu site?
Depende de como o cartão é capturado. Se você usa um gateway que tokeniza os dados no navegador (o cartão nunca toca o seu servidor), você fica no SAQ A — um autoquestionário simples, não uma certificação pesada. Se os dados passam pelo seu servidor, o escopo cresce muito.
O que é o SAQ A?
É o questionário de autoavaliação mais simples do PCI-DSS, para quem terceiriza totalmente a captura e o processamento do cartão a um provedor validado, sem armazenar, processar ou transmitir dados de cartão nos próprios sistemas.
A tokenização elimina a necessidade de PCI-DSS?
Não elimina, mas reduz drasticamente o seu escopo. Com a tokenização no lado do cliente, o dado do cartão vai direto para o provedor e você lida apenas com um token — o que normalmente te coloca no SAQ A.
Posso guardar o número do cartão para cobranças futuras?
Guardar o número do cartão (PAN) aumenta enormemente o escopo e o risco. O correto é guardar o token que o provedor devolve e usar esse token para as próximas cobranças, sem nunca armazenar o cartão real.