Una baja de cuenta SaaS con periodo de gracia no es una única operación aplazada. Es un flujo de ciclo de vida que debe coordinar acceso, facturación, tareas automáticas, integraciones y datos. Si la aplicación solo guarda una fecha de cierre y la comprueba al iniciar sesión, otros procesos pueden seguir operando como si la organización estuviera activa.
El diseño debe hacer explícito qué significa cada etapa, quién puede realizar una transición y qué efectos son reversibles. Así, cancelar la solicitud no equivale a reconstruir la cuenta desde cero, y alcanzar la fecha límite no depende de que un usuario vuelva a iniciar sesión.
Separar solicitud, suspensión y cierre definitivo
La solicitud expresa una intención: una persona autorizada pide cerrar la cuenta. La suspensión determina qué puede hacer la organización mientras se resuelve esa solicitud. El cierre definitivo ejecuta las acciones finales, que pueden incluir revocar credenciales, detener procesos y aplicar la política de datos. Son momentos distintos y conviene modelarlos por separado.
Una decisión de producto importante es cuándo empieza la restricción de acceso. Si el acceso se mantiene hasta el vencimiento, hay que comunicarlo claramente y controlar el uso durante ese tiempo. Si se restringe de inmediato, el periodo de gracia sirve para recuperar la cuenta, no para seguir utilizando el servicio con normalidad. No hay una opción universal: depende del modelo comercial, los riesgos y las obligaciones del producto.
También deben definirse las consecuencias para la facturación y las suscripciones. La baja de la cuenta no necesariamente cancela una suscripción externa, ni una cancelación de pago debe eliminar una organización. Aclara cuál es la fuente de verdad para cada decisión y evita inferir el estado operativo a partir de un evento aislado del proveedor de pagos.
Definir estados y transiciones permitidas
Un modelo explícito facilita que la interfaz, la API y los trabajos en segundo plano apliquen las mismas reglas. Un flujo sencillo puede usar estados como active, deletion_requested, suspended y closed. Si la suspensión ocurre al mismo tiempo que la solicitud, quizá baste con un único estado de solicitud y atributos que describan sus restricciones. Evita añadir estados que no representen una diferencia operativa real.
Documenta las transiciones válidas. Por ejemplo, una organización activa puede solicitar la baja; una solicitud vigente puede cancelarse; y una solicitud cuyo plazo venció puede pasar a cierre final. En general, una organización cerrada no debería reabrirse mediante la misma acción de cancelación: su recuperación, si se ofrece, necesita un procedimiento distinto y límites claros.
- Registra quién inició la solicitud, cuándo, desde qué canal y cuándo vence el periodo.
- Comprueba permisos y estado actual en el servidor, no solo en la interfaz.
- Rechaza o gestiona explícitamente transiciones repetidas y solicitudes concurrentes.
- Guarda los cambios de estado de forma atómica y publica los efectos secundarios mediante un patrón fiable, como una bandeja de salida transaccional.
En una aplicación PHP, centraliza las reglas de transición en un servicio de dominio o una capa equivalente. Los controladores no deberían cambiar directamente varios campos y asumir que todos los consumidores conocerán la nueva semántica. La base de datos debe conservar suficiente información para que un proceso pendiente pueda determinar qué acción corresponde sin depender del estado de una petición web anterior.
Limitar accesos y contener procesos pendientes
Define las capacidades por rol durante la gracia. Un administrador podría tener permiso para cancelar la baja y consultar información necesaria para exportarla, mientras que miembros de la organización podrían quedar bloqueados. Si se permite acceso de solo lectura, especifica qué recursos cubre y si se mantienen disponibles API, descargas y funciones administrativas. El mismo control debe aplicarse en interfaz, API y trabajos automatizados.
El bloqueo de inicio de sesión no basta. Los tokens de acceso, claves API, sesiones activas y credenciales de integraciones pueden seguir funcionando. Decide cuáles revocar, cuáles poner en pausa y cuáles conservar temporalmente. Si se revocan credenciales, registra el efecto para que la reactivación no dependa de secretos que ya no existen; puede ser necesario exigir que se generen de nuevo.
Revisa colas y tareas programadas: envíos, sincronizaciones, informes, webhooks y trabajos de facturación, por ejemplo. Cada proceso debe comprobar el estado vigente de la organización justo antes de ejecutar una operación con efectos externos. Los trabajos ya encolados pueden cancelarse, quedar en espera o terminar según una política explícita. No asumas que cambiar el estado de la cuenta retira automáticamente mensajes de una cola distribuida.
La cancelación de una tarea también necesita idempotencia. Un trabajo que se reintenta por un fallo de red no debería duplicar una notificación ni una operación de cierre. Usa identificadores de evento, claves de idempotencia o restricciones de unicidad adecuadas, y registra los resultados para distinguir un reintento seguro de una acción nueva.
Hacer que cancelar la baja y reactivar sean seguras
Durante el periodo de gracia, cancelar la solicitud debería ser una transición definida, no una rutina que “deshace todo” sin comprobar qué ocurrió. La operación debe validar que el plazo siga vigente, actualizar el estado una sola vez y restaurar únicamente las capacidades que se habían suspendido y que todavía son válidas.
Para evitar duplicados, no vuelvas a crear de forma indiscriminada suscripciones, webhooks, tareas programadas, espacios de trabajo ni credenciales. Conserva identificadores estables y marca cada efecto secundario con su estado. Si un componente externo ya fue dado de baja, la aplicación debe poder reconciliarlo: confirmar si sigue existiendo, recrearlo de forma controlada o informar de que requiere una acción manual.
Una reactivación idempotente produce el mismo estado final aunque se solicite más de una vez. Esto se puede respaldar con transacciones para los cambios locales, operaciones de actualización en lugar de inserciones ciegas y una estrategia de reintentos para los sistemas externos. Si la operación falla a mitad de camino, registra qué pasos se completaron y permite continuar sin repetir los que ya tuvieron éxito.
Tratar datos, trazabilidad y cierre final
El cierre operativo y la eliminación de datos son decisiones diferentes. Define qué ocurre con los datos de la organización, las copias de seguridad, los registros de auditoría y la información que se conserva por obligaciones legales o contractuales. Los plazos y motivos aplicables dependen del contexto y la jurisdicción; deben revisarse con las personas responsables de privacidad y cumplimiento. Comunica al cliente qué se elimina, qué se conserva y durante cuánto tiempo, según la política aplicable.
Al vencer el periodo de gracia, un proceso programado debe localizar solicitudes pendientes y verificar de nuevo su estado y fecha límite antes de cerrar la cuenta. Si hay un fallo parcial, el sistema necesita registrar el paso fallido y permitir reanudarlo. Una bandera closed no demuestra por sí sola que se hayan revocado credenciales o detenido integraciones.
Conserva trazabilidad de las solicitudes, cancelaciones, cambios de permisos, ejecuciones finales y errores. Limita el acceso a esos registros y evita incluir secretos o datos personales innecesarios. Las alertas deben señalar casos que exceden el tiempo esperado, como organizaciones vencidas aún activas o cierres bloqueados por errores repetidos.
Lista de comprobación para probar el flujo
- Una persona sin permisos no puede solicitar ni cancelar la baja.
- Solicitar la baja dos veces no genera fechas, eventos o cierres duplicados.
- Los roles tienen exactamente las capacidades previstas durante el periodo de gracia.
- Sesiones, tokens, APIs, colas e integraciones respetan el estado de la organización.
- Cancelar antes del vencimiento restaura el acceso previsto sin duplicar procesos ni recursos.
- Una solicitud vencida no se cancela por una petición tardía ni se cierra dos veces.
- Los fallos parciales y reintentos permiten completar el cierre sin repetir efectos externos.
- Las reglas de conservación y eliminación de datos se verifican por separado del bloqueo operativo.
Prueba también cambios simultáneos, retrasos de cola y errores de proveedores externos. La señal de que el diseño es consistente no es solo que la pantalla muestre “cuenta cerrada”, sino que permisos, procesos, credenciales y datos reflejen la misma decisión y que el sistema pueda explicar cómo llegó a ese estado.
