tech stack

Passarel·la de pagament detectada

MetricSpot detecta passarel·les de pagament a la pàgina (Stripe, PayPal, Adyen, Braintree, Square, Mollie, Razorpay, Paddle, Lemon Squeezy). Si hi ha checkout, les teves capçaleres de seguretat porten exponencialment més pes.

Què comprova aquesta auditoria

Escaneja la pàgina buscant empremtes de passarel·les de pagament, fonts d’scripts, orígens d’iframe, globals JS, i reporta quina passarel·la (si n’hi ha cap) gestiona el checkout. És informativa. Però la seva presència eleva les apostes en cada comprovació de seguretat d’altres llocs de l’auditoria.

Per què importa

Si detectem una passarel·la de pagament, estàs prenent dades de targeta a la sessió de l’usuari. Això et posa dins de l’abast PCI DSS, i en llocs de jurisdicció PSD2 dins l’abast d’Strong Customer Authentication. Les comprovacions següents passen de ser “interessants” a “no negociables”:

  • HTTPS al teu lloc, PCI DSS 4.2.1 requereix TLS per a qualsevol pàgina implicada en la transmissió de dades de targeta.
  • Activar HSTS, prevé els atacs de downgrade que eliminen TLS de les submissions de checkout.
  • Atributs de cookies segures, Secure; HttpOnly; SameSite=Lax a cookies de sessió bloca el robatori de tokens via XSS i CSRF.
  • Protecció clickjacking, X-Frame-Options / CSP frame-ancestors impedeixen que els atacants emmarquin el teu checkout dins el seu domini per robar clics.

En un lloc de màrqueting, capçaleres de seguretat febles són mal format. En un lloc que pren pagaments, són una bretxa esperant a passar i una responsabilitat d’auditoria.

Com solucionar-ho

Aquesta comprovació és informativa, així que l’acció depèn del que s’hagi detectat.

Heurístiques de detecció, per a referència. MetricSpot empremta:

  • 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.

Tria un mode d’integració que redueixi l’abast PCI. Totes les passarel·les importants ofereixen tres integracions de checkout, en ordre de més a menys abast PCI:

  1. API directa (dades de targeta crues enviades al teu servidor), PCI DSS SAQ D, ~300 controls. Evita-ho tret que tinguis un equip de compliment.
  2. Camps embeguts (Stripe Elements, Braintree Hosted Fields, Adyen Components), els camps de targeta s’iframegen des de la passarel·la; el teu servidor mai toca el PAN. PCI DSS SAQ A-EP, ~140 controls.
  3. Redirecció / Hosted Checkout (Stripe Checkout, PayPal Smart Buttons, Paddle, Lemon Squeezy), l’usuari és redirigit a una pàgina allotjada per la passarel·la. PCI DSS SAQ A, ~20 controls.

Per a la majoria de llocs SaaS i ecommerce, hosted checkout és el defecte correcte. Paddle i Lemon Squeezy van més enllà actuant com a Merchant of Record, gestionen IVA de la UE, sales tax dels EUA i chargebacks. Cedeixes uns punts percentuals de marge i recuperes setmanes de feina de compliment.

Strong Customer Authentication (3DS). Si vens a clients UE/RU i utilitzes API directa o integracions embegudes, has de disparar 3D Secure en transaccions que no tinguin una exempció reconeguda. Stripe, Adyen i Braintree exposen flags setup_future_usage / authentication_required. Prova amb les targetes de repte 3DS de la banda emissora a la sandbox de cada passarel·la abans del llançament.

Conjunt mínim de capçaleres de seguretat per a qualsevol pàgina que inclogui una passarel·la de pagament:

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

Consulta activar HSTS, protecció clickjacking, referrer policy i atributs de cookies segures per al detall de cadascun.

Preguntes freqüents

Utilitzem Stripe Checkout (hosted). PCI encara aplica?

Sí, però al menor abast (SAQ A). T’autoavalues anualment que el teu lloc només inclou codi de redirecció/iframe controlat per Stripe, que els teus servidors mai veuen dades de targeta i que el teu lloc se serveix per TLS amb xifrats actuals. Stripe proporciona una plantilla SAQ A pre-omplerta. Hosted checkout no elimina PCI; el fa prou petit perquè càpiga en una sola pàgina.

Per què MetricSpot marca una passarel·la de pagament en una pàgina sense checkout evident?

Dos casos habituals: una pàgina de preus que carrega js.stripe.com per a un botó “Compra ara”, o un widget de footer “Dona via PayPal”. L’script es carrega a tot el lloc encara que el checkout només passi en una ruta. Això encara és dins l’abast, qualsevol pàgina que carregui codi SDK de pagament està dins l’abast PCI per a aquella pàgina. Carrega l’SDK de forma lazy només a la ruta de checkout per reduir l’abast.

Apple Pay o Google Pay canvien els requisits?

Redueixen la fricció, no els requisits. Els tokens d’Apple Pay i Google Pay flueixen a través de la teva passarel·la existent (Stripe, Adyen, Braintree), i el teu abast PCI es manté al tier SAQ que dicti el teu mode d’integració. SCA es compleix automàticament perquè el wallet en si és un factor d’autenticació fort, Visa i Mastercard ho tracten com una exempció d’autenticació delegada.

Fonts

Última actualització 2026-05-11