> 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/subscription-payment-decline-codes-guide-for-stripe.md). # Guía de códigos de rechazo de pagos de suscripción para Stripe {% hint style="info" %} **EN RESUMEN:** Cuando falla un pago de suscripción, tu procesador devuelve un código de rechazo que te indica por qué. El problema: los códigos son inconsistentes entre redes y procesadores, y el más común, "Do Not Honor", no dice casi nada. Esta guía asigna a cada código de rechazo común una estrategia específica de recuperación, para que dejes de tratar todos los fallos por igual y empieces a recuperar más de cada tipo. {% endhint %} *Por el equipo de FlyCode. Última revisión: septiembre de 2026.* {% hint style="success" %} **Puntos clave** * Los rechazos suaves representan del 60 al 70 por ciento de los fallos de pago de suscripciones y normalmente pueden recuperarse con reintentos silenciosos, mientras que los rechazos duros (del 30 al 40 por ciento) requieren que el cliente actualice su método de pago. * `insufficient_funds` (código de red 51) es el rechazo individual más grande, entre el 50 y el 70 por ciento de los fallos, y se recupera en un 70 al 85 por ciento cuando se reintenta alrededor de las fechas de pago en lugar del mismo día. * "Do Not Honor" (código 05) es un cajón de sastre que representa del 10 al 20 por ciento de los fallos y por sí solo revela casi nada, así que clasificar su causa subyacente a partir de los patrones de la transacción es lo que lo hace recuperable. * Activa Card Account Updater y Network Tokens antes de enviar cualquier correo de cobro por una tarjeta reemplazada: CAU evita del 60 al 80 por ciento de los fallos relacionados con credenciales sin que el cliente tenga que actuar. {% endhint %} ## Códigos de rechazo de pagos de suscripción: qué significan y cómo recuperar cada uno *** ### Cómo funcionan los códigos de rechazo: la anatomía de un pago fallido Cuando se intenta el pago de un cliente, la solicitud pasa por una cadena: tu procesador de pagos (p. ej., Stripe) → la red de tarjetas (Visa, Mastercard) → el banco emisor. El banco emisor toma la decisión de aprobar o rechazar y devuelve un código de respuesta que viaja de vuelta por la cadena. Lo que ves en tu panel de Stripe es la interpretación de Stripe de la respuesta del banco, que a menudo es más descriptiva que el código bruto de la red, pero aun así no es perfecta. #### El problema de los códigos en tres capas | Capa | Formato del código | Ejemplo | Lo que ves | | -------------------------------- | -------------------------------------- | ------------------ | --------------------------------------- | | **Banco emisor** | Código de respuesta bruto (DE 39) | `05` | No ves esto directamente | | **Red de tarjetas** | Código de red estandarizado | `05: Do Not Honor` | Disponible a través de la API de Stripe | | **Procesador de pagos (Stripe)** | Código de rechazo específico de Stripe | `generic_decline` | Lo que aparece en tu panel | Esta capa crea un problema de traducción. El código bruto del banco se interpreta por la red y luego Stripe lo reinterpreta. El matiz se pierde en cada paso. Un solo código de Stripe como `generic_decline` puede representar una docena de decisiones bancarias subyacentes distintas. *** ### Rechazos suaves vs. rechazos duros: la distinción crítica Este es el concepto más importante en la recuperación de pagos. Cada rechazo entra en una de dos categorías, y tu respuesta a cada una debe ser completamente diferente. #### Comparación entre rechazo suave y rechazo duro | Característica | Rechazo suave | Rechazo duro | | ---------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | | **Naturaleza** | Temporal: puede resolverse por sí solo | Permanente: no se resolverá sin intervención | | **% de todos los fallos de suscripción** | 60–70% | 30–40% | | **¿Se puede recuperar con reintentos?** | Sí: a menudo sin que el cliente lo sepa | No: requiere que el cliente actualice el pago | | **Ejemplos** | Fondos insuficientes, error de procesamiento, emisor no disponible | Credenciales de tarjeta desactualizadas, número inválido, tarjeta robada, cuenta cerrada | | **Respuesta óptima** | Reintento silencioso con timing optimizado | Correo de cobro con enlace para actualizar la tarjeta | | **Potencial de recuperación** | Alto (70–90% con timing inteligente) | Medio (40–60% con buen cobro) | | **Riesgo de reintentar** | Bajo (dentro de los límites de la red) | Desperdicia reintentos y arriesga multas de la red | La regla de oro: agota los reintentos inteligentes en rechazos suaves antes de contactar al cliente. Envía comunicaciones de cobro de inmediato para rechazos duros. *** ### Referencia completa de códigos de rechazo: cada código, cada estrategia de recuperación #### Rechazos suaves: alto potencial de recuperación (reintentar primero) | Código | Código de Stripe | Significado | % de fallos | Estrategia de recuperación | Tasa de recuperación esperada | | ------- | ---------------------------------- | ------------------------------------------------------------ | ----------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | | **51** | `insufficient_funds` | El cliente no tiene suficiente dinero | 50–70% | Reintenta alrededor de las fechas de pago (1.º, 15 del mes), por la mañana en la zona horaria del cliente. No reintentes el mismo día. | 70–85% con timing optimizado | | **05** | `generic_decline` / `do_not_honor` | El banco rechazó: no se dio un motivo específico | 10–20% | Reintentos optimizados por ML en distintos momentos. Puede resolverse por sí solo. Este es el código de la "caja negra". | 40–60% según la causa subyacente | | **91** | `issuer_not_available` | Sistemas del banco temporalmente caídos | 3–5% | Reintenta entre 4 y 24 horas. Casi siempre funciona en el siguiente intento. | 90%+ | | **06** | `processing_error` | Fallo genérico de procesamiento | 3–5% | Reintenta entre 24 y 48 horas con una ventana de tiempo diferente. | 80–90% | | **65** | `card_velocity_exceeded` | Demasiadas transacciones en un periodo corto | 1–3% | Espera 24–48 horas y luego reintenta. Se alcanzó el límite diario de la tarjeta. | 70–80% | | **61** | `withdrawal_amount_exceeds_limit` | La transacción excede el límite de transacción de la tarjeta | 1–2% | Reintenta después de 24 horas. Si es recurrente, considera dividirlo en importes más pequeños. | 60–75% | | **N/D** | `try_again_later` | Problema temporal del emisor | 2–4% | Reintenta entre 4 y 12 horas. | 85–95% | #### Rechazos duros: se requiere acción del cliente (cobro de inmediato) | Código | Código de Stripe | Significado | % de fallos | Estrategia de recuperación | Tasa de recuperación esperada | | ------- | ------------------------------------------------ | ------------------------------------------------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | | **54** | `expired_card` | La tarjeta ya no es válida; el emisor la ha reemplazado | 10–15% | Primero verifica si Card Account Updater / Network Tokens puede reemplazarla automáticamente. Si no, envía un correo de cobro con un enlace de un solo clic para actualizar la tarjeta. | 60–80% (con CAU), 40–55% (solo correo) | | **14** | `invalid_number` | El número de tarjeta no existe o es incorrecto | 2–3% | Correo de cobro solicitando al cliente que vuelva a introducir los datos de la tarjeta. | 35–50% | | **43** | `stolen_card` | Tarjeta denunciada como robada | 1–2% | NO reintentes. Envía una notificación amable pidiendo un método de pago alternativo. | 30–40% | | **41** | `lost_card` | Tarjeta denunciada como perdida | 1–2% | Similar a robada: Network Tokens puede actualizarla automáticamente. Si no, correo de cobro. | 40–55% (con tokens), 30–40% (sin ellos) | | **04** | `pickup_card` | El banco quiere retener la tarjeta | <1% | No reintentes. Contacta al cliente para obtener un nuevo método de pago. | 20–30% | | **N/D** | `card_declined` (con `do_not_try_again` consejo) | Rechazo terminal: el banco dice que se detenga | 2–3% | No reintentes. Cobro inmediato con formulario de actualización de tarjeta. | 30–45% | #### Rechazos de autenticación: requieren interacción del cliente | Código | Código de Stripe | Significado | % de fallos | Estrategia de recuperación | Tasa de recuperación esperada | | ------- | ------------------------- | ----------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | | **N/D** | `authentication_required` | Se necesita un reto 3D Secure / SCA | 5–10% | Envía un correo con un enlace de pago que active el flujo de autenticación. Notificación en la app para usuarios activos. | 50–65% | | **N/D** | `3ds_required` | Mandato europeo de SCA | Depende de la región | Redirige al cliente para completar la verificación 3DS. No se puede resolver con reintentos silenciosos. | 55–70% con buena UX | #### Rechazos relacionados con fraude: trátalos con cuidado | Código | Código de Stripe | Significado | % de fallos | Estrategia de recuperación | Tasa de recuperación esperada | | ------- | ----------------- | -------------------------------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | **N/D** | `fraudulent` | Stripe Radar o el banco lo marcó como fraude | 3–5% | Si Stripe lo bloqueó: revísalo en el panel, añádelo a la lista permitida si es legítimo. Si lo marcó el banco: el cliente debe llamar al banco. | 25–40% | | **59** | `suspected_fraud` | El banco sospecha fraude | 2–3% | No reintentes agresivamente. La hora del día y la geografía importan: un cargo a las 3 a. m. desde una ubicación inusual se marca con más frecuencia. Reintenta en horario laboral. | 30–50% con optimización de timing | *** ### El problema de "Do Not Honor": resolviendo la caja negra Código 05 / `do_not_honor` / `generic_decline` merece atención especial porque es el código de rechazo más común y el menos informativo en la facturación de suscripciones. #### Por qué "Do Not Honor" es tan común Cuando un banco rechaza una transacción pero no quiere revelar el motivo específico (privacidad, razones competitivas o simplemente una clasificación perezosa), devuelve el código 05. Es un cajón de sastre que en realidad puede significar: * Fondos insuficientes (el banco simplemente no lo dice) * Límite de frecuencia superado * Retención temporal de seguridad * Se superó el umbral de puntuación de riesgo * Restricciones de la tarjeta (p. ej., transacciones internacionales bloqueadas) * Cuenta en revisión #### Estrategias de recuperación para "Do Not Honor" según el patrón | Señal del patrón | Causa subyacente probable | Acción recomendada | | -------------------------------------------------- | ---------------------------------------------------- | ----------------------------------------------------- | | Fallo por primera vez, el cliente está activo | Retención temporal o fondos insuficientes | Reintenta en 24–48 horas, en otra hora del día | | Fallos repetidos el mismo día cada mes | Fondos insuficientes, relacionado con el momento | Mueve el reintento a la ventana posterior al pago | | El fallo ocurre a una hora inusual (3 a. m. local) | Puntuación de riesgo de fraude | Reintenta entre las 9 a. m. y las 12 p. m. hora local | | Tarjeta nueva añadida recientemente | Restricción del emisor para tarjetas nuevas | Espera 5–7 días y luego reintenta | | Tarjeta internacional, comerciante nacional | Bloqueo de riesgo transfronterizo | Si es posible, enruta a través de un adquirente local | | Fallo después de un periodo de cargos exitosos | Retención temporal del banco o revisión de seguridad | Reintenta en 48–72 horas | Aquí es donde brillan los modelos de ML. Un humano que mira "Do Not Honor" ve un callejón sin salida. Un modelo que ha analizado millones de estos rechazos en tipos de tarjeta, emisores, geografías y patrones de tiempo puede predecir la causa subyacente y aplicar la estrategia de recuperación correcta. Los clasificadores internos de FlyCode desagregan los códigos de rechazo genéricos usando cientos de puntos de datos por transacción, convirtiendo una caja negra en un plan de recuperación accionable. *** ### Card Account Updater y Network Tokens: los héroes silenciosos Antes de enviar un correo de cobro por una tarjeta reemplazada o reemitida, asegúrate de haber activado las herramientas que pueden solucionarlo automáticamente. #### Mecanismos automáticos de actualización de tarjeta | Característica | Qué hace | Quién lo proporciona | Impacto en la recuperación | | ------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------- | ------------------------------------------------------------------------------------ | | **Card Account Updater (CAU)** | Reemplaza automáticamente los datos de tarjeta desactualizados por los nuevos de la red | Visa VAU, Mastercard ABU: disponible a través de Stripe | Evita del 60 al 80% de los fallos relacionados con credenciales | | **Tokenización de red** | Crea un token persistente que se actualiza automáticamente cuando cambia la tarjeta física | Visa, Mastercard: compatible con Stripe | Reduce los fallos de tarjeta guardada entre un 2 y un 5% en todos los tipos | | **Cargo a tarjeta de respaldo** | Cobra automáticamente una tarjeta alternativa guardada cuando falla la principal | No nativo en Stripe: disponible a través de FlyCode | Recupera del 10 al 15% de los fallos que de otro modo requerirían acción del cliente | Comprobación de implementación: Network Tokenization y Card Account Updater deberían estar activos por defecto en la mayoría de las cuentas de Stripe. Verifícalo comprobando si ves `card_updated` eventos en los registros de tus webhooks. Si no los ves, contacta con soporte de Stripe. *** ### Optimización del momento de recuperación: cuándo reintentar cada código El timing no es solo "esperar y volver a intentar". Los distintos tipos de rechazo tienen distintas ventanas óptimas de reintento. #### Momento óptimo de reintento por tipo de rechazo | Tipo de rechazo | Primer reintento | Segundo reintento | Tercer reintento | Después de 3 fallos | | ------------------------------------------- | --------------------------------------------- | --------------------------------------------------- | --------------------------------- | -------------------------------------------------------------------- | | **Fondos insuficientes** | 48–72 horas (espera al día de pago) | 5–7 días (siguiente ciclo de pago) | Días 14–15 (pago de mitad de mes) | Correo de cobro con actualización de tarjeta | | **Error de procesamiento** | 4–12 horas | 24 horas | 48 horas | Investigar: puede indicar un problema de integración | | **Do Not Honor** | 24–48 horas, otra hora del día | 4–5 días, horas de la mañana | 7–10 días | Si sigue fallando, probablemente sea un rechazo duro: cambia a cobro | | **Emisor no disponible** | 4–6 horas | 12–24 horas | 48 horas | Rara vez necesita 3 reintentos, debería funcionar pronto | | **Credenciales de tarjeta desactualizadas** | No reintentes: espera la actualización de CAU | Después de 48 horas (CAU puede haberse actualizado) | 5 días | Correo de cobro con enlace para actualizar la tarjeta | | **Se requiere autenticación** | No reintentes: envía enlace de autenticación | 3 días (correo de recordatorio) | 7 días (correo de urgencia) | Paywall en la app o restricción de funciones | *** ### Conclusión: deja de tratar todos los rechazos por igual El mayor error en la recuperación de pagos es aplicar el mismo calendario de reintentos y la misma secuencia de comunicaciones a todos los pagos fallidos. Un rechazo por fondos insuficientes y un rechazo en una tarjeta reemplazada o reemitida requieren respuestas fundamentalmente distintas. Las empresas que recuperan del 70 al 90% de sus pagos fallidos hacen tres cosas de forma diferente: clasifican cada rechazo por tipo y ajustan su estrategia en consecuencia, agotan los reintentos silenciosos antes de involucrar al cliente, y usan modelos de ML que aprenden de sus patrones de transacción específicos, no del promedio global. *** Actúa: * : obtén una auditoría de pagos gratuita, ve la distribución de tus códigos de rechazo y la tasa de recuperación por tipo. * : calcula tu ROI de recuperación. * : instala FlyCode para Stripe. *** #### Lecturas relacionadas * * * * * ## Relacionado * [Explicación de los códigos de rechazo](https://help.flycode.com/decline-codes-explained) en el Centro de ayuda * [Referencia de códigos de rechazo de Stripe](https://www.flycode.com/stripe/decline-codes) (cada código con su código de respuesta de red) * [Reglas de reintento de redes de tarjetas para pagos fallidos](https://docs.flycode.com/docs/read-more/card-network-retry-rules-for-failed-payments-visa-and-mastercard) --- # 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/subscription-payment-decline-codes-guide-for-stripe.md?ask=&goal= ``` `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.