Guía de códigos de rechazo de pagos de suscripción para Stripe
Referencia de los códigos de rechazo de suscripciones de Stripe, rechazos suaves frente a duros, qué significa cada código y la estrategia de reintento o dunning que recupera cada uno.
Por el equipo de FlyCode. Última revisión: septiembre de 2026.
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.
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
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
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)
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)
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
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
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
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
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
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:
https://www.flycode.com/churn-audit-failed-payments: 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.
https://www.flycode.com/revenue-recovery-calculator: calcula tu ROI de recuperación.
https://marketplace.stripe.com/apps/flycode-payments: instala FlyCode para Stripe.
Lecturas relacionadas
https://www.flycode.com/blog/stripe-generic-decline-code-what-it-means-why-it-happens-and-how-flycode-recovers-the-revenue
https://www.flycode.com/blog/the-do-not-honor-decline-code-what-subscription-businesses-need-to-know
https://www.flycode.com/blog/what-are-issuer-declines-in-stripe-failed-payment-report
https://www.flycode.com/blog/subscription-ghosting-when-"insufficient-funds"-steals-your-mrr
https://www.flycode.com/blog/how-to-deal-with-failed-payments-if-you-re-using-stripe
Relacionado
Explicación de los códigos de rechazo en el Centro de ayuda
Referencia de códigos de rechazo de Stripe (cada código con su código de respuesta de red)
Última actualización
¿Te fue útil?