Cómo detectar tarjetas generadas y ataques de prueba en una tienda online

Los comercios electrónicos reciben intentos de pago legítimos, errores de clientes y operaciones fraudulentas. Entre los riesgos más frecuentes se encuentran los ataques automatizados que prueban datos de tarjetas robadas o combinaciones creadas para encontrar credenciales que continúen activas.

Estos ataques suelen conocerse como card testing, carding o enumeración de tarjetas.

El objetivo del comerciante no debe ser adivinar si un número fue generado observando solamente sus dígitos. La protección efectiva requiere analizar el comportamiento de la operación, utilizar una pasarela confiable y combinar diferentes controles de seguridad.

Un número que tiene la longitud correcta y supera el algoritmo de Luhn no demuestra que exista una tarjeta real, que tenga saldo o que esté autorizada para realizar pagos.

¿Qué es una tarjeta generada?

Un generador puede producir números que imitan la estructura general de una tarjeta.

Estos números pueden:

• Comenzar con un prefijo relacionado con una red.
• Tener una longitud aparentemente correcta.
• Superar la validación matemática de Luhn.
• Parecer similares a un número emitido por un banco.

Sin embargo, normalmente no tienen una cuenta bancaria real asociada.

Para que una tarjeta pueda utilizarse legítimamente deben coincidir elementos administrados por el emisor, como:

• Número de cuenta.
• Estado de la tarjeta.
• Fecha de vencimiento.
• Código de seguridad.
• Autorización del titular.
• Fondos o línea de crédito.
• Controles internos del banco.

Por ese motivo, revisar solamente el formato no permite confirmar si una tarjeta es auténtica.

Diferencia entre número generado y datos robados

No todos los ataques utilizan números creados al azar.

En muchos casos, los delincuentes emplean datos obtenidos mediante:

• Filtraciones.
• Phishing.
• Malware.
• Páginas de pago comprometidas.
• Robo de cuentas.
• Bases de datos ilegales.
• Ingeniería social.

Después utilizan bots para probar esos datos en formularios de pago. Si una operación pequeña es aceptada, pueden intentar compras mayores o vender la información.

Señales de un ataque de prueba

Un solo pago rechazado no representa necesariamente fraude. Los clientes pueden equivocarse al escribir sus datos o utilizar una tarjeta vencida.

El riesgo aumenta cuando aparecen varias señales al mismo tiempo.

Muchos intentos en poco tiempo

Puede observarse una cantidad elevada de solicitudes desde:

• Una misma cuenta.
• Una misma sesión.
• Una dirección IP.
• Un dispositivo.
• Un rango de direcciones.
• Diferentes IP con comportamiento idéntico.

Los atacantes también pueden utilizar proxies o redes distribuidas, por lo que no conviene depender solamente de la dirección IP.

Operaciones de importe muy bajo

Los ataques de prueba suelen buscar productos baratos, donaciones pequeñas o cargos mínimos para comprobar si una tarjeta funciona.

El importe bajo no demuestra fraude por sí solo, pero debe analizarse junto con la frecuencia y el comportamiento del usuario.

Muchos rechazos consecutivos

Una sucesión de respuestas como las siguientes puede indicar automatización:

• Tarjeta rechazada.
• Fecha incorrecta.
• CVV incorrecto.
• Fondos insuficientes.
• Número no válido.
• Autenticación fallida.

No muestres mensajes demasiado específicos al usuario. Indicar exactamente qué dato fue correcto o incorrecto puede ayudar a quien intenta descubrir credenciales.

Puedes utilizar un mensaje general como:

No fue posible procesar el pago. Revisa los datos o utiliza otro método.

Uso de muchas tarjetas desde una misma cuenta

Una cuenta que intenta pagar con numerosas tarjetas diferentes en pocos minutos debe considerarse de mayor riesgo.

También conviene vigilar:

• Muchas cuentas usando la misma tarjeta.
• Mismo dispositivo con distintas identidades.
• Direcciones de facturación muy diferentes.
• Cambios constantes de nombre y correo.
• Correos temporales o recién creados.

Comportamiento demasiado rápido

