GoCardless refer_to_payer: MS02, MS03, RR04 and SL01 in a SEPA collection

One cause, four codes

All three rows come from the failed payments table (payments · failed) in GoCardless's SEPA Core documentation. Unlike other causes, none of them says the mandate is cancelled: the customer is still authorised for you to collect, even though this particular debit did not go through.

What lies behind each code

MS02 is the clearest answer: the customer told their bank not to pay that direct debit. The connector notes in its code that this is the combination it saw in a test SEPA payment in the GoCardless sandbox. MS03 and RR04 are the opposite: the payment fails and the bank gives no reason, usually for regulatory reasons, so the only way to find out what happened is to ask the customer. SL01 points to the account: their bank limits the direct debits that can be charged to it, and only the account holder can change that with their bank.

With MS02, RR04 and SL01, presenting the debit again without first talking to the customer usually ends the same way and may cost another fee. MS03 has an exception: according to Success+ guidance, in Austria, Belgium, Germany, Luxembourg and Slovakia MS03 counts as insufficient funds, and Success+ can retry it. If so, the event arrives with will_attempt_retry set to true.

What Odoo does with the connector

The transaction is opened from the invoice, with the “Payment Transaction” button at the top; the transactions menu only appears in developer mode, and in Odoo 20 it does not exist. The connector stores the cause in the “GoCardless Cause” field, not the SEPA code, and shows “GoCardless could not collect this payment (refer_to_payer).”. Then it follows what the event says:

• If will_attempt_retry comes as true, the transaction is “Pending”, the “Success+ Will Retry” checkbox is ticked and the message says so: “Success+ will retry it automatically; there is nothing to do.”. The retry button does not appear.
• Otherwise, the transaction moves to “Error” and the “Retry collection” button appears, if retries remain. If Odoo had already treated the collection as done, the connector cancels its payment and the invoice becomes due for payment again.
• The mandate is left alone. refer_to_payer is not among the causes for which the connector archives a mandate, so the customer's payment method remains available for the next collection.

This last point is deliberate: archiving the mandate over a one-off refusal would force the customer to sign a new one for no reason.

The connector writes these texts in English, so in an English-language Odoo they appear exactly as quoted here, whether a user or a scheduled action triggers them: “GoCardless could not collect this payment (refer_to_payer).” and “Success+ will retry it automatically; there is nothing to do.”.

What to do for each code

Odoo does not tell you which of the four codes arrived: the connector only stores the cause. You see the code in GoCardless. According to its help centre, the reason for each failure appears in the payment timeline, in the Dashboard (“You are able to view the reason for a payment failure in the status timeline of the payment in your GoCardless dashboard.”). In advanced mode, the exact code also comes in the event (details.reason_code), and the Dashboard keeps the deliveries of the last 3 months under Developers > Webhooks, with their content.

Once the customer confirms the collection will go through, use “Retry collection” on the transaction and confirm the fee notice. The connector replies “Retry requested. GoCardless will confirm the new charge date.” and leaves it pending. Remember the limit: a payment can be retried at most 3 times (“Payments can be retried up to 3 times.”).

With our connector

In Odoo 17, 18, 19 and 20 the connector turns refer_to_payer into an outstanding invoice with the cause in view and a mandate that remains valid. It does not guess the SEPA code: Odoo stores the cause on the transaction, and you check the code in GoCardless. The decision to collect again is yours, after talking to the customer.

Keep reading