# Un module de paiement quand aucune solution du marché ne convient > Portefeuille virtuel, système d'avoir, paiement fractionné maison : c'est le type de module de paiement que je développe quand les modules du marché ne couvrent pas exactement le besoin. - Source canonique : [https://allaux.fr/expertises/module-paiement-sur-mesure-prestashop](https://allaux.fr/expertises/module-paiement-sur-mesure-prestashop) - Langue : FR - Dernière mise à jour : 2026-07-26 ## Le besoin type Les modules de paiement du marché couvrent bien les cas standards : carte bancaire, PayPal, virement. Le besoin d'un module sur mesure apparaît quand la logique de paiement sort de ces cas classiques : un système de portefeuille virtuel alimenté par l'entreprise cliente, un mécanisme d'avoir utilisable partiellement sur plusieurs commandes, un paiement fractionné avec des règles propres à l'activité, ou encore un mode de paiement réservé à certains comptes professionnels selon leurs conditions négociées. Ce sont des besoins spécifiques qu'aucun module générique ne peut anticiper. ## Comment j'interviens sur ce genre de besoin Un module de paiement touche à l'argent et à la validation de commande : c'est une zone où une erreur peut coûter cher, en commandes non honorées ou en paiements mal comptabilisés. Je commence toujours par cadrer précisément le cycle de vie complet du paiement concerné : à quel moment le montant est-il réservé, débité, remboursable, et quels statuts de commande doivent en découler. Le développement s'appuie sur le système de paiement natif de PrestaShop plutôt que de le contourner, pour que le module reste compatible avec le reste de l'écosystème (facturation, gestion des retours, statistiques). Une attention particulière va à la gestion des cas limites : que se passe-t-il si le paiement est interrompu en cours de traitement, si le solde d'un portefeuille devient insuffisant après validation du panier, ou si deux commandes tentent d'utiliser le même avoir presque simultanément. Ces cas rares sont statistiquement les plus coûteux à laisser mal gérés. ## Facteurs qui influencent le chiffrage - **Complexité de la logique métier** — Un solde simple à débiter n'a rien à voir avec un système de plafonds, de comptes rattachés ou de règles d'attribution automatique. - **Lien avec un système externe** — Un portefeuille alimenté manuellement en back-office est plus simple qu'un solde synchronisé avec un système de gestion externe. - **Exigences de traçabilité** — Un historique détaillé des mouvements, exigé pour des raisons comptables, ajoute un travail de conception et de restitution en back-office. - **Volume de transactions attendu** — Un mécanisme rarement utilisé se traite différemment d'un mode de paiement destiné à devenir le principal canal de règlement. ## Questions à se poser avant de lancer > Le comportement attendu en cas d'échec partiel est-il défini ? Qui doit pouvoir consulter ou modifier un solde, et avec quelle traçabilité ? Le module doit-il rester compatible avec un système comptable existant ? ## FAQ ### Un module de paiement sur mesure est-il compatible avec les obligations réglementaires ? Le module s'intègre dans le cadre défini par les moyens de paiement déjà en place (carte, virement) ; il ne remplace jamais une passerelle bancaire agréée mais orchestre une logique métier autour d'elle. ### Peut-on combiner un portefeuille virtuel avec les moyens de paiement classiques ? Oui, c'est même l'usage le plus courant : un solde de portefeuille utilisé en priorité, complété par un paiement carte pour la différence. ### Comment le module gère-t-il les remboursements ? Le cycle de remboursement est cadré dès la conception, avec un mécanisme cohérent selon que le montant revient sur le portefeuille, en avoir, ou par le moyen de paiement d'origine. ### Ce type de module résiste-t-il aux mises à jour de PrestaShop ? En s'appuyant sur les hooks et le système de paiement natifs plutôt que sur des modifications du core, le module reste compatible d'une mise à jour à l'autre, sous réserve d'une vérification lors des montées de version majeures.