Un bot puede completar formularios en una fracción de segundo y repetir exactamente la misma secuencia.

Algunas señales son:

• Tiempo anormalmente corto entre carga y pago.
• Reintentos con intervalos idénticos.
• Navegación directa al formulario sin visitar productos.
• Ausencia de movimientos normales dentro de la página.
• Solicitudes que no ejecutan correctamente JavaScript.

Validaciones que sí pueden aplicarse

Longitud y estructura

Puedes comprobar que el número tenga una longitud compatible con el método de pago seleccionado.

Esta validación sirve para detectar errores de escritura, pero no confirma que la tarjeta exista.

No mantengas manualmente una lista rígida de prefijos. Las redes y entidades pueden actualizar sus rangos. Es preferible utilizar la información proporcionada por la pasarela de pago.

Algoritmo de Luhn

Luhn permite detectar ciertos errores en la estructura de un número.

Puede utilizarse como validación inicial en el navegador, pero nunca como control antifraude principal.

Un número generado puede superar Luhn sin pertenecer a una tarjeta emitida.

Validación desde el servidor

Las decisiones importantes deben realizarse en el servidor.

No confíes solamente en:

• JavaScript del navegador.
• Campos ocultos.
• Valores enviados por el cliente.
• Validaciones visuales.
• Respuestas modificables desde las herramientas del navegador.

El servidor debe confirmar el importe, producto, usuario, moneda y estado real del pago.

Pasarela de pago confiable

Utiliza un procesador que ofrezca:

• Tokenización.
• 3D Secure.
• Evaluación de riesgo.
• Detección de pagos repetidos.
• Webhooks firmados.
• Reglas antifraude.
• Protección contra card testing.
• Entorno sandbox.

No almacenes el número completo de la tarjeta ni el CVV en tu propia base de datos.

No realices transacciones de prueba

Un comercio no debe probar números sospechosos realizando cargos adicionales.

Esto puede:

• Afectar a titulares reales.
• Generar comisiones.
• Incrementar los rechazos.
• Provocar contracargos.
• Incumplir las condiciones del procesador.
• Exponer al comercio a problemas legales.

La tarjeta debe enviarse únicamente a la pasarela como parte del intento legítimo iniciado por el cliente.

Para comprobar la integración técnica utiliza las tarjetas ficticias del entorno sandbox del proveedor.

Sobre las supuestas bases de datos de tarjetas reportadas

No existe una base pública legítima donde un comercio pueda introducir un número completo para saber si fue robado, cancelado o generado.

Publicar o consultar números completos de tarjetas comprometería la seguridad de los titulares.

Los bancos, adquirentes, redes de pago y procesadores mantienen sistemas internos de riesgo que pueden compartir señales dentro de entornos autorizados.

PCI DSS

PCI DSS no es una base de datos de tarjetas.

Es un estándar que establece requisitos para proteger los datos de cuentas de pago.

Su objetivo incluye:

• Reducir la exposición de información.
• Controlar accesos.
• Proteger sistemas.
• Mantener registros.
• Detectar cambios.
• Gestionar vulnerabilidades.

Programas de Visa y Mastercard

Los programas de monitoreo de las redes no funcionan como buscadores públicos de tarjetas.

Están dirigidos a:

• Bancos adquirentes.
• Emisores.
• Procesadores.
• Comercios.
• Proveedores autorizados.

Los comerciantes deben comunicarse con su pasarela o banco adquirente para conocer las herramientas disponibles.

Sistemas de análisis de fraude

Soluciones como las utilizadas por procesadores, bancos o proveedores especializados analizan señales de riesgo sin entregar al comerciante una lista pública de números comprometidos.

Pueden considerar:

• Historial de transacciones.
• Dispositivo.
• Ubicación.
• Importe.
• Velocidad de intentos.
• Relación entre cuentas.
• Patrones conocidos de fraude.

Medidas recomendadas para 2026

Limita la frecuencia de intentos

Aplica límites por:

• Cuenta.
• Sesión.
• Dispositivo.
• Dirección IP.
• Tarjeta tokenizada.
• Correo.
• Dirección de facturación.

Los límites deben aumentar progresivamente ante comportamientos sospechosos.

