Saltar al contenido principal
Migo Docs

Ciclo de Vida de la Suscripción

Una suscripción tiene exactamente cuatro estados: active, cancelled, expired e inactive.

┌──────────────┐
│ active │
└──────┬───────┘

┌──────────────┼──────────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ cancelled│ │ inactive │ │ expired │
└──────────┘ └──────────┘ └──────────┘

Transiciones — quién dispara qué

De → ADisparado por
active → cancelledTu DELETE /v1/subscriptions/{subUid} (inmediato)
active → inactiveReintentos de cobro agotados (cron, automático)
active → expiredSuscripción de plazo fijo que llegó a su fin

No existen los estados trialing, past_due, unpaid ni paused, por lo que no hay transiciones de fin de prueba, pausa/reanudación, cambio de plan ni prorrateo.

Cambios de plan y prorrateos

La API actual no soporta cambiar el plan de una suscripción ni prorratear a mitad de ciclo. PUT /v1/subscriptions solo actualiza el email de notificación (ver Suscripciones → Actualizar).

Cancelación

La cancelación es inmediata: DELETE /v1/subscriptions/{subUid} define el estado de la suscripción en cancelled. No existen los modos cancelAt, immediate ni period_end, ni el concepto de currentPeriodEnd.

Cobros fallidos

Cuando un cobro programado falla, los reintentos se gobiernan por plan mediante dailyAttempts e intervalAttempt (más una ventana opcional graceDays). Una vez agotados los intentos, la suscripción transiciona a inactive. Ver Cobros programados → Calendario de reintentos.

Reactivación

Una suscripción cancelled o inactive no puede des-cancelarse ni reactivarse a través de la API. Se crea una nueva suscripción vía el flujo verify-card con shouldCreateSubscription: true, ligado a una nueva transacción.

Notificaciones

El flujo de suscripción envía notificaciones por email (notifyEvent) y un callback al comercio (subsCallback) en lugar de un contrato público de webhook saliente. Ver Suscripciones → Notificaciones.