Seguridad en los pagos: PCI y fraude

Módulo 6: Gestión y seguridad · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Después de esta lección podrá explicar por qué una tienda nunca trata por sí misma los datos de tarjeta, qué significan PCI DSS y SAQ A para una tienda pequeña, cómo se protege la página de pago y cómo reconocer y limitar el fraude y el card testing.

Conceptos clave: PCI DSS, datos de tarjeta, proveedor de pago, redirección a la página de pago, formulario de pago integrado (iframe), SAQ A, scripts en la página de pago, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, contracargo (chargeback), riesgo de fraude

Los datos de tarjeta no deben estar en su tienda

Un número de tarjeta de crédito, la fecha de caducidad y el código de seguridad valen oro para los delincuentes. Quien los almacena o los transmite queda sujeto a PCI DSS (Payment Card Industry Data Security Standard), la norma de seguridad de las marcas de tarjetas. La versión actual es la v4.0.1. Para una empresa que trata por sí misma los datos de tarjeta, eso supone un buen paquete de requisitos: separación de redes, registros, escaneos y pruebas realizadas por una entidad acreditada.

Una tienda pequeña no quiere meterse en eso, y tampoco lo necesita. La regla fija es: los datos de tarjeta nunca entran en su tienda. El cliente los introduce en la página de su proveedor de pago (Mollie, Stripe, PayPal, WooPayments u otro, lección 4.4). Después, la tienda solo recibe el resultado: pagado o no, con una referencia. Ni número de tarjeta ni código. Esto también significa:

• no crear nunca un campo de formulario propio para números de tarjeta, ni siquiera "un momento para un pedido por teléfono";
• no aceptar nunca datos de tarjeta por correo, chat o teléfono para anotarlos en una nota del pedido;
• no usar ningún plugin que guarde datos de tarjeta en su propia base de datos.

Redirección o formulario integrado: SAQ A

Las tiendas pequeñas demuestran con un SAQ (Self-Assessment Questionnaire, un cuestionario de autoevaluación) que cumplen PCI DSS. Su proveedor de pago a veces lo solicita. El más ligero es el SAQ A, para tiendas que externalizan por completo el pago. En una tienda esto puede funcionar de dos maneras:

1. Redirección. Tras pulsar "Realizar el pedido", el cliente va a la página de pago del proveedor y después vuelve. La tienda nunca ve los datos de tarjeta, ni tampoco la página en la que se introducen.
2. Formulario integrado. El campo de pago está en su página de pago, pero es un iframe (un fragmento de página) del proveedor. Los datos de tarjeta van directamente del navegador al proveedor.

Desde el 31 de marzo de 2025 rige una nueva versión del SAQ A. Incluye una condición que afecta sobre todo a la segunda opción: quien usa un formulario integrado debe confirmar que su sitio no es vulnerable a ataques con scripts que puedan afectar al sistema de pago. El motivo es el e-skimming: un script malicioso en su página de pago que lee lo que escribe el cliente o superpone un campo de pago falso sobre el real. Quien redirige a la página del proveedor no está sujeto a esa condición. Pregunte a su proveedor de pago qué SAQ se aplica a su integración; él lo sabe con exactitud.

Lo que debe hacer en cualquier caso:

• Mantenga la página de pago despejada. En principio, cualquier script en esa página puede leer lo que se escribe: widgets de chat, gestores de etiquetas, píxeles publicitarios, herramientas de pruebas A/B. Cargue en la página de pago solo lo necesario para el pago. Un gestor de etiquetas en la página de pago es una puerta por la que cualquiera con acceso a esa cuenta puede añadir scripts.
• Pocos plugins, y actualizados (lección 6.2). La mayor parte del e-skimming en WordPress entra a través de una vulnerabilidad en un plugin o de una contraseña de administrador robada.
• Una Content-Security-Policy (una cabecera que indica desde qué dominios pueden cargarse scripts) limita los daños si, aun así, entra algo. Es trabajo para alguien que sepa probarlo; una CSP incorrecta rompe su botón de pago.

https y HSTS en la página de pago

Es evidente que toda su tienda debe funcionar con https (curso de WordPress, lección 3.1). Para la página de pago se añaden dos cosas:

• http debe redirigir inmediatamente a https, con una redirección permanente (301 o 308). Un cliente que alguna vez escriba http://shop.example.com/afrekenen/ no debe recibir una página sin cifrar.
• HSTS (HTTP Strict Transport Security) es una cabecera con la que indica al navegador que, durante un tiempo, abra su sitio solo por https. Así evita que alguien en una wifi abierta intercepte la primera petición sin cifrar. Un max-age de al menos 180 días es un mínimo habitual. Active HSTS solo cuando todo, incluidos los subdominios que incluya, funcione por https: un navegador que ha visto HSTS rechaza después el acceso por http. El artículo KB 6752 explica cómo configurarlo.

El contenido mixto (un script o una hoja de estilos cargados por http en una página https) en la página de pago es especialmente peligroso: precisamente un archivo así puede sustituirse por el camino.

Card testing

