La fecha de vencimiento de una tarjeta es uno de los pocos datos que el usuario localiza de un vistazo, y aun así provoca errores desproporcionados: cobros rechazados por un mes de diferencia, suscripciones que se cortan sin motivo y formularios que dan por inválida una tarjeta perfectamente vigente. Casi todos esos fallos nacen de confundir tres cosas distintas: cómo se muestra la fecha, cómo se guarda y hasta cuándo es válida de verdad. Las tres se aclaran a continuación.
Cómo se lee la fecha impresa
En el anverso aparece un mes y un año, normalmente como dos cifras separadas por una barra: el mes siempre con dos dígitos, con un cero delante cuando hace falta, y el año abreviado a dos dígitos. En español lo natural es hablar de mes y año, y en la documentación en inglés verás la abreviatura de month y year.
Algunas tarjetas acompañan la cifra con una expresión como válida hasta, y otras imprimen el mes con tres letras, pero el significado es el mismo: un mes concreto de un año concreto. No hay día ni hora en el dato impreso, y esa ausencia de día es el origen de la mitad de los problemas que veremos después.
¿Caduca el primer día del mes o el último?
Aquí está la regla que más se malinterpreta: una tarjeta marcada con un mes concreto sigue siendo válida durante todo ese mes, hasta su último día. No caduca el día uno ni a mitad de mes.
Esa diferencia produce el clásico error de un día. Un sistema que compare la fecha actual contra el vencimiento con una comparación estricta dará por caducada la tarjeta justo el día del cobro, o al contrario, la seguirá aceptando durante todo el mes siguiente si la comparación se hace solo por año.
La forma robusta de tratarlo es comparar por parejas de año y mes, considerando válida la fecha si el mes de vencimiento es igual o posterior al mes actual. Si necesitas trabajar con días, convierte el vencimiento al último día de ese mes, pero no lo hagas en la capa de interfaz: es una decisión de negocio, no de presentación.
Formato visible y formato guardado
El formato que se muestra y el que se almacena no tienen por qué coincidir, y de hecho no coinciden. Muchos sistemas guardan el mes y el año como dos valores numéricos independientes, lo que elimina de raíz el problema del orden y del separador. Otros conservan una cadena corta.
En los mensajes que se intercambian entre sistemas, la codificación habitual del sector coloca el año antes que el mes. Es un buen recordatorio de que la representación estándar no es la que ve el usuario. Si tu base de datos guarda el año primero y tu formulario muestra el mes primero, no hay ningún error: son dos vistas del mismo dato. Lo que sí es un error es reutilizar la cadena que se muestra en pantalla como valor almacenado.
Queda por resolver la ambigüedad del año de dos cifras, porque un año corto puede corresponder a dos siglos distintos en abstracto. Los sistemas lo resuelven con una ventana de años, y conviene que esa ventana esté escrita en un único sitio en lugar de repartida por varias comprobaciones.
Diseñar el campo sin pelear con el usuario
El campo de vencimiento recibe muy poco texto, así que cada decisión se nota. Estas pautas funcionan bien en la práctica:
- Acepta el año con dos dígitos y con cuatro. Mucha gente escribe el año completo por costumbre, y rechazarlo es gratuito y molesto.
- Inserta el separador automáticamente mientras se escribe, pero sin borrar lo que la persona ya había tecleado al corregir.
- No valides en cada pulsación. Marcar el campo en rojo después de un solo dígito es la queja más repetida en las pruebas de usabilidad.
- Permite pegar la fecha completa. Pegar es la forma más rápida de rellenar un pago, y bloquearlo solo consigue que la gente abandone.
- Explica el formato antes del error. Un texto de ayuda discreto evita más fallos que un mensaje rojo después.
Si el formulario separa mes y año en dos casillas, revisa que ambas acepten el valor pegado y que el foco salte de una a otra sin obligar a usar el ratón.
¿Qué casos límite conviene probar?
Estas entradas descubren errores reales de implementación casi siempre:
- El mes en curso. Debe aceptarse, porque la tarjeta es válida hasta que el mes termina.
- El mes siguiente y uno lejano, por ejemplo diez años en el futuro, para comprobar que no hay un límite oculto.
- El mes anterior, que debe rechazarse con un mensaje claro y no con un error genérico.
- Mes trece, mes cero y año cero, entradas que deben fallar sin romper la interfaz.
- El año escrito con cuatro dígitos, para confirmar que la normalización funciona.
- Entradas incompletas, como un único dígito de mes o un separador sin año.
- El cambio de año a medianoche, que es donde las comparaciones por cadena suelen equivocarse.
Prueba siempre el paso del tiempo. Un formulario puede comportarse bien hoy y fallar el día uno del mes siguiente, así que las pruebas no deberían depender del reloj real: fija la fecha actual y comprueba los bordes de forma determinista.
Para quien programa
Este campo tiene fama de sencillo y esconde varias trampas. Las siguientes son las que más veces aparecen en una revisión.
- Compara por año y mes, no por cadena. Ordenar texto no equivale a ordenar fechas, porque el año va abreviado y el mes no siempre lleva el cero delante.
- Fija la fecha actual inyectándola. Si la lógica lee el reloj del sistema directamente, la prueba se vuelve imposible de reproducir el mes que viene.
- Mantén la ventana de años en una sola constante. Dos ventanas distintas en el formulario y en el servidor producen rechazos que nadie sabe explicar.
- Normaliza antes de validar. Acepta el año de cuatro dígitos y guárdalo siempre de la misma forma, con una única rutina.
- Trata el vencimiento como dato del emisor. No lo inventes a partir del número ni lo derives de otra fecha; si necesitas un valor para probar, debe ser sintético y quedar claro que no pertenece a ninguna tarjeta emitida.
El generador de este sitio produce ese tipo de dato: números con estructura correcta y nunca emitidos, acompañados de una fecha futura coherente y de un código de seguridad con la longitud que corresponde a la marca. Sirven para comprobar el formulario, no para cobrar.
Siguientes pasos
Si necesitas un vencimiento que encaje con el resto de los datos de prueba, el generador de tarjetas entrega el número, el código y la fecha a la vez. Para el campo que va justo al lado, el artículo sobre qué es el CVV explica su longitud según la marca, y la lista de comprobación del formulario de pago reúne el resto de la matriz, incluidos los rechazos y los reintentos. Si además quieres entender por qué la longitud del número también varía, está desarrollado en el artículo sobre el formato del número de tarjeta.