Cuando el navegador cancela tus membresias depurando woocommerce memberships y chrome

Cuando el navegador cancela tus membresías: depurando WooCommerce Memberships y Chrome

En Zonsai solemos encontrarnos con casos curiosos, pero este merece capítulo propio:
membresías de WooCommerce que se cancelaban solas, sin que nadie hiciera clic, y además de forma aparentemente aleatoria.

En este artículo cuento el proceso completo: desde los primeros síntomas hasta el diagnóstico final, incluyendo pruebas, hipótesis descartadas, descubrimientos inesperados y la solución definitiva.
No menciono al cliente, pero sí los plugins implicados y las lecciones que nos llevamos.

El síntoma: planes que se cancelan “de la nada”

El escenario inicial incluía:

WordPress + WooCommerce
WooCommerce Memberships para gestionar planes
Gravity Forms + User Registration para registrar usuarios
Un flujo B2B donde el usuario recibía una membresía base y luego podía “subir de nivel” con un código

Todo funcionaba bien hasta que, tras navegar unas cuantas páginas, algunas membresías aparecían como “cancelled” sin que el usuario hubiera hecho nada.

Incluso creando la membresía a mano desde el backend, sin formularios de por medio, también terminaba cancelada.

Primera sospecha: nuestro propio plugin

El proyecto tenía un pequeño plugin a medida para asignar la membresía base y permitir que un código B2B cambiara la membresía del usuario.
Revisamos toda la lógica, desactivamos el plugin e incluso eliminamos los hooks que podían cancelar planes.

El problema seguía ocurriendo.

Comparando usuarios: backend vs formulario

Descubrimos un patrón curioso:

Usuarios creados manualmente en WordPress → la membresía se mantenía estable.
Usuarios creados mediante Gravity Forms → la membresía a veces se cancelaba sola.

Para confirmar diferencias creamos una herramienta interna para mostrar todos los metadatos de dos usuarios.
Y sorprendentemente…

No había ninguna diferencia significativa que explicara la cancelación.

Así que seguimos investigando.

Nueva pista: mirar dentro de la membresía (no del usuario)

Las membresías en WooCommerce son posts propios con su propia información interna:
fecha de inicio, pausas, fecha de cancelación, etc.

Comparando dos membresías (una correcta y una problemática), vimos que:

La membresía problemática tenía un _cancelled_date registrado.
Tenía además intervalos de pausa que el usuario jamás había activado.

Era evidente: alguien o algo estaba ejecutando la acción de cancelar.

La URL maldita

WooCommerce Memberships permite que un usuario cancele su propia membresía con una URL parecida a:

/mi-cuenta/?cancel_membership=ID&_wpnonce=XXXX

Esto por sí mismo ya es arriesgado, porque:

Es una acción destructiva
Se ejecuta mediante una simple URL GET
No hay confirmación adicional

Pero entonces apareció la pieza clave que faltaba.

El verdadero culpable: Chrome prefetch

Tras muchas pruebas, vimos que sólo ocurría en los ordenadores donde el navegador —concretamente Chrome— realizaba procesos de predicción y precarga de enlaces.

Es decir:

Chrome detectaba el enlace “Cancelar” y, sin que nadie hiciera clic, abría la URL por adelantado.

Lo hacía para acelerar la navegación… pero al abrir esa URL, WooCommerce interpretaba que el usuario había ordenado cancelar su membresía.

Para complicarlo aún más:

Cuando el inspector estaba abierto, Chrome dejaba de hacer prefetch → por eso en nuestras pruebas “desaparecía”.
Dependía de la versión exacta del navegador.
Dependía de extensiones y del hardware.

Una tormenta perfecta.

La solución: bloquear la cancelación desde el frontend

Como no podemos controlar lo que hace Chrome, la solución debe estar en el servidor.

Implementamos una protección que evita que cualquier usuario pueda cancelar su membresía desde el frontend.

Solo un administrador, desde el backend, puede hacerlo.

El resultado:

Chrome ya no puede disparar accidentalmente la acción.
Los usuarios ya no pueden “accidentalmente” cancelar sus propios planes.
El sistema es mucho más robusto.

Desde ese momento, ninguna membresía volvió a cancelarse automáticamente.

Lecciones que nos llevamos

Este caso nos deja varias conclusiones importantes:

Las acciones críticas no deben depender de enlaces GET.
Los navegadores modernos ya no son pasivos: toman decisiones por ti.
El bug visible no siempre está donde crees.
A veces lo provoca algo externo al propio WordPress.
Conviene auditar cualquier URL que ejecute acciones sensibles:
cancelar membresías, borrar, vaciar, dar de baja…