Cómo probar las renovaciones de suscripción de WooCommerce (sin perder el sueño ni el dinero)

Puntos clave

• Probar las renovaciones de suscripción antes del lanzamiento evita perder entre un 10 % y un 15 % de los ingresos por pagos automáticos fallidos que los clientes nunca notan.
• Tanto la prueba manual de renovaciones como la ejecución de acciones programadas en WooCommerce son necesarias para detectar distintos tipos de fallos.
• Los relojes de prueba de Stripe (Test Clocks) te permiten adelantar el tiempo y probar meses de ciclos de renovación en minutos, en lugar de esperar a las fechas reales.
• La configuración de los webhooks es crítica (las renovaciones pueden procesarse correctamente en Stripe, pero tu sitio nunca recibe la confirmación).
• Las suscripciones de aplicaciones móviles en Apple y Google requieren pruebas de sandbox separadas, con ciclos de tiempo comprimidos y casos límite específicos de cada plataforma.

Ahí estaba yo, a las 2 de la madrugada, mirando fijamente la pantalla de mi portátil. Mi servicio de suscripción acababa de procesar su primer gran lote de renovaciones. De 50 clientes que debían renovar, solo lo hicieron 32.

¿Los otros 18? Silencio absoluto. Sin mensajes de error, sin avisos, nada. Solo 2000 $ escapándose por la puerta mientras yo dormía.

Esa pesadilla me enseñó algo importante. Probar las renovaciones de suscripción no es una función opcional que añades después. Es la diferencia entre construir un negocio real y ver cómo el dinero desaparece cada mes.

Voy a mostrarte exactamente cómo pruebo ahora las renovaciones. Estos métodos funcionan tanto si usas WooCommerce, Stripe, o si gestionas suscripciones móviles a través de Apple y Google.

Sáltate estos pasos y lo aprenderás de la manera cara, como me pasó a mí.

Por qué esto importa de verdad (más allá de lo obvio)

Mira, todo el mundo sabe que las renovaciones fallidas son malas. Pero esto es lo que me sorprendió: la mayoría de los negocios pierde entre un 10 % y un 15 % de sus ingresos por renovaciones que deberían haber funcionado.

No hablamos de personas que deciden cancelar. Estos son clientes que literalmente quieren seguir pagándote, pero algo falla y no pueden.

Piensa en los números un segundo. Conseguir clientes nuevos cuesta mucho más que conservar a los que ya tienes. Algunos expertos dicen que es 5 veces más caro, otros dicen que 7 veces.

De cualquier forma, cada renovación que falla por un problema técnico es como tirar dinero a la basura.

Cuando configuras correctamente las pruebas automatizadas de renovación, básicamente estás comprando un seguro para tu fuente de ingresos más importante. Y a diferencia de un seguro real, este paga constantemente.

Probar las renovaciones de WooCommerce: empieza aquí

Si gestionas un sitio WooCommerce (y son muchísimos), tienes dos formas principales de probar las renovaciones. Déjame guiarte por ambas, empezando por la más fácil.

Método 1: la prueba manual rápida

WooCommerce tiene un botón llamado “Procesar renovación” que te permite probar las cosas manualmente. Así es como lo uso:

Lo primero, crea una suscripción de prueba. Configúrala para que se renueve cada día en lugar de mensualmente; esto te ahorra tener que esperar eternamente. Inicia sesión en WordPress, ve a WooCommerce, busca Subscriptions y localiza tu suscripción de prueba.

Verás un botón que dice “Procesar renovación” justo ahí. Haz clic en él. WooCommerce intenta cobrar la tarjeta de inmediato. Observa qué pasa. ¿Funciona el pago? ¿Se actualiza el estado? ¿Se envían los correos?

Aquí es donde la mayoría se equivoca: prueban una vez con una tarjeta que funciona y lo dan por terminado. Eso no es suficiente. Necesitas probar lo que se rompe:

Intenta procesar con una tarjeta caducada. Mira qué pasa. Luego prueba con una tarjeta que es rechazada. Comprueba si tu sistema lo maneja correctamente. Prueba tanto en modo de prueba como en modo real, porque pueden comportarse de forma distinta.

También pruebo suscripciones con distintos periodos de facturación y periodos de prueba. El mes pasado encontré un error donde nuestro sistema no enviaba correos cuando las tarjetas caducaban. Solo lo detecté porque estaba probando estos casos límite deliberadamente.

Método 2: acciones programadas (la prueba de verdad)

Las pruebas manuales están bien, pero no te muestran qué pasa cuando las renovaciones se ejecutan automáticamente a las 3 de la madrugada mientras duermes. Ahí es donde entran las Scheduled Actions (acciones programadas).

