« Order not found » — ce message apparaît dans les journaux d’un site qui utilise Mollie comme passerelle de paiement, alors même que le client a bien payé et que Mollie confirme la transaction dans son propre tableau de bord. La commande WooCommerce, elle, reste bloquée au statut « en attente », comme si le paiement n’avait jamais été traité. Ce billet ne traite pas la configuration initiale de Mollie, déjà fonctionnelle sur ces sites, mais un symptôme précis qui apparaît par intermittence sur des commandes autrement normales.
Le scénario exact du bug
Le parcours d’achat classique avec Mollie fonctionne ainsi : WooCommerce crée la commande en base, redirige le client vers la page de paiement hébergée par Mollie, puis attend soit le retour du client sur le site, soit un webhook envoyé directement par les serveurs de Mollie confirmant le statut final. Le problème survient quand ce webhook arrive extrêmement vite — parfois en moins d’une seconde après la redirection — alors que l’écriture de la commande en base de données WordPress n’est pas encore totalement terminée côté serveur, notamment si un cache d’objet ou une réplication de base introduit un léger délai de propagation.
Le gestionnaire de webhook interroge alors wc_get_order( $order_id ) avant que cet identifiant ne soit réellement lisible, reçoit un résultat vide, et journalise l’erreur « Order not found » avant d’abandonner le traitement de la notification.
Diagnostic : confirmer la course
Pour confirmer cette hypothèse, il faut comparer l’horodatage de création de la commande en base avec celui de réception du webhook, généralement disponible dans les journaux d’accès du serveur. Un écart de quelques centaines de millisecondes entre les deux événements, avec le webhook arrivant en premier, confirme la course :
add_action( 'woocommerce_api_wc_gateway_mollie', function() {
error_log( sprintf(
'Webhook Mollie reçu à %s pour commande %s',
microtime( true ),
$_GET['order_id'] ?? 'inconnu'
) );
}, 1 );
Correctif immédiat : retenter avant d’abandonner
La solution robuste consiste à ne jamais abandonner au premier échec de lecture de la commande, mais à retenter la lecture après une courte pause, avec un nombre limité de tentatives avant d’enregistrer un véritable échec :
function wpm_recuperer_commande_avec_retry( $order_id, $tentatives = 3 ) {
for ( $i = 0; $i < $tentatives; $i++ ) {
$commande = wc_get_order( $order_id );
if ( $commande instanceof WC_Order ) {
return $commande;
}
usleep( 300000 ); // pause de 300 millisecondes avant nouvelle tentative
}
return false;
}
Cette approche coûte quelques centaines de millisecondes supplémentaires sur les rares cas concernés, un délai négligeable comparé au risque de laisser une commande payée bloquée indéfiniment au statut « en attente ».
Correctif de fond : ne pas rediriger trop tôt
La cause racine se trouve souvent en amont : certaines intégrations redirigent le client vers Mollie avant que la transaction WooCommerce (wc_transaction_query( 'commit' ) implicite en fin de requête) ne soit pleinement validée côté base de données, en particulier sur des architectures avec réplication ou cache d'objet persistant comme Redis. S'assurer que l'écriture de la commande est bien validée avant l'appel à l'API Mollie qui initie le paiement réduit fortement la fréquence de cette course, sans pour autant l'éliminer totalement dans les cas de forte latence réseau.
S'appuyer sur la file d'Action Scheduler en filet de sécurité
Au-delà du retry immédiat, une tâche planifiée via Action Scheduler, exécutée quelques minutes après la création de toute commande encore en attente avec un identifiant de transaction Mollie renseigné, permet de revérifier son statut réel auprès de l'API Mollie et de corriger automatiquement les cas résiduels qui auraient échappé au retry initial.
- Le retry avec pause courte règle la grande majorité des cas de course immédiate.
- Vérifier que la commande est bien validée en base avant la redirection vers Mollie réduit la fréquence du symptôme.
- Une tâche planifiée de rattrapage sécurise les cas résiduels sans intervention manuelle.
Ne loggez jamais un échec de webhook comme une erreur définitive sans distinguer une commande réellement inexistante d'une commande simplement pas encore lisible : la confusion des deux cas retarde énormément le diagnostic.
En résumé
Le message « Order not found » sur un webhook Mollie qui arrive trop vite n'est pas un bug de Mollie, mais une course de timing côté infrastructure WordPress. Un mécanisme de nouvelle tentative avec pause courte, combiné à une tâche planifiée de rattrapage, élimine ce symptôme sans jamais avoir à toucher à l'intégration Mollie elle-même.
