Processador de pagamentos detetado

O que esta verificação faz

Analisa a página em busca de fingerprints de processadores de pagamento — fontes de script, origens de iframe, globais JS — e reporta qual processador (se algum) trata o checkout. Isto é informativo. Mas a sua presença aumenta os riscos em cada verificação de segurança noutro ponto da auditoria.

Porque é importante

Se detetamos um processador de pagamento, estás a receber dados de cartão na sessão do utilizador. Isso coloca-te no âmbito do PCI DSS, e em sites de jurisdição PSD2 no âmbito de Strong Customer Authentication. As verificações seguintes tornam-se não-negociáveis em vez de bom-de-ter:

• HTTPS no teu site — o PCI DSS 4.2.1 exige TLS para qualquer página envolvida em transmissão de dados de cartão.
• Ativar HSTS — previne os ataques de downgrade que retiram o TLS de submissões de checkout.
• Atributos de cookies seguros — Secure; HttpOnly; SameSite=Lax em cookies de sessão bloqueia roubo de tokens via XSS e CSRF.
• Proteção contra clickjacking — X-Frame-Options / CSP frame-ancestors impedem atacantes de envolver o teu checkout dentro do seu domínio para roubar cliques.

Num site de marketing, cabeçalhos de segurança fracos são má forma. Num site que recebe pagamentos, são uma brecha à espera de acontecer e uma responsabilidade de auditoria.

Como corrigir

Esta verificação é informativa, pelo que a ação depende do que foi detetado.

Heurísticas de deteção, para referência. O MetricSpot faz fingerprinting a:

• Stripe — <script src="https://js.stripe.com/v3/">, window.Stripe, iframes de js.stripe.com.
• PayPal — <script src="https://www.paypal.com/sdk/js">, data-paypal-button, paypal.Buttons.
• Adyen — script src checkoutshopper-live.adyen.com, window.AdyenCheckout.
• Braintree — js.braintreegateway.com, window.braintree.
• Square — web.squarecdn.com, Square.payments.
• Mollie — js.mollie.com, Mollie(profileId).
• Razorpay — checkout.razorpay.com, window.Razorpay.
• Paddle — cdn.paddle.com, Paddle.Setup.
• Lemon Squeezy — app.lemonsqueezy.com, LemonSqueezy.Setup.

Escolhe um modo de integração que reduza o âmbito PCI. Todos os processadores grandes oferecem três integrações de checkout, por ordem do maior âmbito PCI para o menor:

1. API direta (dados de cartão crus enviados para o teu servidor) — PCI DSS SAQ D, ~300 controlos. Evita a menos que tenhas uma equipa de conformidade.
2. Campos embebidos (Stripe Elements, Braintree Hosted Fields, Adyen Components) — os campos de cartão são iframed pelo processador; o teu servidor nunca toca no PAN. PCI DSS SAQ A-EP, ~140 controlos.
3. Redirecionamento / Hosted Checkout (Stripe Checkout, PayPal Smart Buttons, Paddle, Lemon Squeezy) — o utilizador é redirecionado para uma página alojada pelo processador. PCI DSS SAQ A, ~20 controlos.

Para a maioria dos sites SaaS e ecommerce, hosted checkout é o default certo. O Paddle e o Lemon Squeezy vão mais longe ao atuar como Merchant of Record — tratam do IVA UE, imposto sobre vendas dos EUA e chargebacks. Cedes alguns pontos percentuais de margem e recuperas semanas de trabalho de conformidade.

Strong Customer Authentication (3DS). Se vendes a clientes UE/UK e usas API direta ou integrações embebidas, tens de disparar 3D Secure em transações que não tenham uma exceção reconhecida. Stripe, Adyen e Braintree expõem flags setup_future_usage / authentication_required. Testa com os cartões de challenge 3DS do lado do emissor nos sandboxes de cada processador antes de lançar.

Conjunto mínimo de cabeçalhos de segurança para qualquer página que inclua um processador de pagamento:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'; ...
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax

Vê ativar HSTS, proteção contra clickjacking, cabeçalho Referrer-Policy e atributos de cookies seguros para cada um em detalhe.

Perguntas frequentes

Usamos Stripe Checkout (hosted). O PCI ainda se aplica?

Sim — mas no âmbito mais baixo (SAQ A). Auto-atestas anualmente que o teu site só inclui código de redirecionamento/iframe controlado pela Stripe, que os teus servidores nunca veem dados de cartão e que o teu site é servido sobre TLS com cifras atuais. A Stripe fornece um template SAQ A pré-preenchido. O hosted checkout não remove o PCI; torna-o pequeno o suficiente para caber numa única página.

Porque é que o MetricSpot assinala um processador de pagamento numa página sem checkout óbvio?

Dois casos comuns: uma página de preços que carrega js.stripe.com para um botão “Comprar agora”, ou um widget de rodapé “Donativo via PayPal”. O script é carregado em todo o site mesmo que o checkout só aconteça numa rota. Isso continua em âmbito — qualquer página que carregue código de SDK de pagamentos está em âmbito PCI para essa página. Carrega o SDK em lazy-load apenas na rota de checkout para reduzir o âmbito.

Apple Pay ou Google Pay mudam os requisitos?

Reduzem fricção, não requisitos. Os tokens Apple Pay e Google Pay fluem pelo teu processador existente (Stripe, Adyen, Braintree), e o teu âmbito PCI fica no nível SAQ que o teu modo de integração dita. O SCA fica automaticamente satisfeito porque a própria wallet é um fator de autenticação forte — Visa e Mastercard tratam-no como exceção de autenticação delegada.