GoCardless refer_to_payer: MS02, MS03, RR04 y SL01 en un cobro SEPA

Una causa, cuatro códigos

Las tres filas vienen de la tabla de fallos de pago (payments · failed) de la documentación de GoCardless para SEPA Core. A diferencia de otras causas, ninguna dice que el mandato se cancele: el cliente sigue autorizado a que le cobres, aunque este adeudo concreto no haya pasado.

Qué hay detrás de cada código

MS02 es la respuesta más clara: el cliente le dijo a su banco que no pagara ese recibo. El conector anota en su código que es la combinación que vio en un pago SEPA de prueba del sandbox de GoCardless. MS03 y RR04 son lo contrario: el pago falla y el banco no da el motivo, normalmente por razones regulatorias, así que la única forma de saber qué pasa es preguntar al cliente. SL01 apunta a la cuenta: su banco limita los adeudos directos que se le pueden cargar, y eso solo lo puede cambiar el titular con su banco.

Con MS02, RR04 y SL01, volver a presentar el adeudo sin hablar antes con el cliente suele acabar igual y puede costar otra comisión. MS03 tiene una excepción: según la guía de Success+, en Austria, Bélgica, Alemania, Luxemburgo y Eslovaquia MS03 cuenta como falta de fondos, y Success+ puede reintentarlo. Si es así, el evento llega con will_attempt_retry a true.

Lo que hace Odoo con el conector

La transacción se abre desde la factura, con el botón «Transacción de pago» de arriba; el menú de transacciones solo sale en modo desarrollador, y en Odoo 20 no existe. El conector guarda la causa en el campo «Causa según GoCardless», no el código SEPA, y enseña «GoCardless no pudo cobrar este pago (refer_to_payer).». Después sigue lo que diga el evento:

• Si will_attempt_retry viene a true, la transacción queda «Pendiente», la casilla «Success+ reintentará» se marca y el mensaje lo dice: «Success+ lo reintentará automáticamente; no hay que hacer nada.». El botón de reintentar no sale.
• Si no, la transacción pasa a «Error» y sale el botón «Reintentar el cobro», si quedan reintentos. Si Odoo ya daba el cobro por hecho, el conector anula su pago y la factura vuelve a estar pendiente de cobro.
• El mandato no se toca. refer_to_payer no está entre las causas con las que el conector archiva un mandato, así que el método de pago del cliente sigue disponible para el siguiente cobro.

Este último punto es deliberado: archivar el mandato por un rechazo puntual obligaría al cliente a firmar otro sin motivo.

Los dos mensajes los escribe el conector al aplicar el evento, sin nadie delante. En una base de datos creada en castellano salen así; en una creada en inglés y pasada después a castellano salen en inglés: «GoCardless could not collect this payment (refer_to_payer).» y «Success+ will retry it automatically; there is nothing to do.».

Qué hacer según el código

Odoo no te dice cuál de los cuatro códigos llegó: el conector solo guarda la causa. El código lo ves en GoCardless. Según su centro de ayuda, el motivo de cada fallo sale en la cronología del pago, en el Dashboard («You are able to view the reason for a payment failure in the status timeline of the payment in your GoCardless dashboard.»). En el modo avanzado, el código exacto también va en el evento (details.reason_code), y el Dashboard guarda los envíos de los últimos 3 meses en Developers > Webhooks, con su contenido.

Cuando el cliente confirme que el cobro pasará, usa «Reintentar el cobro» en la transacción y confirma el aviso de la comisión. El conector responde «Reintento solicitado. GoCardless confirmará la nueva fecha de cargo.» y la deja pendiente. Recuerda el límite: un pago se puede reintentar como mucho 3 veces («Payments can be retried up to 3 times.»).

Con nuestro conector

En Odoo 17, 18, 19 y 20 el conector convierte refer_to_payer en una factura pendiente con la causa a la vista y un mandato que sigue valiendo. No adivina el código SEPA: Odoo guarda la causa en la transacción, y el código lo consultas en GoCardless. La decisión de volver a cobrar es tuya, después de hablar con el cliente.

Sigue leyendo