Generador de tarjetas de test (Luhn)

Qué es el algoritmo Luhn

Luhn (también llamado "mod 10") es un checksum que detecta errores de tipeo en números de tarjeta. Lo creó Hans Peter Luhn de IBM en 1954. No es seguridad criptográfica: cualquiera puede calcularlo. Su único propósito es detectar errores cuando un humano copia un número.

El algoritmo: recorré los dígitos de derecha a izquierda. Multiplicá por 2 los de posiciones pares (la primera posición desde la derecha es 1, impar). Si el resultado supera 9, restale 9 (o sumá los dígitos). Sumá todos los dígitos. Si el total es múltiplo de 10, el número es Luhn-válido.

Estructura de un número de tarjeta

• BIN/IIN: los primeros 6-8 dígitos identifican al emisor (banco). Por eso los números empiezan distinto según la marca.
• Cuenta: dígitos del medio. Identifican al titular dentro del emisor.
• Checksum Luhn: el último dígito. Calculado para que el total cumpla la regla del mod 10.

Las marcas tienen rangos asignados:

1. Visa: empieza con 4. Largo: 13, 16 o 19.
2. Mastercard: empieza con 51-55 o 2221-2720. Largo: 16.
3. American Express: empieza con 34 o 37. Largo: 15.
4. Discover: empieza con 6011, 644-649 o 65. Largo: 16.
5. Diners Club: empieza con 36, 38 o 300-305. Largo: 14-19.
6. JCB: empieza con 35. Largo: 16.

Tarjetas oficiales de test por procesador

Si lo que querés es probar un checkout completo, no estos números: necesitás los que cada procesador publica en su modo sandbox. Funcionan solo en el ambiente de prueba. Algunas comunes:

• Stripe: 4242 4242 4242 4242 (Visa, success). 4000 0000 0000 0002 (declined). Documentación: stripe.com/docs/testing.
• PayPal: el sandbox de PayPal incluye su propia tarjeta de prueba al crear una cuenta de tester.
• Square: 4111 1111 1111 1111 (Visa). 5105 1051 0510 5100 (Mastercard).
• MercadoPago: 5031 7557 3453 0604 (Mastercard) y 4509 9535 6623 3704 (Visa).
• Adyen: 4111 1111 1111 1111 con CVV 737 y fecha 03/30.

Para qué sí sirven los Luhn-válidos genéricos

Hay casos reales donde necesitás un número que pase la validación Luhn pero no llegue nunca al procesador:

1. Tests unitarios de validadores. Si tu código rechaza tarjetas con Luhn inválido, necesitás casos válidos para asegurarte que las acepta.
2. Tests E2E donde mockeás el procesador. El form de tu app exige Luhn-válido en frontend, pero el backend está stubeado.
3. Validación en formularios sin checkout. Si guardás tarjetas en una app interna (por ejemplo, un sistema de gestión de pagos manuales), querés validar formato sin cobrar.
4. Demos visuales. Mostrar UIs de pago con números que "se ven reales" sin usar uno real.

Lo que NUNCA hay que hacer

• Probar en checkouts reales. Es fraude por intento, aunque no funcionen. Tu IP queda registrada.
• Compartirlos como si fueran reales. Es claramente engañoso.
• Usarlos para credenciales. Algunos sistemas usan tarjetas como verificación de identidad. Un número Luhn-válido no es una identidad.
• Almacenarlos sin marcar. Si los guardás en una base, marcalos claramente como sintéticos.

PCI DSS y datos sintéticos

El estándar PCI DSS (que regula el manejo de datos de tarjetas) reconoce que los datos sintéticos quedan fuera de su alcance: si el número no corresponde a una cuenta real, no es PAN ("Primary Account Number") en el sentido de la norma. Eso permite usarlos en entornos de desarrollo sin tener que tratar la base como un sistema PCI.

Aún así, conviene aislar los datos: no mezclar entornos productivos con sintéticos, no loguear los números en sistemas accesibles, no enviarlos por email.