En el card testing, los delincuentes usan su tienda para probar números de tarjeta robados. Realizan automáticamente cientos de pedidos pequeños. Cada pago que sale bien les indica que una tarjeta funciona. Usted recibe un montón de pedidos fallidos, comisiones por transacción, contracargos y, en el peor de los casos, un proveedor de pago que bloquea su cuenta.

Cómo reconocerlo: muchos pedidos en poco tiempo, a menudo del mismo producto pequeño, con nombres distintos pero direcciones iguales o extrañas, y muchos con el estado Fallido.

Cómo limitarlo:

• Rate limiting (un límite al número de peticiones por unidad de tiempo). La Store API de WooCommerce, que usan los bloques de carrito y de finalizar compra, tiene rate limiting integrado, pero está desactivado por defecto. En WooCommerce > Ajustes > Avanzado > Características puede activar "Rate limiting Checkout block and Store API" para la realización de pedidos. Con código (un filtro) puede fijar usted mismo el límite; el valor por defecto es de 25 peticiones cada 10 segundos y solo cuentan los pedidos y otras acciones de escritura. Si su tienda está detrás de un proxy o una CDN, debe activar la compatibilidad con proxy; si no, todos los visitantes cuentan como uno solo.
• Un captcha u otra barrera similar al finalizar la compra. La propia WooCommerce indica que el rate limiting y el captcha funcionan mejor juntos: los atacantes cambian a menudo de dirección IP.
• Los ajustes de su proveedor de pago. Los proveedores tienen sus propios filtros antifraude y límites. Actívelos y revise lo que notifican.
• 3-D Secure (la confirmación adicional en la app del banco, parte de la autenticación reforzada de clientes en la UE) se lo pone más difícil a los delincuentes y, en caso de disputa, a menudo traslada la responsabilidad al banco del titular de la tarjeta.

Otros fraudes

No todo fraude está automatizado. Señales que, sumadas, justifican esperar un poco antes de enviar:

• dirección de facturación y de entrega en países distintos, o una dirección de entrega en un servicio de reenvío;
• un primer pedido solo con productos caros y fáciles de revender, con envío urgente;
• varios intentos con tarjetas distintas;
• un cliente que, tras pagar, pide que se envíe a otra dirección.

Un contracargo (chargeback) es la anulación de un pago con tarjeta por parte del banco del cliente. Pierde el importe, a menudo con comisiones, y el producto ya no está. Por eso, conserve pruebas del envío y de la entrega. Hasta ahora, un pago con iDEAL no podía anularse de esta manera; cómo funciona con Wero se lo dirá su proveedor de pago (lección 4.4). En España se usan habitualmente tarjeta, Bizum, PayPal, transferencia y contra reembolso; pregunte a su proveedor cómo funcionan las anulaciones en cada método.

Resumen

• Los datos de tarjeta nunca entran en su tienda: ni en formularios, ni en notas, ni en correos. Los trata el proveedor de pago.
• La redirección a la página de pago o un campo integrado del proveedor le mantienen en el cuestionario PCI más ligero (SAQ A); con un campo integrado, su página de pago debe estar protegida contra ataques con scripts.
• Mantenga la página de pago despejada, con https, una redirección 301 desde http y HSTS de al menos 180 días.
• El card testing se limita con rate limiting (desactivado por defecto), un captcha y los filtros de su proveedor.
• Esté atento a las señales de fraude y conserve pruebas de la entrega frente a los contracargos.

Cuestionario

Ejercicio

Ejercicio A6.3: ¿Es segura su página de pago? Introduzca la dirección de su tienda y la dirección de su página de pago. El programa comprueba el certificado y solicita la página de pago por http (sin seguir la redirección) y por https (con el carrito vacío, no se pide nada). Verde si el certificado es válido, http redirige a https con 301 o 308, la cabecera Strict-Transport-Security tiene un max-age de al menos 180 días, no hay contenido mixto y como máximo cinco dominios externos cargan scripts en la página (el programa los muestra). Naranja si no hay HSTS o es demasiado corto, si hay una redirección temporal (302 o 307), más de cinco dominios de scripts o un gestor de etiquetas, o un campo para el número de tarjeta en el propio HTML en lugar de en el del proveedor. Rojo si https o el certificado no son correctos, si http no redirige, o si se cargan scripts u hojas de estilos por http. No almacene nunca usted mismo datos de tarjeta. Esta comprobación solo ve lo que hay en la página sin carrito.

Pregunta para usted (no se corrige): ¿su plugin de pago redirige al proveedor, o el campo de pago está en su página? ¿Qué SAQ dice su proveedor que se aplica?

Una marca verde significa que esta comprobación es correcta ahora, no que su tienda sea segura.

Para saber más

Los pasos en un panel se refieren a WebOké; con otros proveedores funciona de forma similar.

• Curso gratuito de WordPress 3.1: https y el certificado
• HSTS y cabeceras de seguridad para su sitio web
• Redirigir obligatoriamente a los visitantes a https
• Manual de DirectAdmin 6.4: Enviar siempre a los visitantes a https
• Curso gratuito Seguridad online para empresarios 4.2: Su sitio web: https, HSTS y cabeceras de seguridad
• Actualizaciones del SAQ A (PCI Security Standards Council, en inglés): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting para la Store API (developer.woocommerce.com, en inglés): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, en inglés): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/