Miles de tiendas con WooCommerce suscripciones renovación automática pierden ingresos sin recibir ninguna alerta. Las renovaciones se procesan en segundo plano vía WP-Cron y Action Scheduler, y cuando algo falla, el sistema simplemente no cobra, no notifica y sigue adelante como si nada.
En 30 segundos
- WooCommerce Subscriptions procesa renovaciones vía WP-Cron + Action Scheduler, completamente server-side, sin sesión del usuario.
- Los errores más comunes son cron deshabilitado, Action Scheduler bloqueado, límites de memoria PHP y claves API de pasarelas expiradas.
- Existe un bug documentado donde renovaciones quedan marcadas como «Processing» sin que se haya cobrado nada, disparando facturación falsa.
- El diagnóstico correcto empieza en WooCommerce > Estado > Acciones programadas, no en los pedidos.
- Desactivar WooCommerce Subscriptions sin cancelar suscripciones primero es pérdida permanente de renovaciones futuras.
WooCommerce es un plugin de WordPress desarrollado por Automattic que permite crear tiendas de comercio electrónico con gestión de productos, pagos e inventario.
La amenaza silenciosa que no te manda ni un mail
WooCommerce Subscriptions es el plugin que gestiona pagos recurrentes dentro del ecosistema WooCommerce. A diferencia de un pago único, una suscripción activa requiere que el servidor ejecute una renovación en la fecha correspondiente, sin que el cliente tenga que hacer nada. Ahí está la trampa.
Cuando una renovación falla en un pago único, el carrito no procesa y el cliente lo ve en el momento. Cuando falla una renovación automática, el sistema puede simplemente no ejecutarla, no reintentar, y no avisarte. El cliente sigue activo en tu base, vos seguís creyendo que cobra, y la plata nunca llega.
Según la documentación oficial de WooCommerce Subscriptions, el 30-35% de los fallos de pago en renovaciones se debe a tarjetas expiradas o modificadas. Pero ese número asume que la renovación siquiera se intentó. El problema más grave es cuando ni siquiera llega a ese punto.
Cómo funcionan las renovaciones automáticas en WooCommerce
El flujo es así: WP-Cron se ejecuta, activa Action Scheduler, Action Scheduler genera una orden de renovación, esa orden se manda a la pasarela de pago, la pasarela procesa (o no), y el estado de la suscripción se actualiza. Todo esto ocurre server-side, sin sesión del usuario activa.
La diferencia entre renovación automática y manual es relevante: en la automática, el plugin tiene guardada la referencia del método de pago y la usa directamente. En la manual, le manda un mail al cliente para que pague. Si tu pasarela no soporta cargo automático (o dejó de soportarlo por algún cambio de configuración), el sistema puede silenciosamente degradar a manual sin avisarte. Lo explicamos a fondo en el ecosistema de WooCommerce.
Las 5 causas raíz de las renovaciones fallidas silenciosas
1. WP-Cron deshabilitado o roto
Si en tu wp-config.php tenés define('DISABLE_WP_CRON', true); y no configuraste un cron real del sistema operativo como reemplazo, WP-Cron no corre nunca. Action Scheduler tampoco. Las renovaciones se encolan pero nadie las procesa. El diagnóstico es simple: revisá si esa constante está presente y, si lo está, verificá que exista un cron job externo que llame a wp-cron.php.
2. Action Scheduler bloqueado
Action Scheduler puede quedar en estado de bloqueo si una acción anterior tardó demasiado o si hay procesos concurrentes. Según la documentación oficial, cualquier acción que supere 5 minutos de ejecución se marca como timeout. Si esto pasa repetidamente, las renovaciones quedan en cola indefinidamente.
3. Límites de memoria PHP insuficientes
Una renovación que falla por falta de memoria no genera un mensaje de error visible en WooCommerce. El proceso simplemente muere. En servidores con memory_limit = 128M o menos, esto pasa más seguido de lo que se cree, especialmente si la tienda tiene plugins pesados o suscripciones con muchos ítems.
4. Pasarelas mal configuradas o con credenciales expiradas
Las claves API de Stripe, PayPal y otras pasarelas tienen ciclos de vida. Si alguien rotó las claves en el panel de la pasarela y no las actualizó en WooCommerce, todas las renovaciones fallan con un error de autenticación. El sistema lo registra en logs, pero si nadie revisa los logs, nadie se entera.
5. Fallos de pago sin reintento configurado
WooCommerce Subscriptions tiene una configuración para reintentar cobros fallidos. Si está en «no reintentar» o si los reintentos llegaron al límite, la suscripción queda activa en tu panel pero sin cobro pendiente. El cliente sigue teniendo acceso, vos seguís sin cobrar.
Problemas específicos por pasarela de pago
Cada pasarela tiene sus propias formas de romperse en silencio.
Stripe: Los débitos SEPA tienen un flujo diferente al de tarjetas. Dependiendo de cómo esté configurado el plugin WooCommerce Gateway for Stripe, una renovación que debería procesarse automáticamente puede convertirse en manual sin aviso. El issue en GitHub tiene reportes de múltiples merchants afectados sin solución definitiva publicada al cierre de este artículo.
PayPal: Las credenciales de API de PayPal Payments Standard expiran o quedan inválidas si el merchant cambia su contraseña o si PayPal detecta actividad inusual. Las renovaciones fallan con error 401, que queda en logs pero no genera notificación. Relacionado: integración de WooCommerce y WordPress.
Redsys: El sistema de pagos bancario español (muy usado en tiendas argentinas con pasarelas locales similares) requiere configuración explícita de webhooks. Si el webhook no está activo, la pasarela puede procesar el cobro pero WooCommerce nunca recibe confirmación y la suscripción queda en estado pendiente.
El bug de caché: renovaciones marcadas como pagadas sin serlo
Este es el más peligroso. Reportado en el repositorio oficial de woocommerce-subscriptions-core, existe un escenario donde una renovación queda marcada como «Processing» sin que se haya cobrado nada. El flujo roto es: WP-Cron dispara la renovación, el proceso genera la orden, pero antes de que la pasarela confirme el cobro, una capa de caché o un proceso concurrente marca la orden como completada.
¿Y qué pasó cuando lo desplegaron en producción? El sistema de facturación del merchant disparó facturas para pagos que nunca existieron. Los clientes recibían facturas de cobros que no se les habían debitado. Cuando el merchant intentaba reconciliar, los números no cerraban.
El issue 764 en el mismo repositorio documenta variantes del mismo problema con pagos manuales combinados con caché agresivo. La solución parcial es deshabilitar el caché para páginas de checkout y páginas de cuenta, pero no resuelve el problema a nivel de Action Scheduler.
Cómo diagnosticar renovaciones fallidas antes de perder dinero
La ruta correcta para diagnosticar no es mirar pedidos. Es ir directo a las acciones programadas.
- Accedé a WooCommerce > Estado > Acciones programadas (o WooCommerce > System Status > Scheduled Actions en inglés).
- Filtrá por «Fallido» o «Pendiente» para ver acciones que no se ejecutaron.
- Buscá por número de suscripción para rastrear una renovación específica.
- Revisá el timestamp: si una acción figura como pendiente con fecha de hace más de 24 horas, no se ejecutó.
- Para acciones con timeout (>5 minutos), revisá el log de la acción en el detalle de cada entrada.
El segundo paso es revisar los logs del servidor. En /wp-content/woocommerce/logs/ vas a encontrar archivos con errores de pasarelas, de Action Scheduler y de WP-Cron. Si esos archivos están vacíos o no existen, puede ser que el logging esté desactivado o que los errores estén ocurriendo antes de que WooCommerce pueda registrarlos (un fallo de memoria, por ejemplo).
Para tiendas en hostings compartidos, Donweb y proveedores similares suelen ofrecer acceso a logs de PHP desde el panel de control. Revisá esos logs también, especialmente si sospechás de fallos de memoria.
Soluciones inmediatas y mejores prácticas
Arrancá por lo más simple: verificar que WP-Cron esté activo. Abrí wp-config.php y buscá DISABLE_WP_CRON. Si está en true, configurá un cron job real que ejecute wget -q -O - https://tutienda.com/wp-cron.php?doing_wp_cron cada 5 minutos. Para más detalles técnicos, mirá proteger infraestructura de renovaciones.
Para el memory limit, el mínimo recomendado para tiendas con suscripciones es 256M. Idealmente 512M si tenés muchos pedidos concurrentes. Agregá define('WP_MEMORY_LIMIT', '256M'); en wp-config.php si tu hosting lo permite.
Respecto a las pasarelas, la guía de diagnóstico de Fountain City recomienda revisar cada pasarela activa al menos mensualmente: credenciales vigentes, webhooks activos, y logs de los últimos 30 días sin errores 401 o 403.
Para monitoreo proactivo, el plugin WooCommerce Subscriptions incluye un logger de renovaciones que podés activar desde la configuración avanzada. Activalo. También podés configurar alertas por mail en WooCommerce para notificarte cuando una renovación falla, algo que por defecto no está habilitado en todas las versiones.
| Problema | Síntoma visible | Solución |
|---|---|---|
| WP-Cron deshabilitado | Acciones en cola sin ejecutar por días | Cron real del OS o verificar DISABLE_WP_CRON |
| Límite de memoria PHP | Action con timeout, sin error en WC logs | Subir memory_limit a 256M o 512M |
| Credenciales de pasarela expiradas | Error 401/403 en logs de pasarela | Actualizar claves API en configuración de WC |
| Bug de caché en renovaciones | Órdenes en «Processing» sin cobro real | Deshabilitar caché en checkout, actualizar plugin |
| Webhook no configurado | Cobro procesado pero suscripción no actualizada | Configurar endpoint de webhook en panel de pasarela |
| Sin reintento configurado | Suscripción activa, sin cobro, sin alerta | Activar reintentos en WC Subscriptions settings |

