Skip to main content

Descripción general

Dodo Payments devuelve un motivo detallado del fallo cada vez que un intento de pago no se completa correctamente. Estos motivos están estandarizados en los distintos métodos y proveedores de pago, por lo que puedes implementar una gestión coherente en tu aplicación. Cuando falla un pago, el webhook payment.failed y el objeto de pago exponen:
  • error_code — un motivo de fallo estandarizado de la tabla siguiente.
  • error_message — una explicación legible para las personas.
  • retry_attempt0 para el cargo original, 1 o superior para cada reintento programado de renovación de la suscripción.
Comprender estos motivos de fallo te permite ofrecer a los clientes información clara, decidir si vale la pena reintentar y recuperar más ingresos.

Handle Payment Failures

Una guía paso a paso para desarrolladores sobre cómo leer estos códigos desde los webhooks y la API, mostrarlos a los clientes y decidir cuándo reintentar.

Rechazos suaves y definitivos

Cada código de fallo pertenece a una de dos categorías. Esta distinción determina si debes reintentar con el mismo método de pago o pedir al cliente que use uno nuevo. Para las renovaciones de suscripciones, Dodo Payments aplica esta distinción automáticamente: los rechazos suaves se vuelven a intentar mediante Reintentos de pago de suscripciones, mientras que los rechazos definitivos finalizan inmediatamente la cadena de reintentos y se gestionan mejor con Dunning de suscripciones.
Nunca reveles al cliente el motivo real de STOLEN_CARD, LOST_CARD, PICKUP_CARD o FRAUDULENT. Mostrar estos motivos puede alertar a un actor fraudulento. Muestra siempre al cliente un mensaje de rechazo genérico (por ejemplo, “Se rechazó tu tarjeta. Ponte en contacto con tu banco o utiliza otra tarjeta.”) y registra únicamente el código específico de forma interna.

Motivos de fallo de transacciones

La tabla siguiente enumera cada código de fallo, su tipo de rechazo, si el cliente puede resolverlo, una descripción y la acción recomendada.
Error del usuario indica si el cliente puede resolver el rechazo del pago. Cuando Yes, el cliente puede actuar para solucionar el problema (por ejemplo, introduciendo correctamente los datos de la tarjeta). Cuando No, el rechazo se debe a problemas a nivel del sistema o a restricciones bancarias que el cliente no puede resolver directamente.
Una tarjeta también puede rechazarse cuando el propio motor de riesgo del banco emisor marca al titular como un cliente de alto riesgo, independientemente del comercio o de los detalles de la transacción. Estos rechazos suelen aparecer como códigos genéricos, como DO_NOT_HONOR, GENERIC_DECLINE, CARD_DECLINED, TRANSACTION_NOT_APPROVED o FRAUDULENT. En estos casos, el banco no comparte el motivo específico, y ni Dodo Payments ni el comercio pueden anular la decisión. Pide al cliente que se ponga en contacto con su banco para resolver la marca o que utilice otra tarjeta o método de pago.

Gestión programática de fallos

Lee error_code del webhook payment.failed o del objeto de pago, asígnalo a la acción recomendada anterior y decide si debes reintentar. Para las renovaciones de suscripciones, los rechazos suaves se reintentan automáticamente; consulta Reintentos de pago de suscripciones. Para los errores a nivel de API y de lógica empresarial (como PAYMENT_NOT_SUCCEEDED o REFUND_WINDOW_EXPIRED) que no sean rechazos de tarjeta, consulta la referencia de Códigos de error.

Relacionado

Handle Payment Failures

Guía completa para detectar, mostrar y reintentar pagos fallidos.

Error Codes

Códigos de error de API y de lógica empresarial para fallos que no son rechazos.

Subscription Payment Retries

Reintentos automáticos que recuperan rechazos suaves en las renovaciones de suscripciones.

Subscription Dunning

Secuencias de correo electrónico que recuperan rechazos definitivos solicitando actualizar el método de pago.

Soporte

Para obtener ayuda adicional con los fallos de transacciones o problemas de integración, ponte en contacto con nuestro equipo de soporte en support@dodopayments.com.
Última modificación el 21 de julio de 2026