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 → A | Disparado por |
|---|---|
active → cancelled | Tu DELETE /v1/subscriptions/{subUid} (inmediato) |
active → inactive | Reintentos de cobro agotados (cron, automático) |
active → expired | Suscripció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.