Fora do escopo PCI-DSS: dados de cartão nunca tocam seu servidor

Você administra um restaurante de 18 mesas no Porto e quer que os clientes paguem por cartão direto do menu QR. No momento em que um PAN bruto toca seu servidor, você cai no escopo PCI-DSS SAQ-D — pen-tests, scans ASV, auditorias de segmentação, facilmente 8.000 EUR+ por ano. Com a arquitetura certa, esse custo é zero.

SAQ-A vs SAQ-D

SAQ-A é a auto-avaliação PCI-DSS mais leve — 22 perguntas sim/não para comerciantes que terceirizam totalmente os dados de cartão. Custo jurídico: 0 EUR.

SAQ-D aplica-se assim que dados de cartão tocam seus sistemas — memória, logs, variáveis temporárias. Conte com 8.000-15.000 EUR de conformidade anual.

O padrão Stripe Elements

Stripe.js Elements renderiza o campo do cartão num iframe servido por js.stripe.com. PAN, CVV e validade nunca compartilham origem com sua aplicação — seu JavaScript não consegue lê-los.

• Cliente digita o cartão → fica no iframe da Stripe
• Frontend chama stripe.confirmCardPayment(secret)
• Seu servidor só vê o token (pi_xxx)

thMenu faz isso por padrão

O plano Platinum do thMenu traz Stripe Elements de fábrica. Não há opção para "enviar cartão ao servidor" porque o código backend nunca referencia um PAN. 3D Secure 2.0 e SCA PSD2 são processados do lado da Stripe.

Para um restaurante português, isso significa zero conversas adicionais com a CNPD sobre retenção de cartão — basta apresentar o SAQ-A preenchido ao seu adquirente.

FAQ

SAQ-A requer auditoria anual? Não, é uma auto-avaliação que preenche e declara ao adquirente todos os anos.

Webhooks da Stripe me devolvem ao escopo? Não. O payload contém apenas últimos 4 dígitos, bandeira e validade.

E pedidos por telefone? Se a equipa digitar o cartão, passa para SAQ-D. Use Stripe Terminal ou Payment Links.

Achou útil? Compartilhe.