Changer l'état d'une commande selon le moyen de paiement dans PrestaShop

Dans PrestaShop, le module de paiement intervient dans l'attribution de l'état initial de la commande. Avant de le changer, identifiez ce qu'il signifie dans votre boutique et les actions qu'il déclenche : réservation du stock, facture, e-mail, préparation ou intégration logistique.

Ne marquez pas une commande comme payée avant la confirmation réelle de l'encaissement. Un état fait partie du flux de l'activité, ce n'est pas qu'une étiquette de couleur.

Chercher une option maintenable

1. Notez la version de PrestaShop, le module de paiement et l'état attribué actuellement.
2. Vérifiez si le module permet de configurer l'état initial.
3. Examinez la configuration de cet état et ses effets sur le paiement, le stock et les documents.
4. Si un développement est nécessaire, utilisez un module ou un mécanisme d'extension compatible avec cette version.
5. Testez le changement sur un clone avec des passerelles de test avant de l'appliquer en production.

La documentation des modules de paiement permet au développeur de vérifier le contrat de la version concernée. Ne copiez pas un correctif d'une autre branche sans vérifier le flux complet.

Référence historique : ps_cashondelivery

Dans les anciennes implémentations de ps_cashondelivery, le fichier controllers/front/validation.php appelait validateOrder() en passant l'identifiant de l'état comme deuxième argument. Une expression comme Configuration::get('PS_OS_PREPARATION') récupérait l'état configuré pour la préparation.

Cette référence aide à reconnaître une ancienne personnalisation. Ce n'est pas une instruction pour modifier le module actuel : une mise à jour peut remplacer la modification et l'implémentation peut être différente.

Des clés comme PS_OS_PAYMENT, PS_OS_CANCELED ou PS_OS_REFUND font référence à des états configurés, pas à une confirmation bancaire. Ne codez pas en dur des numéros copiés d'une autre boutique et ne supposez pas que toutes les clés d'une ancienne version existent dans la vôtre.

Tester le flux complet

Vérifiez, selon le cas, la commande en attente, la confirmation, l'échec, l'annulation et le remboursement. Incluez les notifications tardives ou répétées de la passerelle : elles ne doivent dupliquer ni les encaissements, ni les commandes, ni les e-mails.

Vérifiez l'historique de la commande, le stock, la facture et ce que voit le client. Changer l'état manuellement pour un test ne reproduit pas forcément le callback réel du module.

Si la boutique dépend d'un ancien correctif, documentez-le et préparez son remplacement avant de mettre à jour. Conservez une copie des fichiers et des données et définissez comment revenir en arrière sans perdre les nouvelles commandes.