Stripe, PayPal, Mollie, Alma… les modules de paiement ne manquent pas sur le marketplace PrestaShop. Pourtant, de nombreux marchands finissent par avoir besoin d'un module sur-mesure. Pas par caprice technique, mais parce que leur cas d'usage ne rentre pas dans les cases des solutions standards.
Quand les modules du marché ne suffisent plus
Les modules marketplace couvrent les parcours classiques : paiement par carte, PayPal, virement. Mais ils montrent leurs limites dès que le besoin sort du standard.
Paiement fractionné sans Alma ou Oney — Vous voulez proposer du 3× ou 4× sans passer par un tiers qui prend une commission ? Un module sur-mesure gère la logique de split en interne : première échéance à la commande, les suivantes prélevées automatiquement aux dates prévues.
Paiement B2B à 30/60 jours — Dans le B2B, le paiement à la commande est rarement la norme. Vos clients pros veulent passer commande et payer à réception de facture. Un module sur-mesure affiche cette option uniquement pour les groupes clients autorisés, avec plafond d'encours et relance automatique.
Multi-PSP avec routage intelligent — Au-delà d'un certain volume, concentrer tous vos paiements sur un seul PSP est risqué. Si Stripe tombe, votre CA tombe avec. Un module multi-PSP route les transactions vers le PSP disponible avec les meilleures conditions selon le montant, la devise ou le pays.
Architecture technique d'un module de paiement
Le hook paymentOptions
Tout module de paiement PrestaShop commence par le hook paymentOptions. C'est lui qui affiche votre méthode de paiement sur la page de checkout. Vous déclarez un objet PaymentOption avec le nom, la description, et l'action (redirection ou formulaire inline). En PS 9, ce hook reste le point d'entrée standard.
Le flux de transaction
Le flux classique en trois temps : initiation (le client choisit la méthode et clique "Payer"), traitement (redirection vers le PSP ou formulaire sécurisé iframe), et confirmation (retour sur votre site avec validation de la commande). La commande PrestaShop est créée avant la redirection avec le statut "En attente de paiement", puis mise à jour à la confirmation.
La confirmation par webhook
Ne faites jamais confiance au retour navigateur. Le client peut fermer son navigateur après le paiement, ou le redirect peut échouer. Le seul mécanisme fiable est le webhook (aussi appelé IPN ou notification serveur-à-serveur). Votre module expose un endpoint que le PSP appelle avec le résultat du paiement. C'est ce webhook qui met à jour le statut de la commande.
Sécurité : PCI DSS en pratique
Dès que vous touchez au paiement par carte, la norme PCI DSS s'applique. Mais le niveau d'exigence dépend de votre architecture.
Redirection complète (Stripe Checkout, PayPal) — Les données de carte ne transitent jamais par votre serveur. Vous remplissez un questionnaire d'auto-évaluation SAQ-A. C'est le cas le plus simple.
Formulaire intégré (Stripe Elements, iframe PSP) — Le formulaire s'affiche sur votre page mais les données vont directement au PSP. Niveau SAQ A-EP : plus d'exigences sur la sécurité de votre serveur (TLS, headers de sécurité, CSP).
Règle d'or : ne stockez jamais de données de carte sur votre serveur PrestaShop. Pas de numéro de carte, pas de CVV, même chiffré. Utilisez la tokenisation fournie par votre PSP — un token remplace le numéro de carte pour les transactions récurrentes.
Paiement B2B : les spécificités
Le B2B a des besoins que les modules grand public ignorent complètement.
Paiement par bon de commande — Le client pro passe commande avec un numéro de PO (Purchase Order). La commande est validée immédiatement, le paiement arrivera plus tard. Le module gère la vérification du numéro de PO, l'encours client, et les relances.
Paiement différé avec encours — Chaque client a un plafond d'encours. Le module vérifie en temps réel que la commande ne dépasse pas le plafond avant d'autoriser le paiement différé. En cas de dépassement, il bascule automatiquement sur le paiement immédiat.
Paiement par virement avec réconciliation — Le client paie par virement bancaire. Le module génère une référence unique par commande pour identifier le virement dans le relevé bancaire et confirmer automatiquement la commande.
Choisir son PSP
Stripe offre la meilleure API du marché, une documentation exemplaire, et une flexibilité maximale. Idéal pour les développeurs et les marchands qui veulent personnaliser leur parcours de paiement.
PayPal apporte une base d'utilisateurs massive et la confiance des consommateurs. Incontournable en complément d'un paiement par carte.
PSP bancaires (Worldline/Sips, Adyen, Payzen/Lyra) — Préférés pour les volumes importants et les négociations de commissions. Les API sont parfois moins ergonomiques, mais les conditions financières sont meilleures au-delà de 100 000 € de CA mensuel.
Mon conseil : combinez deux solutions minimum. Un PSP principal (Stripe ou bancaire) + PayPal en complément. Le module sur-mesure vous permet de router intelligemment entre les deux.
Besoin d'un module de paiement sur-mesure ?
Paiement fractionné, B2B, multi-PSP — décrivez votre besoin et je vous propose une solution technique adaptée avec devis sous 24h.
Demander un devis gratuit