Saltar al contenido principal

RF41: Usuario es notificado de renovación o cancelación

Descripción

El sistema notifica al usuario los eventos relevantes de su suscripción: renovación exitosa, próximo cobro, fallo de pago (dunning), cancelación programada y baja efectiva.

Las notificaciones se disparan a partir de webhooks validados de Stripe (invoice.payment_succeeded, invoice.payment_failed, customer.subscription.updated/deleted) y se envían por push y/o email respetando el consentimiento del usuario.

CampoValor
MóduloSubscription Module
ActorSistema (emite) → Usuario (recibe)
EndpointInterno: handler de webhooks + servicio de notificaciones
PrecondicionesWebhook de Stripe válido; usuario con datos de contacto
PrioridadMedia (MVP)
EtapaMVP
Requisitos relacionadosRF38, RF39, RF42, RF45

Reglas de negocio

  • RN-41.1 — Cada notificación se origina en un webhook validado (constructEvent con STRIPE_WEBHOOK_SECRET).
  • RN-41.2 — Eventos notificados: próxima renovación, cobro exitoso, fallo de cobro, cancelación programada, baja efectiva.
  • RN-41.3 — El email/push no incluye datos de tarjeta; solo el dato necesario (plan, fecha, monto del cobro).
  • RN-41.4 — Las notificaciones de marketing requieren opt-in; las transaccionales (cobro/baja) se envían como parte del servicio.

Validaciones de entrada

CampoReglasComportamiento
WebhookFirma válida.Si es inválida, se rechaza y no se notifica.
EventoTipo soportado.Eventos no soportados se ignoran de forma segura.

Criterios de aceptación

Escenario 1: Notificación de renovación exitosa

Dado que Stripe emite invoice.payment_succeeded, Cuando el backend valida el webhook, Entonces se notifica al usuario la renovación con plan, fecha y monto.

Escenario 2: Notificación de fallo de pago

Dado que Stripe emite invoice.payment_failed, Cuando el backend valida el webhook, Entonces se notifica al usuario el fallo y el inicio del dunning con instrucciones para actualizar su método.

Escenario 3: Notificación de cancelación/baja

Dado que la suscripción se cancela o vence (customer.subscription.deleted), Cuando el backend valida el webhook, Entonces se notifica al usuario la baja y la fecha de fin de acceso.

Escenario 4: Webhook con firma inválida (seguridad)

Dado que llega un webhook con firma inválida, Cuando el backend lo procesa, Entonces lo rechaza y no envía ninguna notificación.

Criterios no funcionales

  • Envío asíncrono e idempotente (no duplicar notificaciones por reintentos de webhook).
  • Comunicación TLS 1.2+; sin datos de tarjeta en el contenido.

Diagrama de secuencia