GoCardless internal_server_error and request_timed_out: the failure is on GoCardless

What GoCardless says

GoCardless groups these reasons under the type gocardless, the one for errors that occur inside GoCardless: “These errors occurred within GoCardless while processing your request.”. Its HTTP status code table says this about the two codes:

On its limits page, GoCardless also sets how long a request may take: 29 seconds (“Request timeout 29 seconds”).

Three cases the connector does not handle the same way

The connector waits up to 30 seconds for GoCardless's response on each request. With a charge, a refund or a retry, Odoo can run into three different situations:

• GoCardless answers with a 500 or a 504, with the reason in the response.
• GoCardless does not answer: the connection drops or the 30 seconds run out.
• The failure comes when applying an event, when the connector asks GoCardless for the payment the event refers to.

What the connector does

With a 500 or a 504. The connector only repeats a request when it gets no answer or after a 429. With a 500 or a 504 there is an answer, so it treats it as a rejection. On a charge, the transaction moves to “Error” with “GoCardless rejected the request.” and, below it, GoCardless's message with the reason and the request_id in square brackets. The hourly task does not resend a transaction in error. If GoCardless did create the charge anyway, its first event links it: each charge carries the Odoo transaction reference in its metadata, the connector finds it with that reference and applies the payment status. A transaction in error thus goes back to “Pending” or moves to “Confirmed”.

No answer. The connector repeats the request once, with the same idempotency key. If nobody answers either, it does not give the charge up for lost: the transaction stays pending with “GoCardless did not answer, so it is not known yet whether it took the request. It will be sent again, safely, within the hour.”. The hourly task sends it again with the same key; if GoCardless had already created it, it answers 409 and the connector adopts what already exists.

When applying an event. With each event for a payment, the connector asks GoCardless for that payment. If that query fails, the webhook answers 500 so that GoCardless sends the delivery again, and the events already applied are not applied twice. The hourly recovery also does not leave behind an event that failed.

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 rejected the request.” and “GoCardless did not answer, so it is not known yet whether it took the request. It will be sent again, safely, within the hour.”.

What to do

1. Open the transaction from the invoice, with the “Payment Transaction” button at the top; the transactions menu only shows in developer mode, and it does not exist in Odoo 20. If the message names internal_server_error or request_timed_out, the failure was on GoCardless's side, not the customer's or their mandate's.
2. Before charging the invoice again, look for the charge in the GoCardless Dashboard: the connector sets the reference of its Odoo transaction as the description of each charge. If it is there, do not charge again; its event will link the transaction.
3. If it is not there, charge the invoice again with the customer's saved payment method. A new charge is another transaction, with another idempotency key: that is why it is worth checking first.
4. If it keeps happening, write to GoCardless support with the request_id from the message: their documentation asks you to include it when you contact their support.

With our connector

In Odoo 17, 18, 19 and 20 the connector separates a GoCardless error from a request with no answer: the first stays in error with its request_id, the second stays pending and is resent with the same key, and in both cases the event of a charge that does exist links it to its transaction.

Keep reading