✓ Sin registro 🔒 Todo en tu navegador Lotes de 1 a 100 · CSV y JSON

Generador de tarjetas de crédito de prueba

Números que pasan el algoritmo de Luhn con el prefijo y la longitud correctos de cada marca, con CVV, fecha de expiración y titular. Son sintéticos: no están asociados a ninguna cuenta y no pueden cobrar.

100 % privado. No hay servidor: los datos se generan en tu navegador y no se envían ni se guardan en ninguna parte.

Cómo funciona

Tres pasos, cero configuración

1

Elige la marca

Cada marca tiene su prefijo y su longitud: Visa empieza por 4 con 16 dígitos, Mastercard por 51-55 o 2221-2720 con 16, American Express por 34 o 37 con 15 y Diners Club por 36 con 14.

2

Válida o que falle Luhn

El modo válido calcula el dígito de control correcto. El modo inválido lo altera: úsalo para comprobar que tu formulario detecta un número mal escrito antes de enviarlo a la pasarela.

3

Copia el juego completo

Número, CVV, expiración y titular en una sola línea, o el lote entero en CSV con cada dato en su columna para tus pruebas automatizadas.

Qué significa que una tarjeta «pase Luhn»

El algoritmo de Luhn (norma ISO/IEC 7812) es una suma de control diseñada en 1954 para detectar errores de tecleo: un dígito equivocado o dos dígitos intercambiados. Funciona así: recorriendo el número de derecha a izquierda se duplica uno de cada dos dígitos, y si el resultado pasa de 9 se le restan 9; el número es correcto cuando la suma total es múltiplo de 10.

Por eso todas las tarjetas reales pasan Luhn, y por eso cualquier formulario decente lo comprueba antes de llamar a la pasarela: es validación gratuita en el navegador que ahorra una petición. Que un número pase Luhn significa que está bien escrito, no que exista una cuenta detrás. Son dos cosas distintas y ahí está la utilidad de este generador.

Prefijos y longitudes por marca

MarcaPrefijo (IIN)DígitosCVV
Visa4163
Mastercard51–55 y 2221–2720163
American Express34 y 37154
Diners Club36143

Con estos datos puedes probar la detección automática de marca mientras se escribe, el agrupado visual en bloques de cuatro (que en Amex es 4-6-5, no 4-4-4-4) y la longitud del CVV, que cambia a cuatro dígitos en American Express y rompe más formularios de lo que parece.

Nunca podrán cobrar: eso es una característica

Estos números no están asociados a ninguna cuenta ni emisor. Sirven para probar el front-end del pago: máscara de entrada, validación de Luhn, detección de marca, fecha de expiración vencida, CVV incompleto, mensajes de error. En cuanto el flujo llega al cobro real, la pasarela los rechazará.

Para probar el pago de principio a fin necesitas las tarjetas de sandbox de tu pasarela: Culqi, Niubiz, Izipay o Mercado Pago publican las suyas, y cada número está asociado a un resultado concreto (aprobada, fondos insuficientes, robada). La opción «números de sandbox conocidos» de esta herramienta incluye los universales 4111 1111 1111 1111, 4242 4242 4242 4242, 5555 5555 5555 4444 y 378282246310005, que la mayoría de entornos de prueba reconoce.

Fecha de expiración y casos límite

La fecha es donde se esconden los defectos más silenciosos. Una tarjeta que expira este mismo mes sigue siendo válida hasta el último día, y muchos sistemas la rechazan un mes antes de tiempo. Prueba también el año de dos cifras contra el de cuatro, el mes 13, el 00 y una fecha ya vencida: el generador de CVV y expiración cubre esas variantes por separado.

Datos de tarjeta y PCI DSS

Una razón práctica para usar números sintéticos: nunca metas datos de tarjetas reales en un entorno de pruebas. Los entornos de QA suelen tener registros verbosos, copias de base de datos y accesos amplios; un PAN real ahí es un incidente de seguridad y un problema de cumplimiento PCI DSS. Con números generados, un volcado de logs no expone nada de nadie.

  • Usa el modo inválido para verificar que el error se muestra antes de llamar a la pasarela.
  • Comprueba que los logs enmascaran el número (solo los últimos 4 dígitos).
  • Verifica que el CVV no se guarda nunca: almacenarlo está prohibido por PCI DSS.
  • Genera 100 tarjetas y prueba tu formulario con lectura automatizada.

Preguntas frecuentes

Dudas habituales

¿Se puede comprar algo con estas tarjetas?

No. Son números sintéticos que cumplen el formato y la suma de control, pero no están asociados a ninguna cuenta, emisor ni saldo. Cualquier intento de cobro real se rechaza.

¿De verdad pasan el algoritmo de Luhn?

Sí. El último dígito se calcula con Luhn sobre el resto del número, y la propia herramienta muestra el resultado de la comprobación en la columna luhn_valido del CSV. Puedes verificarlo con cualquier validador independiente.

¿Sirven para probar Culqi, Niubiz, Izipay o Stripe?

Sirven para todo lo que ocurre antes de la pasarela: máscara, validación, detección de marca y mensajes de error. Para el cobro en modo sandbox usa las tarjetas de prueba que publica cada pasarela; la opción «números de sandbox conocidos» incluye los más universales.

¿Es legal generar números de tarjeta de prueba?

Sí. Generar números que cumplen una regla matemática es legal y es práctica habitual en desarrollo y QA. Lo ilegal es intentar usar datos de tarjetas ajenas o construir números con la intención de defraudar.

¿Incluye CVV y fecha de expiración?

Sí: CVV de 3 dígitos (4 en American Express), fecha de expiración futura y titular en mayúsculas sin acentos, como aparece en las tarjetas reales. Si necesitas fechas vencidas o imposibles, usa el generador de CVV y expiración.

¿Puedo generar tarjetas que fallen la validación?

Sí, con el modo «falla Luhn». Es la prueba negativa que necesitas: un formulario que acepta un número con un dígito mal escrito acabará generando un rechazo en la pasarela y una mala experiencia para el usuario.

¿Por qué no debo usar tarjetas reales en un entorno de pruebas?

Porque los entornos de QA registran mucho, se copian con frecuencia y tienen accesos amplios. Un número de tarjeta real ahí es una fuga de datos y un incumplimiento de PCI DSS. Con datos sintéticos, ese riesgo desaparece.