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: reintenta el pago a lo largo de varios días, notifica al cliente, y le da 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 desarrolladores 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 comunes 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 y el recibo fallido se marca como outstanding. El cliente recibe una notificación de que su pago falló, con un enlace para actualizar su método de pago.
Días 1, 3 y 5: Reintentos automáticos. Commet reintenta el cobro 3 veces con un calendario fijo: el día 1, el día 3 y el día 5 después de la falla original. Los reintentos se ejecutan automáticamente, impulsados por el propio proceso de dunning de Commet, sin ninguna acción del cliente o de tu equipo.
Durante el período de gracia: el cliente mantiene el acceso. Esta es una decisión de diseño crítica. Mientras la suscripción está en past_due, el cliente mantiene el acceso a tu producto: las features, el uso y los seats siguen funcionando (el uso se acumula como deuda). Solo se bloquean las compras y los cambios de plan. Cortar el acceso inmediatamente ante un pago fallido castiga al cliente por un problema del que quizás ni está enterado.
Después de agotar todos los reintentos: cancelación. Si el cobro no se puede recuperar después de que falla el tercer reintento, la suscripción se cancela y el recibo pendiente se marca como uncollectible. En este punto el cliente pierde el acceso.
El cliente también puede recuperarse por su cuenta durante la ventana de gracia, sin esperar a un reintento, actualizando su método de pago o pagando un enlace de recuperación. Una recuperación exitosa devuelve la suscripción a active y emite un webhook payment.recovered.
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 permanente.
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.
Sumá las actualizaciones de método de pago iniciadas por el cliente durante el período de gracia y las tasas de recuperación suben aún más sobre cobros que de otra forma se perderían.
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, hay pasos proactivos que 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.
Vistas previas de recibo. Enviar notificaciones de recibo próximo 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 (actualiza tu tarjeta), y un enlace directo para hacerlo (un clic a la página de actualización de método de pago).
Evitá el 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 cerca del reintento del día 3, y un aviso final antes del último reintento.
Commet corre todo este flujo de recuperación por vos — empezá con la documentación de Commet.
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 cobro: 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