Cobrar suscripciones con Redsys en WooCommerce es hoy la vía estándar para gestionar pagos recurrentes en España, porque Redsys es la plataforma que da servicio a la mayoría de bancos españoles (BBVA, Santander, CaixaBank, Sabadell y muchos más). La clave no está en el primer cobro, que cualquier pasarela sabe hacer, sino en el segundo, el tercero y todos los que vienen después: renovaciones que se cobran solas, mes tras mes, sin que el cliente tenga que volver a introducir su tarjeta. En este artículo te explicamos cómo lo hace posible la tokenización, cómo encaja con la normativa SCA/PSD2 y por qué Bizum, pese a ser cómodo, no puede usarse para lo recurrente. El objetivo es que montes un modelo de cuotas fiable, en el que un primer pago autorizado dé pie a cobros posteriores sin fricción.
Suscripciones con Redsys en WooCommerce: por qué la tokenización lo cambia todo
Un cobro recurrente tiene una exigencia particular: el negocio debe poder volver a cobrar sin que el cliente esté presente. Eso obliga a guardar de forma segura una “credencial de pago” reutilizable. Redsys resuelve esto con el pago por referencia, que es su nombre para la tokenización: en el primer pago no solo se cobra, sino que se solicita al banco una referencia que representa esa tarjeta y que queda vinculada al comercio. En las renovaciones, la tienda envía únicamente esa referencia y el importe, y el banco ejecuta el cargo.
Conviene subrayar una idea que a menudo se pasa por alto: la tienda nunca vuelve a manejar el número real de la tarjeta. Solo guarda y reutiliza esa referencia, de modo que los datos sensibles permanecen siempre del lado del banco y de Redsys, no en tu servidor. Esto reduce tu exposición y simplifica el cumplimiento de las obligaciones de seguridad sobre datos de tarjeta.
Qué es el pago por referencia (tokenización)
La referencia es un identificador opaco. No es el número de la tarjeta, no revela los datos sensibles del cliente y solo sirve para ese comercio concreto. Por eso es seguro almacenarla: aunque alguien la interceptara, no podría usarla en otro sitio ni reconstruir la tarjeta original. Este mecanismo es lo que separa una simple pasarela de pago de una pasarela capaz de sostener suscripciones reales. Sin token, cada renovación exigiría que el cliente volviese a pagar a mano, y eso, en la práctica, mata cualquier modelo de recurrencia.
Cómo funciona el cobro recurrente con Redsys paso a paso
Para entender bien cómo funcionan las suscripciones con Redsys en WooCommerce, conviene separar mentalmente dos momentos muy distintos, porque tienen requisitos técnicos y legales diferentes.
El primer pago: alta de la referencia
En el checkout inicial el cliente sí está presente. Introduce su tarjeta en el TPV virtual de Redsys y, si su banco lo pide, completa la autenticación reforzada (normalmente un código enviado por la app bancaria o por SMS). En esa misma operación, la tienda solicita el alta de la referencia. Al terminar, ocurren dos cosas: se ha cobrado la primera cuota y se ha guardado el token para el futuro.
Las renovaciones automáticas: cobro sin fricción
Cuando llega la fecha de renovación, el proceso es totalmente desatendido. WooCommerce dispara el cobro, envía la referencia guardada a Redsys y el banco carga el importe. El cliente no recibe ningún formulario, no tiene que hacer nada y, si todo va bien, ni se entera hasta que ve el cargo en su extracto. Cuando el banco responde, Redsys envía a la tienda una notificación de confirmación; con ella, WooCommerce marca el pedido de renovación como pagado y prolonga la suscripción de forma automática. Este es exactamente el comportamiento que la guía de suscripciones en WooCommerce describe como imprescindible para cualquier negocio de cuotas: que la renovación no dependa de la buena memoria del cliente.
SCA y PSD2: autenticación reforzada sin romper las renovaciones
La normativa europea PSD2 introdujo la Autenticación Reforzada de Cliente (SCA): en muchos pagos electrónicos el usuario debe demostrar quién es con un doble factor. A primera vista esto choca con la idea de un cobro desatendido, porque en la renovación el cliente no está delante para autenticarse. Aquí es donde la tokenización bien implementada marca la diferencia.
Cómo las suscripciones con Redsys en WooCommerce sortean el SCA de forma segura
La propia PSD2 contempla las operaciones iniciadas por el comercio (los llamados MIT, merchant-initiated transactions). La lógica es sencilla: la autenticación fuerte se realiza una vez, en el primer pago con el cliente presente, y ese consentimiento queda asociado a la referencia. Las renovaciones posteriores se marcan como cargos recurrentes iniciados por el comercio, quedando exentas de repetir el doble factor. No se está saltando la seguridad: se está cumpliendo la norma en el momento correcto y aprovechando la exención prevista para lo recurrente. Por eso las suscripciones con Redsys en WooCommerce pueden ser automáticas y cumplir la normativa a la vez.
En la práctica, esto significa que la carga de la autenticación recae en el primer cobro. Si ese alta se hace bien, con la tarjeta correctamente tokenizada y el consentimiento registrado, el resto del ciclo de vida de la suscripción transcurre sin volver a molestar al cliente con códigos ni confirmaciones. De ahí que el alta sea el momento más delicado de todo el proceso y el que más conviene cuidar.
Por qué Bizum no sirve para cobros recurrentes
Bizum es rápido, conocido y con una excelente tasa de conversión para pagos puntuales. Pero está diseñado precisamente para eso: pagos puntuales, uno a uno, con el usuario confirmando en su móvil. Bizum no admite tokenización, es decir, no genera una referencia reutilizable que permita al comercio volver a cobrar por su cuenta. Sin token no hay renovación desatendida posible.
La consecuencia práctica es clara: puedes ofrecer Bizum para el primer pago si a tus clientes les resulta cómodo, pero la renovación de una suscripción necesita, sí o sí, una tarjeta tokenizada a través de Redsys. Presentar Bizum como método de “suscripción” sería engañoso, porque cada mes exigiría al cliente confirmar el pago manualmente, y eso ya no es una suscripción: es una serie de compras sueltas que dependen de que el cliente se acuerde y quiera.
Tabla comparativa: Redsys tokenizado frente a otras opciones
| Método | Renovación automática | Tokenización | SCA una sola vez | Uso recomendado |
|---|---|---|---|---|
| Redsys (pago por referencia) | Sí | Sí | Sí, en el alta | Suscripciones y cuotas recurrentes |
| Bizum | No | No | No aplica | Solo pagos puntuales o primer cobro |
| Domiciliación SEPA | Sí | Mandato, no token de tarjeta | No aplica | Recurrente B2B o cuotas grandes |
| Tarjeta internacional (otras pasarelas) | Sí | Sí | Sí | Ventas fuera de España |
Para un negocio español que vende a clientes españoles, montar suscripciones con Redsys en WooCommerce suele ser la combinación más natural: cuota baja, integración directa con el banco de siempre y compatibilidad total con el cobro recurrente.
Cómo configurar el cobro recurrente de Redsys en tu tienda
No entraremos en el detalle técnico de cada entidad para poner en marcha las suscripciones con Redsys en WooCommerce, porque cada banco tiene su propio panel, pero sí conviene saber qué pedir y qué buscar para no llevarte sorpresas.
Qué pedir a tu banco
- TPV virtual con pago por referencia activado. No basta con un TPV normal; hay que solicitar explícitamente la modalidad de referencia (tokenización). A veces se llama “pago por referencia” o “pago recurrente”.
- Clave secreta de firma (SHA-256). Redsys firma cada operación; necesitarás esa clave para que WooCommerce y el banco se entiendan.
- Confirmación de que soportan MIT. Es lo que permite marcar las renovaciones como cargos iniciados por el comercio y evitar el doble factor en cada cobro.
Prueba primero en el entorno de test
Redsys dispone de un entorno de pruebas independiente del real, con sus propias claves. Antes de abrir el cobro a clientes conviene simular ahí un alta de referencia y una renovación completa, comprobando que la firma se valida correctamente y que la notificación de confirmación llega a la tienda. Así detectas errores de configuración sin arriesgar cobros reales ni dejar suscripciones a medias. Recuerda que la clave del entorno de pruebas y la de producción son distintas: cambiarlas al pasar a real es un olvido habitual.
Qué buscar en el plugin
Para que las suscripciones con Redsys en WooCommerce funcionen sin sobresaltos, el conector que uses debe hacer tres cosas bien: dar de alta la referencia en el primer pago, guardarla asociada a la suscripción y lanzar las renovaciones enviando esa referencia con la firma correcta. EHERO WooCommerce Subscriptions integra Redsys recurrente de forma nativa, de modo que la tokenización, el ciclo de renovación y el manejo de la exención SCA vienen resueltos sin plugins intermedios ni parches. Si quieres validar el planteamiento sobre la base de WooCommerce, la documentación oficial de WooCommerce es una buena referencia del comportamiento estándar de la plataforma.
Facturación automática de las renovaciones
Un cobro recurrente genera, cada mes, una obligación contable. Si cada renovación te obliga a emitir una factura a mano, el ahorro de tiempo del cobro automático se pierde en la gestoría. Por eso, cuando gestionas suscripciones con Redsys en WooCommerce, tiene sentido enlazar los cobros con la facturación: cuando una suscripción se renueva y Redsys confirma el cargo, la factura debería emitirse sola. Documentar cada renovación no es solo comodidad: es una obligación fiscal, y automatizar la factura evita olvidos y cuadra los importes con lo realmente cobrado por Redsys. EHERO Woo Holded cubre justamente ese tramo, sincronizando los pedidos de WooCommerce con tu sistema de facturación para que las renovaciones queden documentadas sin intervención manual.
Preguntas frecuentes
¿Puedo usar Bizum para cobrar una suscripción cada mes?
No de forma automática. Bizum no permite tokenizar la tarjeta, así que cada cobro exigiría que el cliente confirmara el pago a mano. Sirve para el primer pago, no para la renovación.
¿El cliente tiene que autenticarse en cada renovación por el SCA?
No. La autenticación reforzada se realiza una sola vez, en el alta de la referencia. Las renovaciones se marcan como cargos iniciados por el comercio y quedan exentas del doble factor.
¿Qué pasa si la tarjeta tokenizada caduca o el banco rechaza el cargo?
La renovación falla y la suscripción queda pendiente de pago. Lo ideal es que el sistema reintente el cobro y avise al cliente para que actualice su tarjeta antes de suspender el servicio.
¿Necesito un TPV virtual especial de mi banco para tokenizar?
Necesitas el mismo TPV de Redsys, pero con la modalidad de pago por referencia habilitada. Es un ajuste que tu banco activa a petición; conviene confirmarlo antes de lanzar las suscripciones.
Conclusión
Montar suscripciones con Redsys en WooCommerce no es complicado cuando entiendes la pieza central: la tokenización o pago por referencia, que convierte un primer pago autenticado en una serie de renovaciones automáticas y conformes con la PSD2. Bizum queda para los pagos puntuales; la recurrencia vive en la tarjeta tokenizada. Si quieres cobrar cuotas cada mes sin fricción, con el respaldo de tu banco español y sin depender de terceros, échale un vistazo a EHERO WooCommerce Subscriptions: integra Redsys recurrente de forma nativa y te ahorra el mayor dolor de cabeza de cualquier negocio de suscripción, que es el cobro que llega, sin fallos, mes tras mes.