Explica qué cobros se autorizan y conserva la evidencia adecuada del acuerdo. Deja que el cliente introduzca la tarjeta en el entorno de la pasarela, utiliza la referencia técnica resultante y limita el acceso a los datos. Separa autorización de pago, base jurídica de privacidad y cumplimiento técnico.
1. Distingue tres decisiones que no son equivalentes
La primera decisión es comercial: qué servicio contrata el cliente y en qué condiciones se pagará. La segunda es la autorización para utilizar el medio de pago en ese marco. La tercera es cómo tratarás los datos personales necesarios. Resolver una de ellas no resuelve automáticamente las otras.
Una referencia de tarjeta válida no permite cobrar cualquier concepto o importe. Del mismo modo, mostrar una política de privacidad no demuestra que el cliente haya aceptado una suscripción. Revisa cada parte antes de activar futuros cargos, especialmente si quien utiliza el servicio y quien lo paga son personas distintas.
Este artículo organiza comprobaciones para un comercio. La guía de tokenización de tarjetas explica el mecanismo técnico con más detalle. Aquí el foco está en lo que debes preparar alrededor del alta para que la autorización y la operativa no queden separadas.
2. Explica los cobros que el cliente está aceptando
Antes de pedir una tarjeta, identifica al negocio, el servicio, el importe o su forma de determinación, la periodicidad y la fecha del primer cobro. Aclara también las condiciones de cambios y cancelación que resulten aplicables. Evita que la recurrencia aparezca solo en un texto secundario después de confirmar el pago.
Conserva una evidencia apropiada de la aceptación y de la versión de las condiciones mostradas. El procedimiento concreto depende del canal, del contrato y de las exigencias de la pasarela. No anuncies que el programa guarda automáticamente todos esos elementos si no lo has comprobado en tu flujo.
Si un cliente acepta una cuota mensual y más tarde quiere un servicio adicional, revisa cómo se autoriza ese nuevo concepto. Tener una tarjeta asociada simplifica parte del proceso técnico, pero no convierte una compra posterior en un cargo previamente aceptado.
3. Determina la base jurídica e informa por finalidad
El consentimiento no es la única base jurídica prevista para tratar datos personales. La AEPD explica las bases de legitimación del tratamiento: debes identificar la que corresponde a cada finalidad e informar de ella. La ejecución del contrato puede ser relevante para datos necesarios para prestarlo; no justifica cualquier uso adicional.
Separa la gestión de la suscripción de otros fines, como comunicaciones comerciales. Pedir un único permiso genérico para todo dificulta explicar qué tratamiento es necesario y cuál depende de una decisión distinta del cliente. Prepara información comprensible en el momento adecuado del alta.
Revisa además las responsabilidades de tus proveedores. Cuando corresponda un encargo de tratamiento, la AEPD detalla qué debe contemplar el contrato. No atribuyas automáticamente el mismo papel a todos los participantes: depende del servicio y de las decisiones que adopta cada uno.
4. Utiliza el entorno de la pasarela para la tarjeta
El recorrido debe llevar al cliente a introducir la información sensible en el entorno de pago correspondiente. Evita solicitar fotos de la tarjeta, números completos por correo o mensajes con su código de seguridad. Tampoco los copies en notas de cliente, hojas de cálculo, tareas de soporte o capturas para «facilitar» la siguiente mensualidad.
Comprueba las direcciones que envías y el contexto del mensaje. Un enlace de pago personal no debe publicarse como si fuera un formulario genérico para todos. Si una persona duda de su autenticidad, ofrece un canal conocido para confirmar el procedimiento sin pedirle que te lea los datos de la tarjeta.
Si recibes información sensible por un canal no previsto, no la reenvíes para resolver la incidencia. Aplica tu procedimiento de seguridad, limita el acceso y determina cómo tratar el envío. No conviertas una excepción en el nuevo método habitual de alta.
5. Comprueba qué se guarda después del alta
En el modelo descrito en seguridad de PagosRecurrentes, la tarjeta se introduce en Redsys o Stripe. La plataforma utiliza referencias técnicas para coordinar la recurrencia y no almacena el número completo ni el CVV. Mantiene datos operativos de clientes, suscripciones y resultados de las transacciones.
| Elemento | Uso que debes comprobar |
|---|---|
| Condiciones aceptadas | Determinan el marco del servicio y de los cobros autorizados |
| Referencia de pago | Permite a la pasarela identificar el medio de pago |
| Periodicidad e importe | Organizan la programación de la suscripción |
| Resultado de la operación | Indica qué ocurrió con un intento concreto |
| Datos de contacto | Permiten gestionar la relación en las finalidades informadas |
Un token no es una autorización ilimitada ni un dato que deba circular libremente. Protege también las credenciales de acceso y la configuración del comercio. La seguridad de la pasarela no compensa una cuenta de administración compartida sin control.
6. No conserves el código de seguridad para futuros cobros
PCI SSC indica que los códigos de verificación no pueden almacenarse después de la autorización para operaciones posteriores, incluidas las recurrentes. La restricción se mantiene aunque se cifren o el cliente dé permiso para guardarlos. Pedir que lo anoten «solo por si falla una cuota» no es una alternativa válida.
Revisa el recorrido completo de soporte: formularios, adjuntos, correos reenviados y documentos exportados. Un sistema central puede estar bien diseñado y, aun así, el equipo puede crear copias innecesarias al resolver una incidencia. Define qué datos se pueden solicitar y cómo escalar un caso que exija revisar el medio de pago.
No atribuyas a tu comercio certificaciones que corresponden a un proveedor. El cumplimiento depende del alcance y de las obligaciones de cada participante. Consulta con la entidad adquirente o proveedor qué validaciones requiere tu integración concreta, sin asumir que la tokenización elimina todas tus responsabilidades.
7. Ejemplo ficticio de un alta bien delimitada
Imagina una academia que ofrece una mensualidad de 45 €. Antes del alta, comunica qué periodo cubre, cuándo se cobrará y qué condiciones se aplican a cambios y bajas. La persona pagadora recibe el recorrido de pago correspondiente e introduce la tarjeta en la pasarela, no en un correo a recepción.
El equipo comprueba después si el alta se completó, qué referencia operativa quedó asociada y cuál es el siguiente vencimiento. Si hay un primer pago, revisa su resultado por separado. Haber enviado el enlace o haber recibido una respuesta del cliente no acredita que la tarjeta haya quedado correctamente asociada.
Al mes siguiente, el alumno solicita un taller adicional de 20 €. Ese nuevo concepto necesita revisar su contratación y autorización; no se cobra simplemente porque exista una tarjeta. El ejemplo es ficticio y muestra cómo separar decisiones, no una garantía de aceptación bancaria o de ausencia de disputas.
8. Revisa accesos, conservación y fin de la relación
Decide quién puede gestionar suscripciones, consultar información y modificar credenciales. Mantén un procedimiento cuando cambie la persona responsable. No es necesario que todos los empleados tengan el mismo acceso para responder una pregunta sobre una mensualidad.
- Identifica las condiciones y el alcance de los futuros cobros.
- Conserva la evidencia que corresponda al acuerdo y al canal.
- Informa del tratamiento de datos por finalidad y base jurídica.
- Utiliza el entorno de pago de la pasarela.
- Evita números completos y CVV en correos, notas y archivos.
- Comprueba el alta, el vencimiento y cada resultado por separado.
- Define revisión de accesos, conservación y cierre de la relación.
Al terminar una suscripción, revisa qué información debe conservarse por obligaciones o incidencias y cuál ya no resulta necesaria. Cancelar cobros no equivale automáticamente a borrar todos los datos ni autoriza a seguir cobrando. Si el caso exige valorar derechos o responsabilidades concretos, recurre a asesoramiento especializado.
Preguntas frecuentes
¿Basta con una casilla para guardar la tarjeta legalmente?
No. Debes revisar el acuerdo de cobro, la información de privacidad, la base jurídica y el recorrido técnico. Una casilla genérica no demuestra que todos esos elementos estén resueltos ni legitima cualquier cargo posterior.
¿Puedo conservar el CVV si el cliente me lo autoriza?
No para futuros cobros después de la autorización. PCI DSS no permite conservarlo para esa finalidad, ni siquiera cifrado. Utiliza el procedimiento de recurrencia de la pasarela y evita copiar el código en cualquier registro auxiliar.
¿El token permite cobrar cualquier importe?
No. Es una referencia técnica del medio de pago. Cada cargo debe responder al acuerdo y a las condiciones aplicables. Los cambios de servicio o importe pueden requerir información o una aceptación adicional según el caso.
¿PagosRecurrentes guarda el número completo de la tarjeta?
No según su modelo de seguridad. La plataforma coordina las suscripciones mediante referencias técnicas; los datos de tarjeta se introducen en Redsys o Stripe. El negocio debe proteger sus propios accesos y organizar correctamente el alta.
¿Dar de baja la suscripción borra todos los datos?
No automáticamente. La cancelación operativa, el tratamiento de una solicitud de supresión y las obligaciones de conservación son cuestiones distintas. Revisa qué datos siguen siendo necesarios y limita los usos posteriores a los que correspondan.
Revisa cómo circulan los datos de tus cobros
Comprueba el modelo de seguridad y el recorrido de alta antes de activar la recurrencia. Podemos ayudarte a distinguir qué gestiona la pasarela y qué debe organizar tu negocio.