Validar número de tarjeta parece una tarea de media hora, y es de esas que se revisan tres veces y aun así llegan a producción con un defecto. La causa no es la aritmética, que cabe en pocas líneas, sino el orden de las comprobaciones, el tipo de dato elegido y la decisión de dónde se ejecuta cada control. Este artículo propone una secuencia que aguanta el paso del tiempo y repasa los errores que más veces se cuelan.
¿Qué está intentando evitar la validación?
Conviene empezar por el objetivo, porque de él se deduce todo lo demás. Un validador de números de tarjeta no demuestra que una tarjeta exista ni que tenga fondos; eso solo lo puede decir el emisor, y decirlo cuesta una autorización. Lo que hace es descartar entradas que no pueden ser un número de tarjeta antes de molestar a nadie.
Ese trabajo produce dos beneficios. El primero es inmediato: el usuario ve el error mientras escribe, sin esperar a la red, y corrige donde está el dedo que se equivocó. El segundo es de higiene: menos datos mal formados llegan a la base de datos, a los registros y a los informes.
Un validador bien hecho también cuida la forma del mensaje. Decir que un número no es válido cuando en realidad falta un dígito es tan frustrante como no decir nada.
Un orden que evita la mayoría de los problemas
Cuando la cadena llega desde el formulario, el orden importa porque cada paso prepara el siguiente. Una secuencia que funciona bien:
- Normalizar. Elimina espacios y guiones antes de mirar nada más, y guarda el resultado como texto, nunca como número.
- Comprobar los caracteres. Después de normalizar solo deben quedar dígitos. Rechaza cualquier otra cosa aquí, no más adelante.
- Comprobar la longitud. Aplica el mínimo y el máximo que admita tu producto, con los límites de la norma internacional en lugar de un valor fijo de dieciséis.
- Detectar la marca por el prefijo. Si el prefijo no pertenece a ninguna marca conocida, decide de antemano si eso es un error o una admisión legítima de una marca nueva.
- Aplicar la suma de control. Y solo entonces, si el flujo lo requiere, continuar hacia la autorización.
Fíjate en que la suma de control va la última. Comprobarla antes de la longitud da por buenos números imposibles, y comprobarla antes de los caracteres obliga a manejar entradas que ni siquiera son dígitos.
¿Basta con validar en el navegador?
No, y es el error más frecuente de todos. La validación del cliente existe para dar respuesta inmediata; la del servidor existe para no creerse nada de lo que llega. Son dos trabajos distintos y ninguna sustituye a la otra.
Cualquiera puede enviar una petición directa sin pasar por el formulario, así que el servidor debe repetir la misma comprobación aunque el resultado sea idéntico. Si quieres, comparte una única rutina entre ambos lados para que las reglas no se separen con el tiempo, pero no cuentes con que el navegador la haya ejecutado.
Errores que sobreviven a la revisión
Estos son los defectos que más veces pasan una lectura atenta del código:
| Error | Por qué duele |
|---|---|
| Limpiar solo los extremos de la cadena | Los espacios interiores hacen fallar un número correcto |
| Convertir la entrada a número entero | Se pierde precisión en los valores altos y el fallo es invisible |
| Suponer que la longitud siempre es dieciséis | Rechaza tarjetas reales más cortas y más largas |
| Devolver un simple sí o no | Nadie sabe después si falló el formato, la longitud o la suma |
| Escribir el número completo en los registros | Deja un dato de cuenta en claro donde no debe estar |
| Reutilizar la cadena con formato del formulario | Espacios y guiones acaban almacenados como si fueran parte del dato |
Los dos últimos puntos no son de corrección, sino de cumplimiento, y el artículo sobre datos de prueba y cumplimiento explica qué se puede guardar y qué no.
Qué decirle al usuario cuando algo falla
El mensaje forma parte de la validación, no es un detalle de estilo. Estas tres reglas bastan para la mayoría de los casos.
- Señala el campo concreto. Si el fallo está en la fecha, no marques el número.
- No repitas el valor. Ni en el mensaje, ni en un registro del navegador, ni en la dirección de la página.
- Distingue el error corregible del que no lo es. Un dígito de menos se arregla escribiendo; un rechazo del emisor se resuelve cambiando de medio de pago o probando más tarde.
Cuando el problema viene de la longitud, un mensaje que indique cuántos dígitos faltan ahorra más tiempo que cualquier otro.
Probar el validador con datos sintéticos
Los ejemplos fijos se quedan cortos para una rutina tan mecánica. Es más útil combinar casos concretos con propiedades que deben cumplirse siempre:
- Un cuerpo de dígitos al que se le calcula la suma correcta siempre pasa.
- Cambiar un solo dígito de un número válido lo invalida.
- Intercambiar dos dígitos adyacentes lo invalida, con la excepción conocida de la pareja cero y nueve, que produce la misma suma en ambos órdenes.
- Añadir o quitar un dígito invalida el número.
- Una cadena con letras, guiones sueltos o espacios interiores nunca se acepta.
Para el material de esas pruebas, el generador produce lotes con el prefijo de cada marca y la suma ya ajustada. Recuerda qué son: números con estructura correcta que nunca han sido emitidos. Sirven para validar tu formulario y tu validador, no para cobrar.
Para quien programa
Además del orden de comprobaciones, hay un puñado de decisiones que conviene fijar por escrito antes de escribir el código, porque son las que después se contradicen entre capas.
- Una sola fuente para los límites. El mínimo, el máximo y los prefijos admitidos deberían vivir en una tabla compartida, no repetidos en el formulario y en el servidor.
- Resultado con motivo, no booleano. Devuelve un objeto que distinga entre caracteres inválidos, longitud incorrecta y suma que no cuadra. El mensaje al usuario sale de ahí, no de adivinar después.
- Sin atajos por marca conocida. No te saltes la suma de control porque el prefijo parezca de una marca concreta; los prefijos se reasignan y el atajo envejece mal.
- Registro seguro por defecto. Si de verdad necesitas depurar, guarda solo la longitud y el motivo del rechazo, nunca el valor.
- Pruebas deterministas. Fija los números de prueba dentro del proyecto en lugar de generarlos en cada ejecución, para que un fallo de hoy se pueda reproducir mañana.
Y una recomendación de arquitectura: mantén la validación de formato separada de la llamada a la pasarela. Si están en la misma función, acabarás viendo peticiones de red para entradas que se podían rechazar sin salir del servidor.
Siguientes pasos
Si necesitas entradas para esas pruebas, el generador produce lotes válidos para cada marca. La parte aritmética está desarrollada en el algoritmo de Luhn, los límites de longitud en el artículo sobre el formato del número de tarjeta, y los casos de interfaz en el de la fecha de vencimiento.