Un generador de números de tarjeta de crédito sirve para obtener valores que un formulario de pago acepta como bien formados, sin acercarse a ninguna tarjeta que exista de verdad. La necesidad es tan común como delicada: hay que probar la validación de la pasarela, los mensajes de error y el comportamiento del formulario ante entradas límite, y al mismo tiempo hay que mantener los datos de titulares reales fuera del circuito. En esta guía se explica qué distingue un número de prueba de uno auténtico, cómo funciona el dígito de control, por qué los demás campos tienen que encajar con él y dónde está la frontera que marca PCI DSS. Al terminar tendrás claro qué puede hacer un generador y qué decisiones deben tomarse en la pasarela de pago y no en tus datos.
Qué diferencia hay entre un número de tarjeta de prueba y uno real
Un número de prueba es un valor que respeta la estructura del sistema de pagos y que no está asociado a ninguna cuenta. Se construye con la longitud que admite la red correspondiente, con un prefijo que pertenece a esa red y con un último dígito calculado para superar la comprobación aritmética que casi todos los formularios aplican. Cuando el sistema lo valida, el valor pasa el filtro de forma y llega hasta el paso siguiente, que es donde se descubre si el número corresponde a una tarjeta autorizada.
Un número real, en cambio, pertenece a una cuenta emitida por un banco. La diferencia no está en el aspecto, porque ambos pueden tener la misma longitud y la misma estructura, sino en lo que ocurre después. Un valor generado para pruebas nunca supera una autorización, y esa es precisamente su virtud: permite ejercitar todo el camino anterior sin producir efectos económicos.
Esa distinción importa porque las empresas de servicios de pago deducen del número datos que no son evidentes. El prefijo informa de la red, la longitud informa de la clase de producto y el dígito final confirma que el conjunto no tiene un error de transcripción. Un valor de prueba manipula todos esos elementos de forma consciente para que el formulario recorra su lógica completa. La estructura general de estos identificadores está descrita en la guía sobre el formato del número de tarjeta.
El prefijo del emisor y la red de pago
Los primeros dígitos de una tarjeta se llaman identificador del emisor y cumplen dos funciones a la vez. Hacia fuera identifican la red a la que pertenece la tarjeta, y hacia dentro identifican al banco que la ha emitido. Por eso el prefijo no es un adorno: es un dato con significado dentro del sistema, y una prueba que lo invente al azar produce valores que ninguna pasarela reconocería.
Cada red tiene sus propios rangos y sus longitudes admitidas. Algunas usan bloques que empiezan por cuatro, otras por cinco, otras por dos, otras por el par tres y cuatro o por seis. Dentro de cada bloque, la longitud puede variar según el tipo de producto, y hay tarjetas de quince, de dieciséis o de más cifras conviviendo en el mismo sistema. Un formulario que fija una sola longitud rechaza valores legítimos de la misma red.
Para quien prueba formularios, la consecuencia práctica es que conviene trabajar con un conjunto que cubra varias redes y varias longitudes. Probar solo con la red dominante en tu mercado da una impresión de corrección que no resiste el contraste, porque los errores suelen aparecer justamente con las formas menos frecuentes. La comparación entre redes y lo que se puede esperar de cada una está en la guía sobre tarjetas de prueba por red.
¿Qué comprueba realmente el dígito de control de Luhn?
El último dígito de un número de tarjeta no se elige, se calcula. El procedimiento se conoce como algoritmo de Luhn y consiste en recorrer las cifras desde la derecha, duplicar una de cada dos y restar nueve cuando el resultado supera la decena, hasta obtener una suma total que debe terminar en cero. Si el número se transcribe con un error en una sola cifra o si dos cifras contiguas se intercambian, la suma deja de cuadrar y la comprobación falla.
Conviene entender qué no demuestra ese cálculo. No demuestra que la tarjeta exista, ni que esté activa, ni que tenga saldo. Solo demuestra que el conjunto de cifras es internamente coherente, es decir, que el valor pudo ser generado por el emisor y no fue alterado por un error de tecleo. Es una prueba de integridad, no una prueba de autorización, y esa diferencia es la que hace que un número generado pueda pasar la validación del formulario sin ser una tarjeta.
Para el desarrollo tiene una utilidad inmediata. Un campo que aplica la comprobación rechaza la mayoría de las entradas escritas al azar, lo que permite verificar el filtro sin infraestructura adicional. Y cuando el material de prueba incluye a propósito un valor con el dígito alterado, se puede comprobar que el mensaje de error aparece en el momento y en el campo correctos. El desarrollo del algoritmo está explicado con detalle en la guía sobre el algoritmo de Luhn.
¿Por qué el CVV y la fecha deben ser coherentes con el número?
Un formulario de pago no valida un campo aislado, valida un conjunto. El código de seguridad y la fecha de caducidad tienen longitudes y formatos que dependen de la red, y probar el número sin probar los otros dos deja sin cubrir la mitad del formulario. Un valor coherente en el primer campo junto a una fecha imposible produce un error que el sistema debe saber señalar.
El código de seguridad es un buen ejemplo porque su longitud varía. La mayoría de las redes usan tres cifras, pero hay productos que usan cuatro, y un formulario que impone el máximo de tres rechaza tarjetas legítimas de un segmento entero. La fecha de caducidad plantea otro problema: el mes y el año se guardan a menudo en campos separados, y la comparación con la fecha actual introduce reglas que solo se descubren probando con un mes ya pasado y con una fecha muy lejana.
Todo esto se puede cubrir con material generado y verificado por construcción. Cuando el generador produce el trío completo, la prueba comprueba tu lógica en lugar de discutir sobre datos incoherentes. Los detalles de estos dos campos están en las guías sobre qué es el CVV y sobre la fecha de caducidad.
Las tarjetas de prueba oficiales de las pasarelas
Las grandes pasarelas publican listas de números reservados para sus entornos de prueba. Son valores que su propia infraestructura reconoce y cuyo comportamiento está documentado: unos simulan un pago aprobado, otros un rechazo con un motivo concreto, otros una autenticación adicional. Usarlos es la forma recomendada de probar la integración con una pasarela específica, porque reproducen respuestas que sería imposible provocar de otra manera.
El material generado cumple otra función. Sirve para probar tus propias validaciones antes de que el dato llegue a la pasarela, para llenar listados y paneles de administración con tarjetas tokenizadas de ejemplo, y para ejercitar formularios internos que no están conectados a ninguna pasarela. Las dos cosas se complementan y no compiten: una prueba la interfaz de tu sistema, la otra prueba la conversación con el proveedor.
Cuando la pasarela documenta sus valores de prueba, conviene además reservar uno para cada escenario negativo. Un rechazo por fondos, un rechazo por tarjeta caducada y un rechazo por autenticación requerida son tres caminos distintos del código, y los tres merecen una prueba propia. La lista de comprobaciones que suele cubrir este terreno está en la guía sobre la checklist de pruebas del formulario de pago y en la documentación pública de las tarjetas de prueba de Stripe.
El límite de PCI DSS en los entornos de prueba
El estándar de seguridad de la industria de tarjetas de pago se aplica a cualquier sistema que almacene, procese o transmita datos de titulares, y no distingue entre producción y desarrollo. Un entorno de pruebas que guarda números de tarjeta auténticos está dentro del alcance del estándar, con todas las obligaciones que eso implica, aunque el sistema no cobre nada y aunque el entorno esté detrás de una red interna.
Esa es la razón por la que la práctica recomendada es no introducir nunca números de tarjeta reales en un entorno que no sea de producción. Copiar una base de datos de clientes para probar un formulario es la vía más corta a un incidente, porque los entornos de prueba suelen estar peor protegidos, los comparten más personas y acaban replicados en portátiles y copias de seguridad que nadie audita.
Los números de prueba evitan esa exposición desde el principio. Como no pertenecen a nadie, no hay dato personal que custodiar ni alcance que declarar. El tratamiento de este asunto y las consecuencias prácticas para el diseño de entornos están desarrollados en la guía sobre datos de prueba y PCI DSS.
Qué conviene probar en un formulario de pago
La primera familia de casos son los límites de cada campo: el mínimo y el máximo de cifras, el comportamiento del campo cuando se pegan valores con espacios o guiones, y el orden en que se muestran los mensajes de error cuando hay varios campos mal a la vez. Un formulario que solo señala el primer error obliga al usuario a corregir de uno en uno, y eso se descubre probando con todos los campos vacíos.
La segunda familia es el formato de presentación. Los separadores que se insertan automáticamente mientras se escribe, el sitio donde se coloca el cursor al volver a un campo incompleto y el tratamiento del pegado desde el portapapeles son detalles que producen errores difíciles de reproducir a mano. Un conjunto fijo de valores, siempre el mismo, permite repetir la comprobación después de cada cambio.
La tercera familia son los casos de coherencia, donde un campo válido por separado interactúa con otro. Un número de una red con una fecha imposible, un código de seguridad de longitud incorrecta o un nombre de titular con caracteres que el sistema no espera. Todos ellos se resuelven con un conjunto pequeño de registros bien elegidos, y no con un volumen grande de valores repetidos.
Cómo obtener un conjunto de números de prueba
En el generador de tarjetas de crédito de este sitio se eligen la red, la longitud y la cantidad, y la herramienta devuelve números con su dígito de control ya calculado, acompañados de un código de seguridad y una fecha coherentes con el tipo de tarjeta. Al venir del mismo origen, los tres campos se sostienen entre sí y la prueba mide tu formulario y no la calidad del dato. La misma herramienta sirve para construir un conjunto estable que se guarde junto al código y se reutilice en cada ejecución.
Los límites de este material
Los valores que produce un generador son datos de prueba: tienen la forma correcta y el dígito de control válido, pero no corresponden a ninguna cuenta, a ningún banco ni a ningún titular. Pasar la comprobación aritmética no los convierte en tarjetas reales y no autorizan ninguna operación.
Su uso está en probar tus propios formularios, tus validaciones y tus paneles internos en entornos que no sean de producción. No sirven para efectuar cobros, para abrir cuentas ni para acreditarse ante una pasarela, y nunca deben mezclarse con datos de titulares auténticos. Si el sistema que pruebas va a tratar tarjetas reales, la frontera de cumplimiento aplicable es la que decide la arquitectura, no el material de prueba.
Siguientes pasos
Revisa el formulario de pago de tu proyecto y comprueba tres cosas: si admite las longitudes de más de una red, si valida el código de seguridad sin imponer una única longitud y si muestra los errores de todos los campos a la vez. Con esas respuestas, el generador de números de tarjeta de crédito devuelve el conjunto que necesitas para cubrir los casos, con los tres campos coherentes entre sí. Recuerda el límite: son datos de prueba generados para probar software, no corresponden a ninguna tarjeta ni titular real y no sirven para operar.