Ve a WooCommerce, luego a Estado, luego a Acciones programadas. Este es básicamente el panel de control de todo lo que WooCommerce hace automáticamente.

Crea una suscripción de prueba que se renueve en 2 horas. Luego observa la página de Acciones programadas. Deberías ver una acción programada llamada “woocommerce_scheduled_subscription_payment” para esa hora de renovación.

Aquí está el truco: no esperes 2 horas. Simplemente haz clic en “Ejecutar” junto a esa acción, y se ejecuta ahora mismo. Esto prueba exactamente lo que pasará en producción, incluyendo todo tu código personalizado y tus plugins.

Mira qué estado muestra después de ejecutarse. “Completo” significa éxito. “Fallido” significa que algo se rompió, y obtendrás registros que muestran qué salió mal. Yo llevo una hoja de cálculo rastreando cada acción fallida y por qué falló. Se ha convertido en mi biblia de depuración durante el último año.

Pruebas con Stripe: más allá de las simples tarjetas de prueba

Stripe es enorme en el mundo de las suscripciones. Sus herramientas de prueba son en realidad muy potentes, pero la mayoría de los desarrolladores solo usan las tarjetas de prueba básicas y se pierden lo bueno.

Los Test Clocks lo cambiaron todo

Stripe tiene una función llamada Test Clocks que básicamente te permite viajar en el tiempo. En lugar de esperar 30 días para ver si funciona una renovación mensual, simplemente adelantas el tiempo y listo, sucede al instante.

Configurarlo es fácil. Ve a tu panel de Stripe en modo de prueba. Busca Developers, luego Test Clocks. Crea un nuevo reloj y ponle un nombre como “Prueba de renovación mensual”.

Ahora, crea clientes de prueba y asócialos a este reloj. Cuando adelantas el reloj 30 días, Stripe procesa todas las renovaciones que habrían ocurrido en ese tiempo. Puedo probar todo mi sistema de renovación en 15 minutos usando esto.

Un consejo profesional que nadie menciona: crea relojes de prueba separados para diferentes escenarios. Yo tengo uno para renovaciones exitosas, uno para fallos y uno para tarjetas que caducan a mitad de ciclo.

Probarlos todos a la vez detecta problemas que nunca encontrarías probando uno por uno.

Tarjetas de prueba que realmente funcionan

Stripe te da números de tarjeta específicos para probar diferentes escenarios. Aquí está mi lista esencial:

4242 4242 4242 4242 - Esta es tu tarjeta de éxito. Toda renovación debería funcionar con esta.

4000 0000 0000 0002 - Esta tarjeta es rechazada. Tu sistema debería manejarlo con fluidez y enviar los correos correctos.

4000 0000 0000 9995 - Simula fondos insuficientes. Esto es diferente a un rechazo normal y necesita una mensajería distinta para el cliente.

4000 0000 0000 0069 - Tarjeta caducada. Esto pasa constantemente en la vida real y tu sistema necesita detectarlo.

Pruebo cada tarjeta tres veces: en el registro, en la primera renovación y después de varios ciclos de facturación. El sistema puede comportarse de forma distinta según la antigüedad de la suscripción.

Los webhooks son críticos (no te saltes esto)

Aquí hay algo que me mordió fuerte: tus renovaciones pueden funcionar perfectamente en Stripe, pero si los webhooks no están bien configurados, tu app nunca se entera. A los clientes se les cobra, pero no obtienen acceso. Un desastre.

Instala Stripe CLI y ejecuta este comando: stripe listen --forward-to localhost:3000/webhook

Esto envía los eventos de Stripe directamente a tu ordenador. Activa algunas renovaciones de prueba y observa cómo llegan los eventos. Deberías ver “invoice.payment_succeeded” para las exitosas e “invoice.payment_failed” para los fallos.

Si esos eventos no aparecen, nada más importa. Tu sistema en producción no funcionará sin importar lo bueno que sea tu código.

Guardo registros de cada webhook durante las pruebas. Cuando algo se rompe en producción, comparo los webhooks de producción con mis registros de prueba. Esto probablemente me ha salvado unas 50 veces hasta ahora.

Las apps móviles son diferentes (Apple y Google)

Probar renovaciones en aplicaciones móviles es un dolor de cabeza propio. Apple y Google tienen cada uno peculiaridades raras que necesitas conocer.

Las pruebas de Apple son raras pero útiles

El entorno Sandbox de Apple comprime el tiempo de formas extrañas. Las suscripciones mensuales se renuevan cada 5 minutos. Las anuales se renuevan cada hora. Suena conveniente, ¿verdad? Pero crea problemas.