Por ejemplo, después de varios rechazos puedes:

1. Introducir una pausa.
2. Solicitar una comprobación adicional.
3. Bloquear temporalmente nuevos intentos.
4. Enviar el caso a revisión.
5. Impedir que la misma sesión pruebe otra tarjeta.

Utiliza protección contra bots

Puedes combinar:

• Honeypots.
• Tokens de sesión.
• Comprobaciones de integridad.
• CAPTCHA adaptativo.
• Análisis de comportamiento.
• Desafíos solo para operaciones sospechosas.

No muestres un CAPTCHA a todos los clientes si no es necesario, porque puede perjudicar la experiencia de compra.

Activa 3D Secure

3D Secure permite que el banco evalúe la operación y, cuando sea necesario, solicite una confirmación adicional al titular.

Puede utilizar:

• Aplicación bancaria.
• Código temporal.
• Biometría.
• Passkey.
• Autenticación fuera de banda.

No todas las transacciones mostrarán una verificación visible. Algunas pueden autenticarse mediante un flujo sin fricción.

Protege la página de pago

Un atacante también puede intentar insertar scripts para robar los datos introducidos por clientes reales.

Para reducir este riesgo:

• Limita los scripts externos.
• Revisa las dependencias.
• Usa una política CSP.
• Detecta cambios en archivos.
• Controla quién puede publicar código.
• Mantén el sitio actualizado.
• Utiliza formularios alojados por el procesador cuando sea posible.

Verifica los webhooks

No marques un pedido como pagado únicamente porque el navegador redirige a una página de éxito.

Confirma el pago mediante:

• Webhook firmado.
• Identificador único.
• Importe esperado.
• Moneda correcta.
• Estado definitivo.
• Pedido asociado.

También debes evitar procesar dos veces el mismo evento mediante claves de idempotencia o registros únicos.

Qué registrar sin exponer información

Puedes registrar:

• Fecha.
• Identificador de la transacción.
• Respuesta general.
• Cuenta.
• IP.
• Dispositivo.
• Importe.
• Resultado del control antifraude.
• Últimos cuatro dígitos cuando la pasarela los proporcione.

No registres:

• PAN completo.
• CVV.
• PIN.
• Códigos OTP.
• Contraseñas.
• Datos sensibles de autenticación.

Respuesta ante un ataque

Si detectas un aumento de intentos:

1. Activa límites más estrictos.
2. Bloquea temporalmente patrones repetitivos.
3. Contacta a la pasarela.
4. Revisa los registros.
5. Protege formularios vulnerables.
6. Cambia claves expuestas.
7. Comprueba los webhooks.
8. Informa al banco adquirente cuando corresponda.
9. Conserva evidencia sin almacenar datos prohibidos.
10. Revisa los pedidos aprobados durante el incidente.

No intentes investigar realizando nuevos cargos.

Lista rápida para comerciantes

• Utilizo una pasarela reconocida.
• No almaceno números completos ni CVV.
• Confirmo los pagos mediante webhooks.
• Tengo límites de intentos.
• Detecto múltiples tarjetas por cuenta.
• Uso protección contra bots.
• Oculto detalles innecesarios de los rechazos.
• Tengo 3D Secure disponible.
• Protejo los scripts de la página de pago.
• Utilizo sandbox para las pruebas.
• Sé cómo contactar a mi procesador.
• Reviso periódicamente los registros de fraude.

Conclusión

No es posible distinguir con certeza una tarjeta real de un número generado observando únicamente sus dígitos.

La longitud, el prefijo y Luhn sirven para detectar errores básicos, pero no confirman que exista una cuenta ni que el titular haya autorizado la compra.

La protección efectiva requiere varias capas:

• Pasarela confiable.
• Tokenización.
• 3D Secure.
• Límites de frecuencia.
• Protección contra bots.
• Validación en servidor.
• Webhooks firmados.
• Monitoreo de patrones.
• Cumplimiento de PCI DSS.

Los comerciantes no deben buscar bases públicas de tarjetas ni realizar cargos de prueba. Deben apoyarse en su banco adquirente, procesador y herramientas antifraude autorizadas.