Module de paiement PrestaShop : les vérifications utiles

Partir de la boutique réellement exploitée

Notez la version de PrestaShop, les extensions qui modifient le panier et le thème qui affiche le checkout. Ajoutez les devises, les pays servis et les types de commandes. Une démonstration sur une boutique standard ne suffit pas si votre boutique applique des règles particulières. Préparez un panier courant et un panier avec une modification de prix autorisée. Le fournisseur du module doit répondre sur cette configuration précise, avec un périmètre de support identifiable et une procédure de mise à jour compréhensible.

Plugins de paiement pour votre e-commerce — Soon

Vérifier le compte de paiement derrière le module

Un module est une interface technique ; le PSP conserve ses conditions d’ouverture de compte, d’éligibilité et de règlement des fonds. Avant de planifier la mise en production, confirmez que le compte concerné peut traiter les transactions prévues. Vérifiez également les méthodes disponibles pour ce compte et les devises utilisées. La présence d’une option dans le back-office du module ne prouve pas qu’elle fonctionnera dans votre contexte. Demandez un exemple complet reliant la configuration à une transaction vérifiable.

Intégration et API

Tracer les états jusqu’à la commande

Écrivez ce que chaque résultat de paiement doit changer dans PrestaShop. Quand une commande peut-elle être préparée ? Que voit le client si la confirmation n’est pas encore reçue ? Une visite de la page de retour ne constitue pas une preuve de paiement. Le module doit utiliser le résultat serveur prévu par le fournisseur et gérer les notifications répétées. La documentation de Stripe et de Mollie est utile pour comprendre ce principe, même lorsque l’interface de la boutique masque les détails techniques.

Page de paiement hébergée

Préparer les opérations après l’achat

Le quotidien comprend des recherches de transaction, des annulations commerciales et parfois des remboursements. Vérifiez quelles actions existent réellement dans le module et lesquelles nécessitent une autre interface. Une annulation de commande ne doit pas être confondue avec une demande de remboursement acceptée par le PSP. Déterminez qui possède les droits nécessaires et où conserver la référence du résultat. Une solution qui simplifie l’achat mais rend les exceptions introuvables risque de déplacer le travail vers le support.

Tester une mise à jour et un retour arrière

La recette doit couvrir un paiement confirmé, un échec, une fenêtre fermée et une notification tardive. Ajoutez un événement reçu deux fois pour vérifier qu’aucune double expédition n’est déclenchée. Avant une mise à jour, conservez les éléments de configuration nécessaires et préparez une procédure de retour compatible avec les commandes déjà engagées. Le retour arrière logiciel ne doit pas effacer l’existence d’une transaction. Désignez la personne qui décide de suspendre de nouvelles commandes si le résultat ne peut plus être suivi correctement.

Positionner OrsunPay sans anticiper une publication

Les plugins commerce OrsunPay, dont PrestaShop, figurent dans la feuille de route. Leur publication publique n’est pas confirmée : cette page n’est donc pas une invitation à télécharger un module disponible. La compatibilité et les fonctions de chaque version devront être vérifiées lors d’une éventuelle publication. Une intégration via les outils documentés peut faire l’objet d’un périmètre convenu séparément. Les comptes PSP demeurent les vôtres, et OrsunPay ne garantit ni approbation du compte ni routage automatique vers le fournisseur le moins cher.

• Consigner les versions de plateforme et d’extensions.
• Vérifier les statuts qui autorisent la préparation.
• Tester un webhook tardif et un webhook répété.
• Décrire les opérations de remboursement réellement disponibles.
• Préparer le responsable et les conditions du retour arrière.

Sources

• Documentation Stripe sur les webhooks
• Documentation Mollie sur les paiements