Política de Reembolsos InboMarket — v1.0

Para: Customer Success + SuperAdmin + Legal Counsel + Tenants De: ATHENA — Asistente Ejecutiva Estratégica 🏛️📊⚖️ Fecha: 2026-06-03 Decisión asociada: Decisión firmada #60 (catálogo v4.7 sección 6.17) Estado: APROBADO por Gabriel Brens

---

0. Principio rector

NO hay money-back guarantee general. El Trial 14 días (30 días beta) ES la garantía. Sin embargo, hay 9 escenarios específicos con políticas de reembolso definidas.

---

1. Los 9 escenarios

Escenario 1: Cancelación voluntaria mid-cycle

Caso: Tenant Agency $97 paga mes 1, cancela día 15 del mes 2.

Política: Sin refund. La plataforma sigue funcional hasta el fin del ciclo pagado. Después: estado GRACE → SUSPENDED → ANONIMIZADO (política 4 estados sección 6.10).

Quién decide: Self-service vía dashboard tenant.

Implementación:

• Botón "Cancelar suscripción" en MySubscriptionPage
• Modal de confirmación con explicación de los 4 estados
• Ventana "Oops" 24h para revertir
• Email de confirmación al tenant

---

Escenario 2: Cargo erróneo de InboMarket (bug billing)

Caso: Sistema cobra doble por error de código.

Política: Refund completo + 1 mes gratis de compensación.

Quién decide: Customer Success (revisión manual).

Implementación:

• Ticket categoría TENANT_SUPPORT_BILLING con tag BILLING_BUG
• CS verifica vs audit log
• Si confirmado → refund vía Stripe API + crédito 1 mes en próxima factura
• Audit log de la decisión

---

Escenario 3: Tenant anual con descuento cancela mes 3

Caso: Tenant pagó $97 × 12 con 20% descuento ($930 total). Cancela mes 3.

Política: Pro-rata refund de meses no utilizados.

Cálculo:

• Pagado: $930
• Consumido (3 meses al precio mensual normal $97): $291
• Refund: $930 - $291 = $639

Quién decide: Self-service vía Stripe portal.

Implementación:

• Stripe Customer Portal habilitado para auto-cancelación
• Webhook procesa el evento + emite e-CF de anulación parcial DGII

---

Escenario 4: Fraude reportado (cuenta clonada/hackeada)

Caso: Tenant reporta que su cuenta fue accedida por terceros y se hicieron compras.

Política: Refund completo + investigación.

Quién decide: SuperAdmin (no self-service).

Implementación:

• Ticket categoría SECURITY_INCIDENT
• SuperAdmin revisa audit log (login IPs, user agents)
• Si confirmado → refund + reset credentials + 2FA forzado
• Reporte al banco emisor del tenant si hay disputa

---

Escenario 5: Chargeback iniciado en banco/tarjeta

Caso: Tenant disputa cargo directamente con su banco (sin contactar InboMarket).

Política: Disputa estándar Stripe/PayPal. NO aceptamos sin investigación previa.

Quién decide: Sistema automático + revisión SuperAdmin si recurrente.

Implementación:

• Webhook Stripe charge.dispute.created → notificación a SuperAdmin
• Sistema reúne evidencia (audit log uso, e-CF emitidos, correspondencia)
• Respuesta al banco vía Stripe Dispute API
• Si chargeback gana banco → tenant pasa a estado SUSPENDED automático

---

Escenario 6: Tenant insatisfecho dentro de Trial 14d / 30d beta

Caso: Tenant prueba 10 días, decide que no le gusta.

Política: Sin cargo. El trial es la garantía. Después de trial, política de cancelación voluntaria aplica.

Quién decide: Self-service (el trial expira automáticamente sin cargo si no hay método de pago verificado).

Implementación:

• Trial requiere método de pago verificado en signup (estandar SaaS)
• Día 14 → auto-conversión a plan si hay payment method, o LOCK si no
• Ventana 14d completa de trial garantizada (sin cargo si cancela)

