> For the complete documentation index, see [llms.txt](https://help.flycode.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.flycode.com/es/flycode-vs.-profitwell-paddle-retain/whats-different-behind-the-scenes.md).

# Qué cambia entre bastidores

Por qué el motor de reintentos de IA por comerciante de FlyCode supera el programa de intervalos fijos de ProfitWell Retain y cómo FlyCode coordina los correos a clientes con el ciclo de reintentos en lugar de enviar correos después de cada int

Dos decisiones de diseño explican la mayor parte de la diferencia de rendimiento entre FlyCode y ProfitWell Retain: cómo se programan los reintentos y cómo se sincronizan los correos electrónicos.

## ¿Por qué importa el motor de reintentos impulsado por IA de FlyCode?

Porque el momento adecuado para reintentar difiere según el cliente, la tarjeta y el banco, y un calendario fijo no puede captarlo. ProfitWell Retain se basa en un calendario de reintentos a intervalos fijos aplicado a cada factura fallida de la misma manera. FlyCode entrena un modelo de aprendizaje automático personalizado para cada comerciante con las propias transacciones y respuestas del emisor de ese comerciante, y el modelo sigue aprendiendo de cada resultado. Pondera el código de rechazo, el comportamiento del emisor, el tipo y la marca de la tarjeta, el país y la zona horaria, el importe y las fechas de pago anteriores del cliente para elegir la ventana de reintento con mayor probabilidad de éxito, al tiempo que se mantiene dentro de los límites de Visa y Mastercard sobre intentos por ciclo. Los efectos prácticos son menos intentos desperdiciados, recuperación más rápida, menor exposición a tarifas por reintentos excesivos y una tasa de recuperación materialmente más alta, especialmente en los `insufficient_funds` rechazos que representan la mayor parte de los fallos.

## ¿Cómo gestiona FlyCode los correos electrónicos de los clientes durante el ciclo de reintentos?

FlyCode coordina los correos electrónicos con su plan de reintentos en lugar de ejecutar un goteo independiente. No se envía ningún correo inmediatamente después de un rechazo suave, porque los reintentos silenciosos suelen recuperarlo y un correo temprano corre el riesgo de convertir a un cliente que no estaba al tanto en una cancelación voluntaria. Los rechazos duros tienen su propio calendario distinto con una solicitud específica de un nuevo método de pago. Cada mensaje se envía en la hora local del cliente, desde tu propio dominio, utilizando plantillas transaccionales breves de una infraestructura de envío de alta entregabilidad. Esto va mucho más allá de los uno o dos mensajes predeterminados de Stripe y difiere de las herramientas orientadas primero al cobro que envían correos en cada intento. Véase [Coordinar la mensajería con la recuperación](https://help.flycode.com/handling-failed-payments/coordinating-messaging-with-recovery).

## Relacionado

* [Cuándo y cómo se reintentan los pagos](https://help.flycode.com/handling-failed-payments/when-and-how-payments-are-retried)
* [Seguimiento de pagos fallidos](https://help.flycode.com/failed-payment-outreach)


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.flycode.com/es/flycode-vs.-profitwell-paddle-retain/whats-different-behind-the-scenes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
