El dunning es el proceso de recuperar pagos fallidos en suscripciones activas. Cuando un cobro recurrente falla, el sistema de billing no cancela la suscripción inmediatamente. En su lugar, entra en un flujo de dunning: reintentando el pago a lo largo de un período de días, notificando al cliente, y dándole la oportunidad de actualizar su método de pago antes de que se revoque el acceso. Bien implementado, el dunning recupera ingresos que de otra forma se perderían por churn involuntario.
Por qué fallan los pagos
Las fallas de pago son más comunes de lo que la mayoría de los builders de SaaS esperan. Los datos de la industria sugieren que el 5-10% de los cobros recurrentes fallan en el primer intento. Las razones son mundanas pero variadas.
Tarjetas vencidas. La tarjeta de crédito del cliente alcanzó su fecha de vencimiento y el banco rechazó el cargo. Esta es la razón de falla más común.
Fondos insuficientes. La cuenta del cliente no tiene suficiente saldo para cubrir el cargo en el momento en que se intentó.
Bloqueos de fraude del banco. El banco emisor marcó el cargo recurrente como sospechoso, especialmente común cuando el monto del cargo cambia (por overage de uso o un upgrade de plan) o cuando el cliente reportó fraude recientemente en una transacción diferente.
Errores de red. Problemas temporales de conectividad entre el procesador de pagos y el banco emisor. Estos generalmente se resuelven en el reintento sin ninguna acción del cliente.
Ninguna de estas fallas significa que el cliente quiere cancelar. Son problemas mecánicos del procesamiento de pagos, y un buen sistema de dunning resuelve la mayoría automáticamente.
La línea de tiempo del dunning
Cuando un pago falla, la suscripción pasa de active a past_due. Este cambio de estado es la señal de que el dunning comenzó.
Día 0: Falla inicial. El pago es rechazado. La suscripción se marca como past_due. El cliente recibe una notificación de que su pago falló, con un link para actualizar su método de pago.
Días 1-14: Reintentos inteligentes. El procesador de pagos (Stripe, en el caso de Commet) reintenta el cobro usando machine learning para elegir los momentos óptimos de reintento. Los Smart Retries de Stripe analizan patrones a través de millones de transacciones para determinar cuándo una tarjeta particular tiene mayor probabilidad de funcionar. Los reintentos pasan automáticamente sin ninguna acción del cliente o tu equipo.
Durante el período de gracia: El cliente mantiene acceso. Esta es una decisión de diseño crítica. Mientras la suscripción está en past_due, el cliente sigue teniendo acceso completo a tu producto. Puede loguearse, usar features, y acceder a sus datos. Cortar el acceso inmediatamente ante un pago fallido castiga a clientes por un problema del que quizás ni están enterados.
Después de agotar todos los reintentos: Cancelación. Si el pago no se puede recuperar después de que se cierra la ventana de reintentos, la suscripción se cancela. En este punto, el cliente pierde acceso. La cantidad exacta de días antes de la cancelación depende de tu configuración, pero 14-21 días es un período de gracia común.
Para detalles de configuración sobre el manejo de fallas en tu integración, consultá la documentación de manejo de pagos fallidos.
Por qué deberías mantener el acceso durante past_due
Es tentador cortar el acceso en el momento en que un pago falla. La lógica parece sólida: sin pago, sin servicio. Pero este enfoque destruye ingresos.
Considerá la matemática. Un cliente en un plan de $99/mes tiene un pago fallido. Si cortás el acceso inmediatamente, podría hacer churn permanentemente. Aunque tenía intención de quedarse, la fricción de quedar bloqueado, necesitar reactivar, y potencialmente perder configuración o datos puede empujarlo a un competidor. Perdés $1,188/año.
Si mantenés el acceso durante el período de gracia, el cliente tiene una experiencia transparente. Su tarjeta se reintenta, el pago pasa el día 3, y ni se enteró del problema. Mantenés los $1,188/año.
Los números respaldan este enfoque. Stripe reporta que los Smart Retries recuperan alrededor del 30% de los pagos fallidos automáticamente. Sumale las actualizaciones de método de pago iniciadas por el cliente durante el período de gracia, y las tasas de recuperación pueden alcanzar el 50-70% de los cargos inicialmente fallidos.
Reducir el churn involuntario
El dunning es tu defensa principal contra el churn involuntario, que representa el 20-40% del churn total en muchas empresas SaaS. Más allá de la lógica de reintentos, pasos proactivos reducen las fallas de entrada.
Avisos de actualización de tarjeta. Cuando una tarjeta se acerca a su fecha de vencimiento, notificá al cliente antes del próximo cobro. Esto previene el tipo de falla más común.
Métodos de pago de respaldo. Un método de pago secundario le da al sistema un fallback cuando el primario falla.
Previews de factura. Enviar notificaciones de factura próxima unos días antes del cobro le da al cliente tiempo para asegurar fondos suficientes.
Comunicaciones de dunning
Los emails enviados durante el dunning importan tanto como la lógica de reintentos. Un buen email de dunning tiene tres elementos: qué pasó (tu pago falló), qué hacer (actualizá tu tarjeta), y un link directo para hacerlo (un click a la página de actualización de método de pago).
Evitá lenguaje amenazante. "No pudimos procesar tu pago. Actualizá tu tarjeta para mantener tu suscripción activa" es directo y útil. Enviá la primera notificación inmediatamente al fallar, un recordatorio el día 3 o 4, y un aviso final 2-3 días antes de la cancelación.
Relacionados
- Recurring Billing: el proceso automatizado de cobro de pagos donde el dunning se activa ante fallas
- Subscription Billing: el modelo más amplio que el dunning protege del churn involuntario
- Ciclo de facturación: el período dentro del cual ocurren el cobro de pagos y el dunning
- Manejo de pagos fallidos: guía de implementación para configurar el comportamiento de dunning