Cuándo desactivar WooCommerce Subscriptions (y cuándo no)
Hay una advertencia que muy poca gente conoce hasta que la vive: si desactivás WooCommerce Subscriptions temporalmente para resolver un problema, perdés todas las renovaciones programadas para ese período. No se reintentan. No se recuperan.
Si necesitás desactivar el plugin por alguna razón (conflicto, actualización problemática, lo que sea), el paso previo obligatorio es ir a cada suscripción activa y cambiar su estado a «On Hold» o cancelarla. Después podés desactivar. Cuando reactives, tenés que reactivar manualmente cada suscripción.
Los casos legítimos para desactivar son pocos: conflicto crítico confirmado con otro plugin, proceso de migración planificada, o resolución de un bug activo que afecta cobros. Todo lo demás se resuelve con el plugin activo. Tema relacionado: cómo migrar tu tienda sin riesgos.
Errores comunes que multiplican el daño
Mirar pedidos en vez de suscripciones. Un pedido de renovación puede existir como borrador sin haberse cobrado. El estado real de una suscripción se ve en la sección Suscripciones, no en Pedidos. Si revisás solo pedidos, podés creer que todo está bien cuando no lo está.
Confiar en los mails de confirmación como único indicador. Si el sistema de mail de tu hosting tiene problemas, los mails de renovación no llegan ni a vos ni al cliente. Eso no significa que la renovación se procesó. El estado en la base de datos es la fuente de verdad.
Actualizar WooCommerce sin revisar el changelog de Subscriptions. El plugin WooCommerce Subscriptions tiene su propio ciclo de versiones, separado del core de WooCommerce. Una actualización de WooCommerce puede romper compatibilidad con una versión desactualizada de Subscriptions. Según el análisis de Seresa.io, este es uno de los vectores más frecuentes de pérdida silenciosa de datos en tiendas con suscripciones.
Preguntas Frecuentes
¿Por qué mis renovaciones automáticas de WooCommerce fallan sin alertas?
El sistema de WooCommerce suscripciones renovación automática opera server-side sin notificaciones activas por defecto. Los fallos quedan registrados en logs que nadie revisa si no configura alertas explícitas. Activá las notificaciones de renovación fallida en WooCommerce > Ajustes > Emails y revisá el Action Scheduler semanalmente.
¿Cuáles son los errores más comunes en WooCommerce Subscriptions?
Los más frecuentes son WP-Cron deshabilitado, límites de memoria PHP por debajo de 256M, credenciales de pasarela de pago expiradas, y webhooks no configurados. El bug de caché que marca renovaciones como «Processing» sin cobro real es menos común pero más difícil de detectar porque no genera error visible.
¿Cómo verificar si las renovaciones se están procesando correctamente?
Accedé a WooCommerce > Estado > Acciones programadas y filtrá por acciones fallidas o pendientes con fecha anterior. Si encontrás acciones de renovación con más de 24 horas en estado pendiente, no se están ejecutando. Complementá con la revisión de logs en /wp-content/woocommerce/logs/.
¿Qué causa la pérdida silenciosa de ingresos por suscripciones?
La combinación de tres factores: renovaciones que no se ejecutan, sin notificación automática al merchant, y suscripciones que permanecen activas en el sistema. El cliente tiene acceso al producto o servicio, pero el cobro nunca ocurrió. Sin monitoreo activo del Action Scheduler, esto puede acumularse durante semanas.
¿Qué pasa si desactivo WooCommerce Subscriptions temporalmente?
Perdés todas las renovaciones programadas para el período en que el plugin estuvo inactivo. No se reintentan ni se recuperan automáticamente. Antes de desactivarlo, cambiá el estado de todas las suscripciones activas a «On Hold» para preservar los datos. Reactivar el plugin después no restaura las renovaciones perdidas.
Conclusión
El problema con WooCommerce suscripciones renovación automática no es que el plugin sea malo. Es que fue diseñado para operar sin intervención humana, y esa misma característica lo hace opaco cuando algo se rompe. Las renovaciones fallan en silencio porque el sistema asume que si no hay error, todo está bien, cuando en realidad puede haber una cola de acciones que nunca se ejecutaron.
La solución no requiere cambiar de plataforma ni de pasarela. Requiere monitoreo activo: revisar Action Scheduler semanalmente, configurar alertas de renovación fallida, y verificar credenciales de pasarelas cada mes. Si tenés más de 50 suscripciones activas, considerá un plugin de diagnóstico dedicado. El costo de una revisión mensual es infinitamente menor al de descubrir seis semanas de renovaciones perdidas.
Fuentes
- WooCommerce – Proceso de renovaciones automáticas (documentación oficial)
- WooCommerce – Errores de acciones programadas en Subscriptions
- GitHub – Bug: renovaciones marcadas como Processing sin cobro (woocommerce-subscriptions-core #707)
- Seresa.io – Análisis de pérdida silenciosa de ingresos en WooCommerce Subscriptions
- WooCommerce – Problemas comunes y mensajes de error en Subscriptions