[Bug] process_payment() does not bail out on an API error response → checkout fails with a misleading generic message
Summary
In inc/Gateway/WC_HelloAsso_Gateway.php, when the HelloAsso API returns anything other than a valid checkout-intent (e.g. HTTP 400), the code logs the error but does not return: execution continues, it logs "Paiement traité avec succès" ("Payment processed successfully"), then accesses ->redirectUrl on an object that has no such property.
The value handed back to WooCommerce was captured on the woocommerce_payment_successful_result filter, for a single submission:
{"result":"success","redirect":null,"order_id":6057}
WooCommerce therefore receives a success with a null redirect. The checkout script fails while trying to use result.redirect, and since the response carries no messages field, it falls back to i18n_checkout_error:
There was an error processing your order. Please check for any charges in your payment method and review your order history before placing the order again.
The order stays pending. That message is a poor fit here: it tells the customer to check for a possible charge when no payment was ever initiated — the API refused to create the checkout-intent in the first place. On a donation platform, it alarms the donor and discourages a retry.
If they do retry without reloading the page, the second submission fails the nonce check (class-wc-checkout.php, "We were unable to process your order, please try again"). The customer thus hits two unrelated error messages, neither of which mentions that their first name is the problem.
In the logs, an ERROR is immediately followed by an INFO ... success, which makes diagnosis confusing.
Versions
- Plugin: 1.1.2
- WooCommerce: 11.0.1
- WordPress: 7.0.4
- PHP: 8.3.6
- Mode: production (
test_mode: no)
Steps to reproduce
- Connect the HelloAsso account (OAuth OK, webhook OK).
- Place an order using a first name rejected by the HelloAsso API — for example
TEST.
- Submit the payment.
The API responds:
HTTP 400
{"errors":[{"code":"ArgumentInvalid","message":"Le champ prénom est invalide"}]}
Actual behaviour
debug.log:
PHP Warning: Undefined property: stdClass::$redirectUrl in .../inc/Gateway/WC_HelloAsso_Gateway.php on line 871
WooCommerce log (wc-logs/helloasso-*.log):
ERROR [ERROR] Erreur API HelloAsso - {"order_id":6057,"response_code":400,
"response_body":"{\"errors\":[{\"code\":\"ArgumentInvalid\",\"message\":\"Le champ prénom est invalide\"}]}"}
ERROR [ERROR] Réponse API invalide - {"order_id":6057,"response_code":400, ...}
INFO [INFO] Paiement traité avec succès - {"order_id":6057,"redirect_url":"unknown"}
The customer is left on a broken checkout page with no indication of what went wrong.
Expected behaviour
The payment stops cleanly and the error message returned by the HelloAsso API is surfaced to the user, so they can correct their input.
Root cause
WC_HelloAsso_Gateway.php, lines ~851-872: the guard clause logs without interrupting the flow.
$response_data = json_decode($response_body);
if (!$response_data || !isset($response_data->redirectUrl)) {
helloasso_log_error('Réponse API invalide', array(...));
// no return -> execution continues
}
helloasso_log_info('Paiement traité avec succès', array(
'redirect_url' => $response_data->redirectUrl ?? 'unknown'
));
return array(
'result' => 'success',
'redirect' => json_decode($response_body)->redirectUrl // line 871: warning
);
Suggested fix
$response_data = json_decode($response_body);
if (!$response_data || !isset($response_data->redirectUrl)) {
helloasso_log_error('Réponse API invalide', array(
'order_id' => $order_id,
'response_body' => $response_body,
'response_code' => $response_code
));
$message = __('Le paiement HelloAsso n\'a pas pu être initialisé.', 'helloasso');
if (isset($response_data->errors[0]->message)) {
$message = $response_data->errors[0]->message;
}
wc_add_notice($message, 'error');
return array(
'result' => 'failure',
'messages' => $message
);
}
helloasso_log_info('Paiement traité avec succès', array(
'order_id' => $order_id,
'redirect_url' => $response_data->redirectUrl
));
$order->save();
return array(
'result' => 'success',
'redirect' => $response_data->redirectUrl
);
Surfacing the API's message matters here: HelloAsso's identity validation can reject input that a donor considers perfectly legitimate, and with no visible feedback they abandon the donation without understanding why.
[Bug]
process_payment()does not bail out on an API error response → checkout fails with a misleading generic messageSummary
In
inc/Gateway/WC_HelloAsso_Gateway.php, when the HelloAsso API returns anything other than a valid checkout-intent (e.g. HTTP 400), the code logs the error but does not return: execution continues, it logs "Paiement traité avec succès" ("Payment processed successfully"), then accesses->redirectUrlon an object that has no such property.The value handed back to WooCommerce was captured on the
woocommerce_payment_successful_resultfilter, for a single submission:{"result":"success","redirect":null,"order_id":6057}WooCommerce therefore receives a success with a null redirect. The checkout script fails while trying to use
result.redirect, and since the response carries nomessagesfield, it falls back toi18n_checkout_error:The order stays
pending. That message is a poor fit here: it tells the customer to check for a possible charge when no payment was ever initiated — the API refused to create the checkout-intent in the first place. On a donation platform, it alarms the donor and discourages a retry.If they do retry without reloading the page, the second submission fails the nonce check (
class-wc-checkout.php, "We were unable to process your order, please try again"). The customer thus hits two unrelated error messages, neither of which mentions that their first name is the problem.In the logs, an
ERRORis immediately followed by anINFO ... success, which makes diagnosis confusing.Versions
test_mode: no)Steps to reproduce
TEST.The API responds:
Actual behaviour
debug.log:WooCommerce log (
wc-logs/helloasso-*.log):The customer is left on a broken checkout page with no indication of what went wrong.
Expected behaviour
The payment stops cleanly and the error message returned by the HelloAsso API is surfaced to the user, so they can correct their input.
Root cause
WC_HelloAsso_Gateway.php, lines ~851-872: the guard clause logs without interrupting the flow.Suggested fix
Surfacing the API's
messagematters here: HelloAsso's identity validation can reject input that a donor considers perfectly legitimate, and with no visible feedback they abandon the donation without understanding why.