Tu app puede necesitar manejar 12 renovaciones en una hora durante las pruebas. Esto puede exponer problemas de limitación de tasa (rate-limiting) que nunca verías en producción, donde las renovaciones están repartidas en el tiempo.

Crea múltiples cuentas de prueba de sandbox con distintos estados. Yo tengo cuentas para nuevos suscriptores, suscriptores a mitad de ciclo, métodos de pago caducados, periodos de gracia y personas que han renovado varias veces.

Prueba las mejoras y degradaciones de plan de forma exhaustiva. La lógica de prorrateo de Apple es confusa. ¿Se cobra al cliente de inmediato al mejorar de plan? ¿Cambia su fecha de renovación? Necesitas verificar todo esto con pruebas reales.

Google Play tiene sus propias reglas

Las pruebas de Google son más directas, pero aun así tienen trampas. Puedes crear cuentas de prueba que pasan por todo el flujo de suscripción sin cargos reales.

Configura las pruebas de licencia en Google Play Console. Ve a Configuración, luego a Pruebas de licencia. Añade cuentas de Gmail de prueba que puedan hacer compras sin cargos.

Aquí es donde me atraparon: Google Play tiene estados de suscripción que Apple no tiene. Una suscripción puede estar “en espera” (on hold), donde el cliente conserva el acceso, pero las renovaciones se pausan. Es probable que tu app todavía no maneje esto, así que pruébalo específicamente.

Usa las notificaciones servidor a servidor de Google. Le dicen a tu backend de inmediato cuando las renovaciones tienen éxito o fallan. Configura un endpoint de prueba que registre todo. Los datos de la notificación incluyen detalles de la suscripción que no encontrarás en ningún otro lugar.

Pruebas avanzadas para negocios serios

Una vez que domines lo básico, estas técnicas avanzadas blindarán tu sistema de renovación.

Facturación en sombra (shadow billing) en producción

Esto suena complicado, pero es sencillo. Cada vez que una renovación real está a punto de procesarse, ejecuta también una renovación de prueba en paralelo usando un método de pago de prueba. Ambas pasan por el mismo código, pero solo la real cobra al cliente.

Compara los resultados. Si la renovación en sombra falla pero la real tiene éxito (o viceversa), sabes que algo específico del entorno está roto. Esto ha detectado errores exclusivos de producción que habría sido imposible encontrar en staging.

Pruebas de carga en tus webhooks

Tu endpoint de webhook puede manejar 10 renovaciones por hora. Pero ¿qué pasa con 1000 renovaciones a la vez? Esto sucede cada mes cuando las suscripciones se renuevan por lotes.

Usa webhook.site para simular un volumen alto. Graba tu webhook de renovación típico, luego repítelo 100 veces en 10 segundos.

¿Tu endpoint las maneja todas? ¿Se pierde alguna? ¿Se bloquea tu base de datos? Responde estas preguntas antes de que llegue tu gran día de renovaciones.

Ingeniería del caos (rompe cosas a propósito)

Esto en realidad es divertido. Durante las pruebas, rompe cosas al azar para ver cómo responde tu sistema.

Corta la conexión a la base de datos a mitad de una renovación. Simula tiempos de espera agotados de la pasarela de pago. Corrompe los datos del webhook. Tu sistema debería manejar todo esto con elegancia y reintentar de forma adecuada.

Ejecuta pruebas de caos mensualmente en staging. Cada fallo que descubras se convierte en un caso de prueba permanente. Este enfoque me ha evitado muchísimos desastres en producción.

El diagrama de flujo de depuración que necesitas

Cuando una renovación falla en producción, sigue exactamente este diagrama de flujo:

Paso 1: revisa los registros de la pasarela de pago. ¿Llegó siquiera el pago a la pasarela? Si no, el problema está en tu código antes del intento de pago.

Paso 2: verifica la entrega del webhook. ¿Lo envió la pasarela? ¿Lo recibió tu endpoint? ¿Se procesó? Muchas “renovaciones fallidas” son en realidad fallos de webhook.

Paso 3: revisa el estado de la suscripción en tu base de datos. ¿Coincide con lo que muestra la pasarela? Las discrepancias significan problemas de sincronización.

Paso 4: revisa los métodos de pago del cliente. ¿Está caducada la tarjeta? ¿Coincide la dirección? ¿El banco la está bloqueando? Esto causa la mayoría de los fallos.

Paso 5: revisa tus registros de errores. Busca excepciones, tiempos de espera agotados o límites de tasa alrededor de la hora de la renovación.

