Qué es el CVV es una de esas preguntas que parecen triviales hasta que hay que programar el campo. El CVV es el código corto que un formulario de pago pide «por detrás» —o por delante, según la marca— y que nunca aparece en un extracto ni en un recibo. Su función se enuncia en una frase: demostrar que quien está pagando tiene la tarjeta física delante. Cumplir esa frase en el código de un producto es bastante más difícil. Al terminar esta guía sabrás de dónde sale el código, por qué se prohíbe almacenarlo y qué comprobar en un formulario que lo solicita.
De dónde sale el código de seguridad
El código no se deduce del número de tarjeta. Lo calcula el emisor y lo imprime en el plástico; en la banda magnética y en el chip viajan valores distintos, también generados por el emisor, que no coinciden con el que el cliente teclea. Por eso copiar el número de una tarjeta no basta para completar un pago a distancia: falta un dato que solo está en el objeto.
En la mayoría de las marcas son tres dígitos impresos en el reverso, cerca de la banda de firma. American Express hace lo contrario: su código tiene cuatro dígitos y va impreso en el anverso, encima del número. Ese contraste se nota en cuanto se prueba un formulario real, porque el campo cambia de longitud según la marca que el usuario introduce.
Cada red comercializa el código con su propia denominación, así que en la documentación aparecerán siglas distintas para el mismo concepto. Lo importante no es la sigla, sino la naturaleza del dato: un valor numérico corto, asignado por el emisor, que no se puede calcular a partir del resto.
¿Por qué el formulario me lo pide a mí?
Porque en un pago sin presencia de la tarjeta el comercio nunca ve el plástico. El número circula con demasiada facilidad: se copia de un correo, se filtra en una base de datos, aparece en una factura escaneada. Hace falta algún dato que solo esté en la tarjeta física, y ese es el papel del código.
Un atacante que solo haya obtenido el número no puede completarlo. No es una garantía absoluta, porque el código también puede fotografiarse o anotarse, pero eleva el coste del fraude lo suficiente como para que la industria lo exija en la mayoría de los cobros a distancia.
Existe además una razón de reparto de responsabilidad. En muchos mercados la presencia del código desplaza parte del riesgo hacia la entidad emisora y libera al comercio de algunas disputas. Es una de las razones por las que un formulario que no lo pide suele tener peores condiciones que uno que sí lo pide.
Por qué está prohibido almacenarlo
Aquí está la regla que rompe más a menudo quien empieza: el código no se puede guardar después de autorizar el pago. Forma parte de lo que el estándar de seguridad de datos de pago denomina datos de autenticación sensibles, y la norma no admite matices ni cifrado: no se almacena, ni siquiera protegido, ni siquiera durante unos segundos.
Eso descarta prácticas que a mucha gente le parecen inocentes:
- Guardarlo «para el próximo cobro» o para una suscripción que se renueva sola.
- Escribirlo en un registro de la aplicación para depurar un rechazo, o incluirlo en un correo de aviso.
- Enviarlo a un sistema de analítica, a una herramienta de trazas o a un panel de soporte.
- Conservarlo en un borrador del navegador o en un formulario guardado por el usuario.
La consecuencia de diseño es clara: la renovación automática de un cargo no puede depender de este código. Si el producto necesita cobrar sin el cliente delante, lo que hace falta es una autorización guardada del emisor o una referencia del proveedor de pagos, no un valor almacenado. El detalle normativo está en el artículo sobre datos de prueba y cumplimiento.
¿Dónde está el código en cada tarjeta?
La ubicación cambia y conviene explicárselo bien al usuario, porque un formulario no debería obligarle a buscar. Esta tabla resume los casos habituales.
| Marca o grupo | Dígitos | Dónde está impreso |
|---|---|---|
| Visa, Mastercard y la mayoría | 3 | Reverso, junto a la banda de firma |
| American Express | 4 | Anverso, encima del número |
| Marcas de quince dígitos en general | 4 | Anverso |
| Formatos más recientes con chip | 3 | Reverso, a veces en una casilla aparte |
Un formulario bien hecho detecta la marca por el prefijo del número y ajusta el campo en consecuencia: longitud, etiqueta y posición del texto de ayuda. Pedir siempre tres dígitos es la causa más común de que alguien con una tarjeta de cuatro no pueda terminar la compra.
Qué no puede decirte este código
El código de verificación no es una prueba de identidad ni un certificado de que la tarjeta sea válida. Comprobar que los dígitos tienen el formato correcto no confirma que el titular sea quien dice ser, ni que la cuenta tenga fondos, ni que el número no esté en una lista de tarjetas bloqueadas.
Un formulario puede aceptar un código perfectamente formado y recibir después un rechazo por fondos insuficientes o por sospecha de fraude. Y al contrario: contra un entorno de pruebas mal configurado, un valor inventado no siempre produce un error inmediato, porque quien decide es el emisor y no la validación local.
Tampoco sirve como dato reproducible de prueba. Como no se deduce del número, no hay fórmula que lo genere: en un entorno de pruebas se acepta cualquier valor con la longitud correcta, y contra un sistema real no existe ningún valor seguro que usar.
Para quien programa
La parte visible del campo es simple; las obligaciones que lo rodean no lo son. Estas son las comprobaciones que conviene tener por escrito antes de dar la pantalla por terminada.
- Longitud según la marca. El campo debe reevaluarse cuando el usuario cambia de marca, en lugar de conservar la validación anterior.
- Sin rastro en los registros. Revisa los registros de la aplicación, las herramientas de trazas y los avisos de error: el valor no debe aparecer en ninguno. Un rechazo se depura por su código, no por el contenido del campo.
- Sin copia en el estado de la aplicación. El valor debe vivir en memoria el tiempo mínimo, y desaparecer en cuanto termina la petición, sin quedar en un almacén local ni en una caché de formulario.
- Sin mensajes que lo repitan. El aviso de error describe el problema del campo; no repite lo que el usuario escribió ni lo refleja en la dirección de la página.
- Con datos de prueba sintéticos. Combina números de estructura válida y nunca emitidos con códigos inventados de la longitud correcta. Nunca mezcles un número auténtico con un código falso para «ver si pasa»: si el número es real, acabas de enviar una credencial de pago.
Sobre este último punto, el generador entrega el número, la fecha y el código a la vez y con la longitud que corresponde a cada marca, lo que ahorra tener que inventar combinaciones coherentes.
Siguientes pasos
Para montar datos de prueba completos, empieza por el generador de tarjetas, que produce el número y el código con la longitud correcta para cada marca. Si te interesa cómo se relaciona este campo con el resto, revisa el formato del número de tarjeta y, para el campo que va justo al lado, el artículo sobre el formato de la fecha de vencimiento. Y si estás preparando la batería de pruebas antes de un lanzamiento, la lista de comprobación del formulario de pago reúne los casos que suelen faltar.
Recuerda siempre qué estás manejando: datos estructuralmente correctos que nunca han sido emitidos, útiles para probar una pantalla y jamás para cobrar.