> 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/ai-payment-recovery/hard-declines-and-backup-logic.md).

# Rechazos duros y lógica de respaldo

Qué códigos de rechazo de Stripe trata FlyCode como rechazos duros, qué hace con ellos (contacto más rápido y específico por acción y cobro a la tarjeta de respaldo), actualizaciones automáticas de tarjetas reemplazadas y pago de respaldo

No todos los pagos fallidos son iguales. Una denegación temporal es un problema de sincronización; una denegación definitiva significa que no se puede volver a cobrar la tarjeta. FlyCode aplica una lógica distinta a cada una, y para las denegaciones definitivas tiene dos vías que no dependen de que el cliente responda a un correo electrónico: cobrar una tarjeta de respaldo y actualizar automáticamente las credenciales de una tarjeta reemplazada.

## ¿Qué códigos de denegación trata FlyCode como denegaciones definitivas?

Las respuestas del emisor que significan que no se debe volver a intentar con la tarjeta. En la terminología de Stripe, estas son `incorrect_number`, `lost_card`, `pickup_card`, `stolen_card`, `revocation_of_authorization`, `revocation_of_all_authorizations`, `authentication_required` (el cliente debe completar 3D Secure, por lo que un reintento silencioso no puede tener éxito) y `highest_risk_level` (el bloqueo de Stripe Radar). Códigos como `invalid_account` y cualquier cosa devuelta con `do_not_try_again` consejo se tratan de la misma manera. Todo lo demás, incluidas `insufficient_funds`, `generic_decline`, `do_not_honor`, `try_again_later` y `processing_error`, es una denegación temporal y pasa al modelo de reintentos. Consulta [Códigos de denegación explicados](https://help.flycode.com/decline-codes-explained) para saber qué significa cada código.

## ¿Qué hace FlyCode con las denegaciones definitivas?

Para una denegación definitiva, el cliente tiene que cambiar la tarjeta registrada, así que FlyCode no gasta intentos ni días de periodo de gracia reintentándolo. Primero comprueba si ya hay un método de pago de respaldo registrado y lo cobra si existe. Si no, ajusta la cadencia de mensajes para que sea más rápida que en las denegaciones temporales, usa plantillas dinámicas con la acción específica requerida ("actualiza tu tarjeta", "completa la verificación con tu banco"), enlaza a una página de actualización de pago con un clic y secuencia los seguimientos según la interacción previa del cliente con los correos electrónicos. Una vez que el cliente actualiza la tarjeta, FlyCode reintenta de inmediato y marca la factura como recuperada.

## ¿Puede FlyCode actualizar automáticamente tarjetas reemplazadas o reemitidas?

Sí. FlyCode admite tanto Card Account Updater (CAU) como Network Tokens. Cuando un banco emisor reemplaza o reemite la tarjeta de un cliente, Visa y Mastercard envían las nuevas credenciales a la tarjeta registrada, y FlyCode reintenta con los datos actuales. No se requiere ninguna acción por parte del cliente, y no hace falta enviar primero ningún correo de cobranza. Una gran parte de las denegaciones definitivas causadas por credenciales de tarjeta desactualizadas se resuelven en silencio de esta manera, por lo que el contacto puede reservarse para los fallos que realmente necesitan la atención del cliente, como fondos insuficientes y denegaciones genéricas que no se resuelven después de reintentos optimizados.

## ¿FlyCode admite métodos de pago de respaldo?

Sí. FlyCode puede reintentar automáticamente un pago fallido usando una tarjeta alternativa ya registrada para el cliente, sin ningún flujo de trabajo manual y sin interrumpir el servicio del cliente. Se habilita con un solo interruptor y no requiere código adicional ni flujo de captación, porque utiliza los métodos de pago que ya almacena tu plataforma de facturación. Si todas las tarjetas registradas fallan, FlyCode recurre a su lógica estándar de reintentos y comunicación. Los detalles, requisitos legales e informes están en [Métodos de pago de respaldo](https://help.flycode.com/backup-payment-methods).

## Relacionado

* [Qué hacer cuando ves estos otros códigos](https://help.flycode.com/decline-codes-explained/what-to-do-when-you-see-these-other-codes)
* [Estrategia de entrega para el contacto por pago fallido](https://help.flycode.com/failed-payment-outreach/delivery-strategy)


---

# 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/ai-payment-recovery/hard-declines-and-backup-logic.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.