Imprimí este diagrama de flujo y lo pegué en mi pared. Incluso después de años de experiencia, a veces olvido pasos al resolver problemas bajo presión.

Errores que todos cometen

Déjame compartir los errores que veo constantemente, incluso en desarrolladores experimentados.

Error 1: probar solo las renovaciones exitosas. La mayoría de la gente solo prueba el camino feliz. Pero entre un 10 % y un 20 % de las renovaciones fallan por diversas razones. Si no pruebas los fallos, no estás probando de verdad.

Error 2: ignorar las zonas horarias. Tu servidor puede estar en UTC, pero tu procesador de pagos usa PST. He visto renovaciones procesarse a horas completamente equivocadas por errores de zona horaria. Prueba específicamente las renovaciones programadas para medianoche; a los problemas de zona horaria les encanta esa hora.

Error 3: saltarse las pruebas de prorrateo. Cuando los clientes cambian de plan a mitad de ciclo, el prorrateo se complica. Prueba las mejoras y degradaciones en diferentes puntos del ciclo. Las cuentas siempre deberían cuadrar perfectamente.

Error 4: no comprobar la entregabilidad del correo. Tus correos de renovación pueden verse perfectos en las pruebas, pero terminar en spam para los clientes reales. Envía correos de prueba a Gmail, Outlook y Yahoo. Revisa las carpetas de spam.

Error 5: probar solo con tu propia cuenta. Tu cuenta probablemente tiene ajustes especiales. Crea cuentas de prueba nuevas que reflejen las experiencias reales de los clientes.

Tu lista de verificación de 15 escenarios de prueba

Antes de lanzar, prueba estos 15 escenarios. He usado esta misma lista para cada producto de suscripción que he construido.

1. Renovación mensual estándar con pago válido

2. Renovación anual después de 12 meses

3. Renovación con tarjeta que caduca este mes

4. Renovación con fondos insuficientes

5. Renovación que activa la prevención de fraude

6. Renovación durante el mantenimiento de la pasarela

7. Renovación cuando el endpoint del webhook está caído

8. Múltiples renovaciones simultáneas

9. Renovación justo después de mejorar de plan

10. Renovación justo después de degradar de plan

11. Primera renovación tras finalizar la prueba

12. Renovación con método de pago actualizado

13. Reintento tras un fallo inicial

14. Renovación con direcciones de facturación y envío diferentes

15. Renovación en una moneda distinta a la del registro

Prueba cada uno al menos dos veces. Documenta el comportamiento esperado frente al real. Cualquier diferencia es un error que hay que corregir.

Después del lanzamiento: sigue probando

Tus pruebas no terminan en el lanzamiento. De hecho, es entonces cuando empieza el monitoreo más crítico.

Configura alertas para las renovaciones fallidas. Yo uso una regla sencilla: si más del 5 % de las renovaciones fallan en cualquier hora, recibo un mensaje de texto de inmediato. Esto ha detectado problemas antes de que se convirtieran en desastres.

Crea un panel diario que muestre los intentos totales, la tasa de éxito, las razones de fallo, el éxito de los reintentos y los ingresos recuperados. Revísalo cada mañana. Surgirán patrones que nunca detectarías con revisiones ocasionales.

Ejecuta tu suite completa de pruebas contra producción mensualmente usando cuentas de prueba. Los sistemas se desvían con el tiempo. Las dependencias se actualizan, las pasarelas de pago cambian sus APIs, aparecen errores. Las pruebas regulares detectan cambios antes de que los clientes los sufran.

Usa un rastreo de errores que agrupe los fallos por causa raíz. Yo uso Sentry y categoriza automáticamente cosas como tarjetas caducadas, fondos insuficientes y tiempos de espera agotados de la pasarela. Esto ayuda a priorizar las correcciones.

Empieza a probar hoy

Esto es lo que debes hacer ahora mismo: abre tu sistema de suscripción y prueba los primeros cinco escenarios de mi lista de verificación. No planifiques, no leas más adelante, simplemente prueba esos cinco hoy.

Mañana, prueba cinco más. Al final de la semana, habrás validado todo tu sistema de renovación. Dormirás mejor sabiendo que las renovaciones realmente funcionarán a las 3 de la madrugada.

Probar las renovaciones no es algo que se hace una sola vez. Es una práctica continua que protege tu métrica más importante: los ingresos recurrentes. El tiempo que inviertas se recupera muchas veces en cancelaciones evitadas e ingresos ahorrados.

Tu yo futuro te lo agradecerá. Ahora ve a probar esas renovaciones antes de que tus clientes encuentren los errores por ti.