Dunning + Manejo de Pagos Fallidos en SaaS

Involuntary churn (pagos fallidos) puede ser 30-40% del churn total en SaaS B2B. Dunning automatizado bien hecho recupera 60-70% de estos pagos.

Tipos de fallos típicos

• Tarjeta vencida (más común): cliente debería actualizar
• Sin fondos: temporal, retry funciona
• Tarjeta declined: requiere acción cliente
• Cambio de banco: cliente debe re-añadir

Estrategia de dunning

Día 1 (fallo inicial)

• Notification al cliente (email)
• Retry automático en 24-48h (usualmente recupera 30%)

Días 3-5

• Email "pago pendiente"
• Link para actualizar método de pago
• In-app banner cuando ingresa al SaaS

Días 7-10

• Retry adicional
• Email "última oportunidad antes de suspensión"
• Servicio se restringe parcialmente (no full lock)

Días 14-21

• Suspensión del servicio
• Cliente puede reactivar al actualizar pago
• Outreach manual si es cliente de ticket alto

Día 30+

• Cancellation final
• Win-back campaign en mes 2-3 con ofertas

Recovery rates típicas

Estrategia	Recovery rate
Sin dunning (retry simple)	20-30%
Dunning básico (3 emails)	40-50%
Dunning sofisticado (retry inteligente + emails personalizados)	60-70%
+ outreach manual para enterprise	75-85%

Para implementar el motor custom de retry + emails segmentados, ver el servicio de sistemas a medida.

Tools

Stripe Smart Retries

Stripe analiza patrones del banco emisor + horario óptimo + retry. Mejora baseline de retry.

Recurly / Chargebee / Zuora

Plataformas de subscription billing con dunning sofisticado built-in. Para SaaS serios suele justificar (USD 200-2.000/mes según volumen).

Custom

Para SaaS con stack propio: implementar lógica custom usando Stripe webhooks + email automation.

Mejores prácticas

1. Email tone

No accusatorio. "Tu pago no se procesó, ¿podemos ayudarte?" mejor que "URGENTE: pago vencido".

2. UI en app

Banner discreto dentro del SaaS. Cliente entra, ve "actualizá tu método de pago", click, listo.

3. Pause antes de cancel

Permitir pausar suscripción en lugar de cancelar. Muchos vuelven después de pausa.

4. Personalización

Email distinto según razón del fallo. "Tarjeta vencida" different from "sin fondos".

5. Multiple métodos de pago

Permitir backup payment method. Si principal falla, retry en backup.

6. Customer success outreach

Para clientes enterprise: outreach manual cuando hay fallo. Mucho más efectivo que email.

Métricas

• Recovery rate por estrategia
• Days to recovery
• Customer lifetime impact (post-recovery vs pre-recovery)
• % involuntary vs voluntary churn

Caso de referencia

SaaS B2B con $1M ARR + 5% mensual churn (60% voluntary, 40% involuntary).

Pre-dunning sofisticado:

• Involuntary churn recoverable: 30%
• Pérdida mensual: USD 13,000

Post-dunning (Stripe + emails + custom):

• Recovery: 65%
• Pérdida mensual: USD 5,200

Ahorro: USD 7,800/mes = USD 93,600/año.

Inversión: USD 4,000 setup + Stripe Smart Retries (gratis) + email tooling existente.

Dunning específico para AR

Mercado Pago particularidades

• Tarjetas AR con límites bajos en USD = fallos frecuentes en cobro USD
• Pagos rechazados por compras "internacionales" sin notificar al banco
• Switch a transferencia bancaria como fallback común
• DEBIN (débito inmediato bancario) como alternativa para retención

Estrategia AR-friendly

1. Cliente AR: ofrecer cobro en ARS al tipo de cambio del día (no USD)
2. Si tarjeta falla: switch a transferencia + factura A/B
3. Permitir pagos por adelantado (3, 6, 12 meses) con descuento - elimina fallos recurrentes

Implementación técnica de retry inteligente

Cuándo retriear

• Inmediato post-fallo: 0% éxito en general
• 24h después: 30-40% éxito
• 72h después: 25-30% éxito
• Día 7: 15-20% éxito
• Día 14: <10% éxito

Stripe Smart Retries usa ML para optimizar timing por banco emisor + horario.

Decline codes que sí retriear

• insufficient_funds: SI (esperar 2-3 días)
• card_declined + reason do_not_honor: SI (próximo ciclo)
• processing_error: SI inmediato
• try_again_later: SI

Decline codes que NO retriear

• card_declined + reason lost_card / stolen_card: NO, contactar cliente
• expired_card: NO, requerir update method
• incorrect_cvc / invalid_number: NO, requerir update
• fraudulent: NO, posible fraud, escalar

Email sequence típica

Email 1 (día del fallo)

Subject: "No pudimos procesar tu pago - {company}"

• Tono empático, no accusatorio
• Razón específica si es identificable
• 1-click button "actualizar método"
• Mención de que servicio sigue activo

Email 2 (día 3)

Subject: "Recordatorio: tu pago en {company} sigue pendiente"

• Recordatorio breve
• Soporte disponible si hay problema
• Mención de qué pasa si no se resuelve (suspensión en X días)

Email 3 (día 7)

Subject: "Tu cuenta {company} se suspenderá pronto"

• Más urgente sin ser hostile
• Highlight de lo que perderán (data, features)
• Opción de pausar en lugar de perder

Email 4 (día 14)

Subject: "Tu cuenta {company} fue suspendida"

• Servicio suspendido
• Reactivable instantáneo al actualizar pago
• Win-back offer si responde

Email 5 (día 30)

Subject: "Última oportunidad antes de cancelar tu cuenta"

• Cancelación inminente
• Offer especial si vuelven
• Después de esto: cancel + win-back en mes 2-3

In-app dunning

Banner

Cuando user con pago pendiente entra al SaaS:

• Banner top discreto: "Hay un problema con tu pago. {actualizar}"
• No bloquear UX hasta día 14+

Modal en suspensión

Cuando suspendido:

• Modal centrado al login
• Botón único: "Reactivar mi cuenta"
• Form para update method directo

Account settings

Página dedicada con status del pago + history.

Métricas de éxito a trackear

• Recovery rate: % de fallos que recuperan en X días
• Average days to recovery: cuánto tarda en promedio
• Email engagement: open rate + click rate de cada email
• Voluntary cancel rate post-failure: cuántos cancelan después del email
• Win-back rate: % de cancelados que vuelven en mes 2-3
• Churn breakdown: % voluntary vs involuntary mes a mes

Target óptimo: involuntary churn <5% del total churn.

Errores típicos

1. Solo email, sin retry inteligente: Stripe Smart Retries dispara recovery 15-25%
2. Tono hostile: "PAGO VENCIDO URGENTE" → cliente cancela voluntary
3. Sin opción de pausa: cliente con problema temporal cancela en lugar de pausar
4. No segmentar por valor del cliente: enterprise merece outreach manual
5. Cancelar muy rápido: default 7 días = pierdes recoveries de día 14-21
6. Sin win-back: cliente cancelado puede volver en 60-90 días con offer

En síntesis

Dunning bien hecho es alta-leverage en SaaS B2B. Recuperar 60-70% de pagos fallidos vs default 20-30% mueve unit economics significativamente.

Stack: Stripe Smart Retries + emails segmentados + UI in-app + outreach para enterprise.

Para SaaS AR con clientes locales: ajustar a particularidades de pagos AR (Mercado Pago, transferencia, DEBIN) además de Stripe para internacionales.

Si te toca, escribinos. Otras lecturas: reducir churn en SaaS B2B, billing + integración Stripe/MP.