Si sospechas que alguien está robando datos de tarjeta a través de tu tienda online, esta guía te dice cómo comprobarlo sin cargarte las pruebas y qué tienes que hacer con el banco, la pasarela y tus clientes. Y una cosa por delante, sin rodeos: cuando hay datos de pago de por medio, esto no es un ataque más. No basta con limpiar y seguir. Hay pasos que van en un orden concreto y algunos tienen plazos legales.
El robo de tarjetas en una tienda (lo que técnicamente se llama web skimming o ataque Magecart) consiste en que el atacante mete un trocito de código en tu página de pago que copia el número de tarjeta, la caducidad y el CVV mientras el cliente los teclea, y los manda a un servidor suyo. El cliente paga con normalidad, el pedido entra, todo parece correcto. Por eso es tan difícil de detectar: no rompe nada, solo escucha.
Las señales: quejas de clientes, cargos duplicados y avisos del banco
Casi nunca lo descubre el dueño mirando su web. Lo descubre por rebote. Presta atención si empiezan a coincidir varias de estas cosas:
- Clientes que te escriben porque les han aparecido cargos fraudulentos poco después de comprarte a ti, y no a otros sitios.
- Un aviso de tu banco o de la pasarela de pago avisando de un patrón raro o de una posible brecha (a veces lo detectan antes que nadie, por las reclamaciones agrupadas).
- Un repunte de contracargos (chargebacks) en tu panel de la pasarela.
- Que el punto en común de las víctimas seas tú: si varias personas afectadas solo comparten haber comprado en tu tienda, esa es la pista más fuerte.
Una sola queja puede ser casualidad; la tarjeta de un cliente se puede filtrar en cien sitios. El patrón (varias personas, ventana de tiempo parecida, tu tienda como denominador común) es lo que convierte la sospecha en algo que hay que investigar ya.
Cómo funciona un robo de tarjetas en el proceso de pago
Entender el mecanismo te dice dónde mirar. El código malicioso tiene que estar en el sitio por donde pasan los datos de la tarjeta, y hay tres sitios típicos:
- En el propio HTML/JavaScript de tu checkout. El atacante añade un script que se queda escuchando lo que se escribe en los campos de la tarjeta. Esto pasa cuando el formulario de pago se rellena en tu web (no en la página del banco).
- En un módulo o plugin de pago manipulado. En WooCommerce o PrestaShop, un módulo de pago modificado puede desviar una copia de los datos.
- En un script de terceros que tú cargas. Una librería externa, un chat, un contador de visitas: si el atacante compromete uno de esos, hereda el acceso a tu página de pago.
La buena noticia: si usas una pasarela que redirige al cliente a la página del banco (o que carga el formulario dentro de un iframe del propio proveedor), los datos no pasan por tu servidor y el margen de robo es mucho menor. La mala: muchas tiendas rellenan el formulario en su propia página por comodidad, y ahí es donde entra el skimmer.
Revisar el HTML del checkout y los scripts de terceros
Aquí empieza la parte que puedes mirar tú, con cuidado. Abre tu página de pago en el navegador y usa las herramientas de desarrollador (tecla F12), pestaña Red (Network). Recarga la página del checkout y observa a qué dominios se conectan los scripts. Deberías reconocer todos: tu propio dominio, tu pasarela, tu analítica. Un dominio que no reconoces, sobre todo si recibe datos justo cuando se rellena el formulario, es una bandera roja enorme.
Mira también el código fuente de la página de pago (Ctrl+U) y busca scripts que carguen desde direcciones raras, o bloques de código ofuscado (líneas larguísimas de letras y números sin sentido). En WordPress, revisa por FTP o por el administrador de archivos del hosting los ficheros de la plantilla del checkout y ordena por fecha de modificación: un archivo tocado hace tres días cuando tú no publicaste nada es sospechoso. El detalle de cómo reconocer ese tipo de código lo tienes en la guía para buscar puertas traseras en tu web, porque el skimmer y la puerta trasera suelen venir juntos.
Comprobar el módulo de pago y la pasarela
Entra en el panel de tu tienda y revisa la lista de plugins o módulos de pago. Comprueba dos cosas: que no haya ninguno que tú no instalaste, y que los que hay estén en su versión oficial y actualizada. Si tienes conocimientos, compara los archivos del módulo de pago con una copia limpia recién descargada del proveedor: cualquier diferencia en esos ficheros es motivo de alarma.
En el panel de tu pasarela (Stripe, Redsys, PayPal, la que uses), revisa si hay claves de API o webhooks que no reconozcas. Un atacante que consiga tus claves puede desviar información o crear cobros sin tocar tu web. Si ves algo que no pusiste tú, no lo borres todavía; anótalo, porque es prueba, y sigue leyendo antes de tocar nada.
Qué hacer en las primeras horas sin destruir pruebas
Este es el punto donde la mayoría se equivoca por buena fe: entran a limpiar a lo bruto y borran justo lo que un investigador necesitaría para saber qué se llevó el atacante y a cuántos clientes afectó. Orden recomendado:
- Haz una copia del estado actual antes de tocar nada. Una copia completa (archivos y base de datos) de cómo está la tienda ahora mismo, infectada incluida. Esto congela las pruebas.
- Descarga los logs del servidor (accesos, errores, correo) y guárdalos aparte, porque suelen rotar y borrarse solos a los pocos días.
- Corta el sangrado. Si puedes identificar el script malicioso, sácalo; si no, pon la tienda en mantenimiento para que nadie más introduzca su tarjeta. Perder unas ventas duele menos que seguir filtrando tarjetas.
- No pagues, no negocies, no borres cuentas de golpe sin haber anotado antes qué había.
Con las pruebas a salvo, ya puedes limpiar con calma siguiendo el proceso de cómo limpiar un WordPress hackeado. Y ojo: aquí, más que en cualquier otro tipo de ataque, tener las pruebas ordenadas no es manía de técnico, es lo que te va a hacer falta si el banco o un cliente reclaman.
Obligaciones con el banco, la pasarela y tus clientes
Cuando se han podido filtrar datos de tarjeta, dejas de estar solo ante un problema técnico y pasas a tener obligaciones. En líneas generales:
- Avisa a tu pasarela y a tu banco en cuanto tengas indicios fundados. Ellos tienen sus propios protocolos y cuanto antes lo sepan, menos daño (y menos responsabilidad tuya por demora).
- Los datos de pago son datos personales. Una filtración de tarjetas es una brecha de seguridad, y en España eso activa la obligación de valorar si hay que notificar a la Agencia Española de Protección de Datos, con un plazo corto. Tienes el detalle de cuándo y cómo en la guía sobre notificar una brecha a la AEPD en 72 horas.
- Informa a los clientes afectados cuando corresponda, con un mensaje claro y sin adornos: qué ha pasado, qué datos han podido verse y qué les recomiendas hacer (vigilar movimientos, avisar a su banco).
No soy quien para darte asesoría legal a medida, y aquí conviene tenerla: cada tienda guarda cosas distintas y tu contrato con la pasarela marca parte de tus deberes. Pero la regla práctica es simple: transparencia y rapidez juegan a tu favor; el silencio, en contra.
Por qué aquí no vale con limpiar y seguir como si nada
Con un defacement o un spam de casino, limpias, cierras la puerta y sigues. Con un robo de tarjetas hay una diferencia de fondo: mientras estuvo el skimmer, se estuvieron llevando datos de gente que confió en ti. Aunque quites el código hoy, esas tarjetas ya pueden estar circulando, y tu responsabilidad no termina cuando la web queda limpia.
Por eso este caso se parece más a una respuesta a incidente que a una limpieza normal: interesa saber cuándo entró el skimmer, cuántos pagos pasaron por él y qué se llevó exactamente, porque de eso depende a quién tienes que avisar. Reconstruir eso a partir de los logs y del código no siempre está al alcance de quien lleva la tienda, y hacerlo mal (o tarde) sale caro.
Si hay datos de pago de por medio, no improvises el orden. Escríbenos y te ayudamos con la respuesta a incidentes: preservar pruebas, medir el alcance real y dejar la tienda en condiciones de volver a cobrar con seguridad tiene una secuencia que conviene no saltarse.