> For the complete documentation index, see [llms.txt](https://docs.flycode.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flycode.com/docs/es/read-more/failed-payment-recovery-glossary.md).

# Glosario de recuperación de pagos fallidos

Definiciones breves e independientes de los términos utilizados en toda la documentación de FlyCode y en los pagos de suscripciones en general. Cada entrada enlaza a la página con más detalles.

**Abandono involuntario.** La pérdida de un suscriptor porque falló un pago recurrente y no se recuperó, en lugar de porque el cliente eligió cancelar. También se denomina abandono pasivo, moroso o por pago. Normalmente entre el 20 y el 40 por ciento del abandono total de suscripciones. Ver [Comprender la rotación involuntaria](https://help.flycode.com/understanding-involuntary-churn).

**Abandono voluntario.** Un cliente que cancela activamente una suscripción por precio, ajuste, competencia o necesidad. Requiere respuestas de producto y precios, no optimización de pagos.

**Pago fallido / pago denegado.** Un cargo recurrente que el banco emisor se negó a autorizar. La negativa viene con un código de rechazo.

**Código de rechazo.** La razón que da el banco emisor para rechazar un cargo, estandarizada por las redes de tarjetas como un código de respuesta de dos caracteres (por ejemplo, 05 Do Not Honor, 51 Insufficient Funds) y traducida por los procesadores a su propio vocabulario (Stripe: `do_not_honor`, `insufficient_funds`). Ver [Explicación de los códigos de rechazo](https://help.flycode.com/decline-codes-explained).

**Rechazo temporal.** Una negativa temporal que puede tener éxito en un intento posterior: fondos insuficientes, rechazo genérico, no honrar, inténtelo de nuevo más tarde, emisor no disponible, error de procesamiento. Aproximadamente del 60 al 70 por ciento de los fallos de suscripción.

**Rechazo permanente.** Una negativa permanente para esa tarjeta: perdida, robada, retenida, cuenta cerrada o inválida, y cualquier respuesta con indicación de no volver a intentar. Requiere un nuevo método de pago; no debe reintentarse.

**Gestión de cobros.** El proceso de recuperar un pago vencido, históricamente mediante el envío de mensajes de recordatorio. La gestión de cobros moderna combina primero reintentos silenciosos y después acciones coordinadas. Ver [Guía de gestión de recobros 2026](https://docs.flycode.com/docs/dunning-management-2026-guide).

**Reintento (nuevo intento).** Un nuevo intento de autorización sobre un cargo previamente rechazado. Las redes de tarjetas limitan el número y el momento de los reintentos. Ver [Reglas de reintento de la red de tarjetas](https://docs.flycode.com/docs/read-more/card-network-retry-rules-for-failed-payments-visa-and-mastercard).

**Reintentos inteligentes.** La función de reintento de aprendizaje automático integrada de Stripe Billing, entrenada con todos los comerciantes de Stripe y limitada a 8 intentos por factura. Ver [Guía completa de Stripe Smart Retries](https://docs.flycode.com/docs/stripe-smart-retries-complete-guide).

**Reintentos personalizados.** La alternativa de Stripe a Smart Retries con intervalos fijos, con reintentos a intervalos de días establecidos.

**Tasa de recuperación.** Pagos fallidos recuperados divididos por el total de pagos fallidos durante un período. La referencia del sector es de aproximadamente entre el 40 y el 55 por ciento; lo mejor de su clase es del 70 al 90 por ciento.

**Tasa de fallos de pago.** Cargos fallidos divididos por cargos intentados. Normalmente entre el 8 y el 15 por ciento para empresas de suscripción.

**Velocidad de recuperación.** Promedio de días desde el primer fallo hasta la recuperación exitosa. Una recuperación más rápida significa menos riesgo de abandono.

**Conversión de abandono pasivo a activo.** Clientes que cancelan voluntariamente después de que se les informa de un pago fallido que no conocían, normalmente porque llegó un correo de cobro antes de que los reintentos tuvieran oportunidad. La principal razón para reintentar silenciosamente primero.

**Período de gracia / vencido.** El tiempo que una suscripción permanece activa o vencida después de un pago fallido antes de que el sistema de facturación la cancele. Los períodos de gracia más largos dejan más margen para la recuperación.

**Actualizador de cuentas de tarjeta (CAU).** Servicios de Visa (VAU) y Mastercard (ABU) que envían nuevas credenciales de tarjeta a los comercios cuando un emisor reemplaza o vuelve a emitir una tarjeta, de modo que las tarjetas almacenadas sigan funcionando sin acción del cliente.

**Token de red.** Un token emitido por la red que reemplaza el número de tarjeta en la bóveda de un comercio y se actualiza automáticamente cuando cambia la tarjeta subyacente, mejorando las tasas de autorización.

**Método de pago de respaldo.** Un método de pago válido adicional registrado para un cliente que puede cobrarse automáticamente cuando falla el principal. Ver [Métodos de pago de respaldo](https://help.flycode.com/backup-payment-methods).

**Orquestación de pagos.** Enrutamiento de transacciones a través de más de un procesador de pagos mediante reglas o modelos. En la recuperación, redirigir un reintento rechazado a través de un procesador alternativo con más probabilidades de aprobarlo. Ver [Agente de orquestación de pagos](https://help.flycode.com/payment-orchestration-agent).

**Emisor (banco emisor).** El banco del titular de la tarjeta, que toma la decisión de aprobar o rechazar.

**Adquirente.** El banco o procesador del comercio que envía la autorización a la red de tarjetas.

**Código de aviso del comercio (MAC).** Un campo de Mastercard devuelto con muchos rechazos que indica al comerciante qué hacer a continuación; por ejemplo, 01 actualizar la información de la cuenta, 02 intentar de nuevo más tarde, 03 no volver a intentarlo, 21 pago recurrente cancelado.

**Transacción iniciada por el comerciante (MIT).** Un cargo iniciado por el comerciante usando credenciales almacenadas sin que el cliente esté presente, como una renovación de suscripción o un reintento. Debe marcarse correctamente según las reglas de credenciales almacenadas de la red.

**3D Secure / SCA.** Pasos de autenticación del titular de la tarjeta (Autenticación reforzada de clientes en la UE y el Reino Unido). Un rechazo de `authentication_required` no puede recuperarse mediante reintento silencioso; el cliente debe completar la autenticación.

**Precios basados en resultados.** Un modelo de precios en el que el proveedor recibe una parte de los ingresos recuperados por encima de la referencia previa del comerciante, y nada sobre los ingresos que el comerciante habría recuperado de todos modos. El modelo de FlyCode.

**Recuperación de referencia.** La tasa de recuperación que un comerciante logró antes de añadir una herramienta de recuperación, utilizada para medir el incremento obtenido.

**Ingresos en riesgo.** El MRR fallido multiplicado por la vida media restante del cliente; la verdadera exposición financiera de los pagos fallidos. Ver [ROI de la recuperación de costes por pagos fallidos](https://docs.flycode.com/docs/failed-payment-cost-recovery-roi).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flycode.com/docs/es/read-more/failed-payment-recovery-glossary.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.