> ## Documentation Index > Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt > Use this file to discover all available pages before exploring further. # Reintentos de Pago de Suscripción > Reintenta automáticamente los pagos fallidos en la renovación de suscripciones con una programación inteligente sin necesidad de integración, para recuperar ingresos. Los Reintentos de Pago vuelven a intentar automáticamente los pagos de **renovación** de suscripción fallidos siguiendo un cronograma de progresivo. Si un reintento tiene éxito, la suscripción se reactiva automáticamente, sin necesidad de acción del cliente o trabajo de integración. ## ¿Qué Son los Reintentos de Pago? Cuando un pago de renovación de suscripción falla, la suscripción se coloca **en espera**. Con Reintentos de Pago habilitados, Dodo Payments vuelve a cargar automáticamente el método de pago existente del cliente según un cronograma inteligente hasta que el pago tenga éxito o se cierre la ventana de recuperación. Esto recupera los ingresos perdidos por fallos temporales — tarjetas expuestas, fondos insuficientes que se reponen, errores transitorios de red — sin enviar correos electrónicos al cliente ni solicitarle que actualice nada. Los Reintentos de Pago solo se aplican a pagos de **renovación** de suscripción. Los primeros pagos (configuración de mandato), pagos únicos, cargos por cambio de plan y cargos a demanda no se reintentan con esta función. ## Cómo Funcionan los Reintentos de Pago Un pago de renovación de suscripción falla y la suscripción se mueve al estado `on_hold`. Se revisa el código de error de la falla. Las **declinaciones suaves** (fondos insuficientes, declinación genérica, errores de procesamiento o red, etc.) son reintentables. Las **declinaciones duras** terminan la cadena de reintentos inmediatamente, ya que reintentar no cambiará el resultado. Si la declinación es reintenible y la ventana de recuperación lo permite, se programa el siguiente intento. Los reintentos se realizan fuera de sesión contra el método de pago existente del cliente según un cronograma de progresivo. En el primer reintento exitoso, la suscripción vuelve a `active` y la próxima fecha de facturación se avanza con normalidad. Si la ventana se cierra antes de que cualquier reintento tenga éxito, los reintentos se detienen y la suscripción permanece en espera. ## Configuración de Reintentos de Pago Habilita y configura los Reintentos de Pago desde **Configuración → Recuperación** en tu panel de control. Página de Configuración de Recuperación con la opción de habilitar activada y un campo de ventana de recuperación (días) configurado en 13 | Configuración | Descripción | Predeterminado | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------- | ---------------------- | | **Habilitar Reintentos de Pago** | Volver a intentar automáticamente los pagos de renovación de suscripción fallidos para recuperar ingresos. | Desactivado (opcional) | | **Ventana de recuperación (días)** | Cuánto tiempo seguir reintentando un pago fallido antes de desistir. Debe estar entre **1 y 30**. | 13 | La **ventana de recuperación** está anclada al momento en que se creó la factura de renovación fallida. Los reintentos solo se programan mientras el retraso acumulativo todavía encaje dentro de la ventana. ## Programa de Reintentos Los reintentos se retrasan de manera progresiva. Se realizan hasta **8 intentos**, siempre que cada uno encaje dentro de tu ventana de recuperación: | Intento | Retraso después del intento anterior | Tiempo aproximado desde el fallo | | ------- | ------------------------------------ | -------------------------------- | | 1 | 12 horas | 12 horas | | 2 | 24 horas | 36 horas | | 3 | 48 horas | \~3.5 días | | 4 | 72 horas | \~6.5 días | | 5 | 96 horas | \~10.5 días | | 6 | 120 horas | \~15.5 días | | 7 | 7 días | \~22.5 días | | 8 | 7 días | \~29.5 días | Una ventana de recuperación de **13 días** (la predeterminada) cubre los intentos 1 a 5 (el intento 5 se realiza \~10.5 días después del fallo). Aumenta la ventana hacia el máximo de 30 días si deseas que se realicen los intentos posteriores, más ampliamente espaciados (6 a 8). ## Transiciones de Estado de Suscripción | Evento | Estado de la suscripción | | -------------------------------- | ---------------------------------------------------------------------------------- | | Falla en el pago de renovación | `active` → `on_hold` | | Falla en el intento de reintento | permanece `on_hold` (se programa otro reintento si la ventana lo permite) | | Éxito en el intento de reintento | `on_hold` → `active`, próxima fecha de facturación avanzada | | Ventana de recuperación agotada | permanece `on_hold` | | Suscripción cancelada | los reintentos programados se detienen inmediatamente (terminal — no más intentos) | Si una suscripción se cancela mientras aún hay reintentos programados, la cadena de reintentos termina inmediatamente y no se realizan más intentos. Otros estados no activos (`on_hold`, `expired`, `pending`, `failed`) continúan intentando, porque sus facturas de renovación abiertas representan una deuda por períodos que el cliente ya ha consumido. Estas transiciones emiten los eventos estándar de suscripción webhook, para que pueda gestionar la lógica de derechos sin manejo especial de reintentos: | Evento | Se dispara cuando | | ---------------------- | --------------------------------------------------------- | | `subscription.on_hold` | Falla una renovación y la suscripción se coloca en espera | | `subscription.active` | Un reintento tiene éxito y la suscripción se reactiva | Vea los esquemas completos de carga útil de webhook para eventos del ciclo de vida de suscripción. ## Fallas Reintentables vs. No Reintentables | Tipo de fallo | Ejemplos | ¿Reintentado? | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | **Declinación suave** | Fondos insuficientes, declinación genérica, límite de tarjeta excedido, error de procesamiento, error de red/tiempo de espera, inténtelo de nuevo más tarde | Sí | | **Declinación dura** | Tarjeta robada/perdida, tarjeta inválida, no honrar, cuenta cerrada, y otras declinaciones terminales | No — la cadena termina inmediatamente | Reintentar una declinación dura no cambiará el resultado, por lo que la cadena de reintentos se termina tan pronto como se observa una declinación dura. Combine Reintentos de Pago con [Recuperación de Suscripción](/features/recovery/subscription-dunning) para solicitar al cliente que actualice su método de pago en esos casos. ## Reintentos de Pago vs. Recuperación Los Reintentos de Pago y [Recuperación de Suscripción](/features/recovery/subscription-dunning) son herramientas complementarias de recuperación: | | Reintentos de Pago | Recuperación de Suscripción | | ---------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------- | | **Mecanismo** | Recarga silenciosamente el método de pago existente | Envía correos electrónicos al cliente para actualizar su método de pago | | **Acción del cliente** | No se requiere ninguna | El cliente actualiza su método de pago en el portal | | **Mejor para** | Declinaciones temporales/suaves que se resuelven solas | Tarjetas caducadas o inválidas que necesitan ser reemplazadas | Habilitar ambos le brinda la cobertura de recuperación más amplia: los reintentos automáticos capturan fallas transitorias, mientras que la recuperación recupera a los clientes cuyo método de pago realmente necesita ser actualizado. ## Relacionado Secuencias de correos electrónicos que solicitan a los clientes que actualicen su método de pago. Recupere compras únicas incompletas o fallidas con correos electrónicos específicos. Comprenda los estados de suscripción involucrados en los flujos de recuperación. Reaccione a los eventos `subscription.on_hold` e `subscription.active`.