---

Escenario 7: Servicio interrumpido >24h (downtime)

Caso: Bug crítico en producción tira el sistema 36 horas.

Política: Crédito proporcional según SLA.

Cálculo:

• 36h downtime en mes de 720h
• % downtime: 5%
• Crédito: 5% del costo mensual ($97 × 5% = ~$5)
• Crédito aplicado en próxima factura

Quién decide: SuperAdmin (basado en monitoring alerts).

Implementación:

• Status page público con uptime tracker
• Bug crítico → notificación automática a SuperAdmin
• SuperAdmin emite crédito vía Stripe API
• Comunicación pública en status page + email a tenants afectados

---

Escenario 8: Compra accidental de addon

Caso: Tenant clickeó "Activar Marketing Pro $40" por error y se dio cuenta inmediatamente.

Política: Ventana "Oops" 24h para cancelar sin cargo.

Quién decide: Self-service.

Implementación:

• Botón "Cancelar (todavía dentro de 24h)" en MySubscriptionPage
• Cron job verifica addon.activated_at < 24h → permite cancelación instantánea + refund completo
• Después de 24h: política de cancelación voluntaria aplica

---

Escenario 9: Plan no funciona por bug de InboMarket

Caso: Tenant Combo $349 paga, pero módulo APUs no funciona por bug crítico.

Política: Refund proporcional + soporte prioritario mientras se arregla.

Cálculo:

• Si el módulo bloqueado representa ~30% del valor del plan
• Refund: $349 × 30% = ~$105/mes hasta resolver
• Soporte prioritario gratis durante la resolución

Quién decide: Customer Success + escalación a Eng Lead.

Implementación:

• Ticket con tag BLOCKING_BUG
• Validación reproducción del bug
• Refund + audit log + plan de resolución comunicado al tenant

---

2. Tabla resumen

---

3. Compliance fiscal

Todos los refunds requieren:

• e-CF de anulación según Ley 32-23 DGII
• Notificación a contabilidad del tenant para reversión
• Audit log con razón + monto + decisor
• Almacenamiento de evidencia 10 años (compliance fiscal)

Implementación técnica:

• Service RefundService.createRefund(reason, amount, decisor)
• Genera e-CF de anulación via provider configurado (Tx 1)
• Webhook a Stripe Refund API
• Audit log entry
• Email automático al tenant con e-CF adjunto

---

4. Implementación TINA

4.1. Tareas

• Tabla refund_requests (id, tenant_id, scenario, amount, reason, status, decided_by, decided_at)
• Service RefundService con 9 métodos para los 9 escenarios
• Workflow self-service para escenarios 1, 3, 6, 8 (Stripe Portal API)
• UI Customer Success: dashboard tickets refund pendientes
• UI SuperAdmin: refund manual con e-CF anulación
• Webhook Stripe Dispute → notificación SuperAdmin
• Status page público con uptime tracker
• Email templates por escenario (9 templates)
• Tests E2E flujo completo cada escenario

4.2. Estimación dev

• Backend (service + tabla + integrations Stripe): 20h
• Customer Success UI: 8h
• Status page público: 6h
• Email templates: 4h
• Tests E2E: 12h
• Total: ~50h TINA

4.3. Acceptance criteria

• Los 9 escenarios funcionan según política
• e-CF de anulación se genera para todo refund
• Audit log completo de cada refund
• Customer Success puede procesar tickets refund desde dashboard
• Tenant recibe notificación email con resumen + e-CF
• Status page público funcional

---

5. Decisión PO Gabriel Brens 2026-06-03

✅ APROBADO — política completa de 9 escenarios.

Razón: evitar ambigüedad en CS + protección legal del modelo "no money-back guarantee" + claridad para tenants en cada caso particular.

---

Documento generado por: ATHENA 🏛️📊⚖️ Vinculación: Catálogo v4.7 sección 6.17 + Decisión firmada #60 Próximo paso: TINA implementa Sprint 10-11 post-MVP launch (no bloqueante V1 MVP)