Pasarela de pago detectada

Qué comprueba esta verificación

Escanea la página en busca de huellas de pasarela — sources de script, orígenes de iframe, globales de JS — y reporta qué pasarela (si alguna) maneja el checkout. Es informativa. Pero su presencia eleva la apuesta sobre cada comprobación de seguridad del resto de la auditoría.

Por qué importa

Si detectamos una pasarela, estás cogiendo datos de tarjeta en la sesión del usuario. Eso te mete en el ámbito de PCI DSS y, en jurisdicciones bajo PSD2, en el ámbito de Strong Customer Authentication. Las siguientes comprobaciones pasan de nice-to-have a no negociables:

• HTTPS en tu sitio — PCI DSS 4.2.1 exige TLS en cualquier página implicada en la transmisión de datos de tarjeta.
• Activar HSTS — evita los downgrade attacks que arrancan TLS de los envíos de checkout.
• Atributos de cookies seguras — Secure; HttpOnly; SameSite=Lax sobre cookies de sesión bloquea el robo de tokens vía XSS y CSRF.
• Protección clickjacking — X-Frame-Options / CSP frame-ancestors evita que un atacante meta tu checkout en un frame de su dominio para robar clics.

En un sitio de marketing, las cabeceras de seguridad débiles son mala forma. En un sitio que cobra, son una brecha esperando a ocurrir y una papeleta de auditoría.

Cómo arreglarlo

Esta comprobación es informativa, así que la acción depende de lo detectado.

Heurísticas de detección, para referencia. MetricSpot huellea:

• Stripe — <script src="https://js.stripe.com/v3/">, window.Stripe, iframes desde js.stripe.com.
• PayPal — <script src="https://www.paypal.com/sdk/js">, data-paypal-button, paypal.Buttons.
• Adyen — src del script 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.

Elige un modo de integración que reduzca el alcance PCI. Todas las grandes pasarelas ofrecen tres integraciones de checkout, en orden del mayor al menor alcance PCI:

1. API directa (datos de tarjeta enviados en crudo a tu servidor) — PCI DSS SAQ D, ~300 controles. Evita salvo que tengas equipo de compliance.
2. Campos embebidos (Stripe Elements, Braintree Hosted Fields, Adyen Components) — los campos de tarjeta van iframed desde la pasarela; tu servidor nunca toca el PAN. PCI DSS SAQ A-EP, ~140 controles.
3. Redirección / Hosted Checkout (Stripe Checkout, PayPal Smart Buttons, Paddle, Lemon Squeezy) — el usuario se redirige a una página alojada por la pasarela. PCI DSS SAQ A, ~20 controles.

Para la mayoría de SaaS y tiendas, el hosted checkout es el default correcto. Paddle y Lemon Squeezy van más allá actuando como Merchant of Record — manejan IVA UE, sales tax de EE. UU. y chargebacks. Cedes unos puntos porcentuales de margen y recuperas semanas de trabajo de compliance.

Strong Customer Authentication (3DS). Si vendes a clientes UE/UK y usas API directa o integraciones embebidas, debes disparar 3D Secure en transacciones sin exención reconocida. Stripe, Adyen y Braintree exponen flags setup_future_usage / authentication_required. Prueba con las tarjetas de challenge 3DS del lado emisor en cada sandbox antes del lanzamiento.

Conjunto mínimo de cabeceras de seguridad para cualquier página que incluya una pasarela:

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

Ver activar HSTS, protección clickjacking, cabecera referrer-policy y atributos de cookies seguras para cada uno en detalle.

Preguntas frecuentes

Usamos Stripe Checkout (hosted). ¿Sigue aplicando PCI?

Sí — pero en el alcance más bajo (SAQ A). Te autocertificas anualmente de que tu sitio solo incluye código de redirección/iframe controlado por Stripe, que tus servidores nunca ven datos de tarjeta y que tu sitio se sirve por TLS con cifrados actuales. Stripe da una plantilla pre-rellenada de SAQ A. El hosted checkout no elimina PCI; lo hace lo bastante pequeño para caber en una sola página.

¿Por qué MetricSpot marca una pasarela en una página sin checkout evidente?

Dos casos comunes: una página de precios que carga js.stripe.com para un botón “Comprar ya”, o un widget de footer “Dona vía PayPal”. El script se carga en todo el sitio aunque el checkout solo ocurra en una ruta. Eso sigue estando en el ámbito — cualquier página que cargue código de SDK de pago entra en el ámbito PCI para esa página. Carga el SDK de forma lazy solo en la ruta de checkout para reducir el alcance.

¿Cambian las exigencias Apple Pay o Google Pay?

Reducen la fricción, no las exigencias. Los tokens de Apple Pay y Google Pay fluyen por tu pasarela existente (Stripe, Adyen, Braintree) y tu alcance PCI se queda en el SAQ que dicte tu modo de integración. SCA se cumple automáticamente porque el propio wallet es un factor de autenticación fuerte — Visa y Mastercard lo tratan como una exención de autenticación delegada.