Conditions de paiement différé : laisser les clients professionnels payer sur facture

PrestaShop ne propose pas de workflow natif pour les délais de paiement ou les limites de crédit, les chemins du back-office ci-dessous couvrent PrestaShop 1.6, 1.7, 8 et 9 ; les libellés varient légèrement selon les versions. Les conditions, les décisions de crédit et la comptabilité relèvent de vous et de votre expert-comptable, pas de la plateforme.

En B2C, le client paie avant que le colis quitte votre entrepôt. En B2B, le colis part d’abord et l’argent arrive 30, 60, parfois 90 jours plus tard, parce que l’acheteur n’est pas une personne avec une carte bancaire, mais une entreprise avec un cycle de comptabilité fournisseurs. Un responsable achats ne peut pas régler par carte au moment du paiement : la commande passe par une validation, reçoit un code budgétaire, puis le service financier la règle lors d’une échéance fixe. Imposer un paiement immédiat par carte, c’est sortir l’acheteur de son propre processus d’approvisionnement, exactement l’endroit où les commandes finissent par mourir. Proposer le « paiement sur facture » supprime cette friction. Le point délicat, c’est que PrestaShop fournit des modules de paiement hors ligne (virement bancaire, chèque) qui valident une commande sans encaisser d’argent, mais ne propose aucun workflow natif complet pour les délais de paiement / limites de crédit. La vraie question à laquelle répond cet article est donc précise et concrète : comment intégrer concrètement des conditions de paiement différé dans le tunnel de commande PrestaShop, quel mode de paiement, quel état de commande, quel filtrage par groupe, et comment empêcher un client de commander au-delà de sa limite de crédit ?

Cet article est le guide de mise en œuvre du dossier. Décider quelles entreprises méritent d’obtenir des délais de paiement au départ, vérification, demande d’ouverture de compte, est un sujet à part, traité dans les demandes d’ouverture de compte professionnel. Ici, nous partons du principe que le client est déjà approuvé et nous posons la question suivante : que doit maintenant faire PrestaShop ?

Ce que signifie « payer sur facture » au niveau de PrestaShop

Si l’on retire le vocabulaire financier, une commande à paiement différé est simplement une commande que PrestaShop accepte sans encaisser d’argent, puis suit comme impayée jusqu’à ce que vous la marquiez manuellement comme payée. Pour que cela fonctionne proprement, trois conditions doivent être réunies :

• Un mode de paiement qui n’encaisse pas d’argent. Le client arrive à l’étape de paiement, choisit « Payer sur facture », et la commande est validée, pas de PSP, pas de carte, pas de redirection. PrestaShop prend déjà en charge ce modèle : le module natif ps_wirepayment (virement bancaire) fait exactement cela, en plaçant la commande dans un état impayé et en affichant vos coordonnées bancaires au client. Un mode de paiement à échéance repose sur le même mécanisme, avec un libellé différent sur la facture.
• Un état de commande qui dit « ce montant nous est dû ». La commande ne doit pas rester dans « Paiement accepté ». Il lui faut un état où paid = 0, tout en étant une vraie commande expédiable, soit l’état natif En attente de paiement par virement bancaire, soit, mieux, un état personnalisé que vous créez (voir ci-dessous).
• Un filtre pour que seuls les acheteurs B2B approuvés voient ce mode. Un client particulier ne doit jamais se voir proposer de « payer plus tard ». Ce filtre est un groupe client, le même mécanisme de groupes sur lequel repose le reste de ce dossier.

Une fois ces trois éléments correctement configurés, le reste relève du processus, pas de la plateforme.

Étape 1, Réserver le mode de paiement à un groupe B2B approuvé

Dans Clients → Groupes, vous avez déjà (ou devriez créer) un groupe pour les comptes professionnels vérifiés, appelez-le Professionnels, Conditions accordées. La création des groupes et ce que chacun peut voir constituent un sujet à part ; si vous n’utilisez pas encore les prix ou la visibilité par groupe, commencez par les groupes clients dans PrestaShop.

Le levier qui masque réellement le mode se trouve dans Paiement → Préférences / Moyens de paiement (le libellé exact varie selon la version), dans la section des restrictions des modules de paiement. C’est là que vous définissez les restrictions par groupe, ainsi que les restrictions par devise et par pays, pour chaque module de paiement. Restreignez votre module de paiement sur facture au seul groupe Professionnels, Conditions accordées. Le mode apparaît alors au paiement pour un acheteur approuvé et est tout simplement absent pour tous les autres, pas de code conditionnel dans le thème, aucun risque qu’un acheteur particulier tombe sur un paiement à 30 jours nets. En coulisses, ces choix sont stockés dans la table de restrictions PREFIX_module_group (souvent ps_module_group) et appliqués lorsque le cœur assemble les options de paiement disponibles pour le groupe du client courant ; vous lui fournissez simplement le bon groupe.

Étape 2, Créer un état de commande dédié (ne réutilisez pas « En attente de paiement »)

Vous pouvez placer ces commandes dans l’état standard « En attente de paiement par virement bancaire », mais cela brouille votre tableau de bord : les vraies commandes par virement et les factures à 60 jours se ressemblent, et vous perdez la possibilité de filtrer « ce qui est à échéance et en vieillissement ». Créez un état dédié dans Paramètres de la boutique → Paramètres des commandes → États. Réglages recommandés :

Le commutateur interne le plus important est paid sur l’état de commande (l’objet OrderState et sa propriété paid). Quand il vaut 0, PrestaShop considère toujours la commande comme due, ce qui vous permet de filtrer les commandes impayées/à échéance dans une seule liste (PrestaShop n’a pas de grand livre natif de suivi de l’ancienneté des créances. Il faut un module dédié pour cela) et évite que la commande gonfle vos totaux « paiement accepté ». Lorsque vous recevez ensuite le virement bancaire, vous passez la commande à Paiement accepté et PrestaShop la rapproche. Qu’est-ce que cela vous apporte concrètement ? Un back-office où « l’argent qui nous est encore dû » devient une liste filtrée, au lieu d’une estimation.

Étape 3, Le module de paiement : accepter la commande, ne rien encaisser

Un module de paiement à échéance fait quatre choses, et seulement quatre :

• Il affiche l’option pour le groupe approuvé (via hookPaymentOptions qui renvoie une PaymentOption, l’équivalent moderne de l’ancien hookPayment).
• Il valide la commande sans encaissement en appelant validateOrder() et en transmettant l’ID de votre état personnalisé « Paiement à échéance » au lieu de PS_OS_PAYMENT. C’est la seule ligne qui distingue une commande à échéance d’une commande payée.
• Il inscrit les conditions sur la commande, le délai net (30/60/90), la date d’échéance et une référence de paiement, afin qu’elles apparaissent sur la facture générée.
• Il bloque éventuellement selon la limite de crédit avant la validation (étape 4).

L’unique appel qui distingue une commande à échéance d’une commande payée est l’état de commande que vous passez à validateOrder(). Le virement bancaire transmet Configuration::get('PS_OS_BANKWIRE') ; une commande payée par carte transmet PS_OS_PAYMENT ; votre commande à échéance transmet l’ID de l’état personnalisé créé à l’étape 2, rien d’autre ne change :

// Inside your module's validation controller, after building the cart total.
// $customerCredit and $this->id are the module's own values.
$termsStateId = (int) Configuration::get('MYTERMS_OS_ON_TERMS'); // your custom "On payment terms" state

$this->module->validateOrder(
    (int) $cart->id,
    $termsStateId,                       // NOT PS_OS_PAYMENT – order is real but unpaid
    $cart->getOrderTotal(true, Cart::BOTH),
    $this->module->displayName,           // payment method name shown on the order
    null,                                // optional message
    array(),                             // extra vars (terms text, due date, reference)
    (int) $cart->id_currency,
    false,
    $customer->secure_key
);

La partie propre de cette approche : comme vous empruntez le chemin standard validateOrder(), la commande, la facture, l’e-mail client et l’historique de commande sont tous générés par le cœur exactement comme pour n’importe quel autre paiement, pas de tunnel de commande dupliqué, rien à reprendre au prochain changement de version de PrestaShop. Vous ne tordez pas la plateforme ; vous utilisez l’emplacement qu’elle prévoit déjà pour les cas où « le paiement se fait hors bande », ce qui est précisément le principe du virement bancaire.

Étape 4, Faire respecter la limite de crédit avant la validation de la commande

C’est l’élément que les marchands oublient le plus souvent, et qu’ils regrettent le plus. Chaque client à échéance doit avoir une limite de crédit, le montant maximal total de factures impayées que vous acceptez. Sans contrôle, un client avec une limite de 2 000 EUR et déjà 1 800 EUR d’encours peut tranquillement passer une nouvelle commande de 900 EUR, et vous ne le découvrez qu’au moment du retard de paiement.

PrestaShop n’a pas de champ natif pour la limite de crédit, vous devez donc l’implémenter dans l’étape de prévalidation du module :

• Stockez la limite par client, un simple champ personnalisé (une colonne dans la table customer, ou une petite table de module indexée par id_customer) lu dans le hook de paiement.
• Avant validateOrder(), additionnez l’encours du client : le total des commandes dans votre état « Paiement à échéance » (ou dans tout état où paid = 0) qui n’ont pas encore été réglées. Un simple SUM(total_paid_tax_incl) sur les lignes pertinentes de orders pour cet id_customer suffit.
• Si encours + total du panier courant dépasse la limite, n’affichez pas l’option comme disponible, ou affichez-la désactivée avec un message : « Cette commande dépasse votre crédit disponible. Veuillez régler les factures en attente ou payer par carte. » Le paiement par carte destiné aux particuliers doit rester proposé en solution de repli afin de ne pas perdre la vente.

La requête sur l’encours est le cœur du contrôle. Elle additionne le total TTC des commandes du client qui se trouvent encore dans un état impayé, afin que vous puissiez le comparer à sa limite avant validation :

SELECT COALESCE(SUM(o.total_paid_tax_incl), 0) AS open_balance
FROM ps_orders o
JOIN ps_order_state os ON os.id_order_state = o.current_state
WHERE o.id_customer = 42       -- the buyer
  AND os.paid = 0              -- unpaid states only: your "On terms" + bank-wire-awaiting
  AND o.valid = 1;             -- ignore carts that never became real orders

Lisez ce montant dans le hook de paiement, ajoutez le total du panier courant, puis comparez-le à la limite enregistrée. Et alors ? La limite cesse d’être un nombre dans une feuille de calcul que vous vérifiez après coup : elle devient une règle que le paiement applique en temps réel. Les créances douteuses sont bloquées à l’entrée, pas poursuivies après coup.

Étape 5. La facture doit assurer le recouvrement pour vous

Avec des conditions de paiement, la facture PrestaShop n’est pas un reçu. C’est l’instrument qui vous fait payer. Elle doit donc contenir tout ce dont le service comptabilité fournisseurs de l’acheteur a besoin pour régler sans vous renvoyer un e-mail. La facture PDF de PrestaShop est générée par l’objet OrderInvoice et rendue via le template HTMLTemplateInvoice ; les champs dont vous devez vérifier la présence sont les suivants :

• Un numéro de facture unique (le cœur le gère dès que la commande atteint un état donnant droit à facture).
• Les conditions de paiement et la date d’échéance explicite, « 30 jours nets, échéance le 14 juillet 2026 », pas seulement « 30 jours nets ».
• Vos coordonnées bancaires pour le virement.
• Une référence de paiement que l’acheteur doit indiquer, afin qu’un virement entrant soit rapproché de la bonne facture au lieu de devenir un dépôt mystérieux.
• Toute remise pour paiement anticipé (par ex. 2/10 Net 30) indiquée en toutes lettres.

La méthode gratuite pour ajouter un texte bancaire et des conditions est le pied de page natif Paramètres de la boutique → Paramètres des commandes → Factures ; la méthode structurée, dates d’échéance par client, références par commande, résumé de l’encours, relances groupées pour les factures en retard, correspond au rôle d’un module de gestion des factures dédié. Si vous envoyez quelques factures par mois, le pied de page suffit ; dès que les créances deviennent un vrai grand livre, vous voudrez que l’état de commande, la date d’échéance et la référence soient générés et suivis automatiquement plutôt que saisis à la main.

30 jours nets, 60 jours nets ou remise pour paiement anticipé, que proposer concrètement

Ne proposez pas une condition unique à tout le monde. Reliez le délai à la relation commerciale et segmentez-le via le groupe client, afin que le filtre du mode de paiement de l’étape 1 encode aussi la générosité des conditions :

Comme chaque niveau est un groupe, vous pouvez avoir trois instances du mode de paiement (30 jours nets, 60 jours nets, prépaiement) et laisser la restriction par groupe décider de ce que voit chaque acheteur. Un client à sa deuxième commande ne voit jamais 60 jours nets ; un compte établi n’a jamais besoin de le demander.

La réalité de trésorerie que vous acceptez

Une mise en garde honnête, car la plateforme ne peut pas la résoudre : les délais de paiement signifient que vous avez payé le stock et l’expédition alors que l’argent n’arrivera que dans 30 à 60 jours. Avec 20 000 EUR/mois de chiffre d’affaires B2B à 30 jours nets, environ un mois de chiffre d’affaires est en permanence en transit ; à 60 jours nets, deux mois. Ce besoin en fonds de roulement est une décision d’entreprise, pas un réglage PrestaShop, financez-le avec vos fonds propres, une ligne de crédit ou de l’affacturage. Ce que PrestaShop peut faire, et ce que les étapes ci-dessus apportent, c’est vous garantir de connaître à tout moment le montant exact de cet écart : une liste filtrée des commandes impayées à échéance, leur ancienneté sous les yeux, et des limites appliquées avant l’ajout de la commande suivante.

Questions fréquentes

Puis-je gérer des conditions de paiement différé avec le seul module natif de virement bancaire de PrestaShop ?

En partie. Le module natif ps_wirepayment vous fournit déjà gratuitement la partie la plus difficile : un mode de paiement qui valide une commande sans encaisser d’argent et la place dans un état impayé. Restreignez-le à votre groupe approuvé et vous obtenez un flux « paiement sur facture » fonctionnel. Ce qu’il ne vous donne pas, c’est une limite de crédit, un état de commande « à échéance » distinct du virement bancaire, le calcul de la date d’échéance ou les relances de retard. Ce sont les lacunes qu’un module dédié B2B Deferred Payment Terms comble. Pour quelques comptes de confiance, un virement bancaire filtré par groupe avec un tableur manuel est un point de départ légitime.

Comment empêcher un client de passer une commande qui dépasse sa limite de crédit ?

Il n’existe pas de champ natif pour la limite de crédit, le contrôle doit donc s’exécuter dans le hook de paiement avant l’appel à validateOrder(). Additionnez l’encours du client (le SQL de l’étape 4), ajoutez le total du panier courant, puis comparez le résultat à une limite par client que vous stockez vous-même. Si le total dépasse la limite, n’affichez pas l’option à échéance, basculez vers la carte pour ne pas perdre la vente. La décision doit être prise avant la validation de la commande ; contrôler après coup relève du reporting, pas de l’application de la règle.

Une commande « à échéance » va-t-elle fausser mes chiffres de ventes et de chiffre d’affaires ?

Seulement si vous la laissez dans un état « payé ». La correction consiste à utiliser le drapeau paid = 0 sur votre état de commande personnalisé (étape 2) : PrestaShop exclut alors la commande des totaux de chiffre d’affaires accepté et vous permet de la filtrer comme en attente de règlement. Lorsque le virement arrive, passez la commande à Paiement accepté et les chiffres se rapprochent. Réutiliser l’état du virement bancaire fonctionne techniquement, mais mélange les vrais virements avec les factures à 60 jours ; vous perdez donc la vue « ce qui vieillit ».

PrestaShop suit-il les factures en retard ?

Pas nativement. Le cœur sait qu’une commande est impayée (via l’état de commande), mais il n’a ni grand livre des créances, ni champ de date d’échéance, ni notion de « retard ». Vous pouvez l’approcher avec une liste de commandes filtrée et une date d’échéance dans le pied de page de facture, mais dès que vous envoyez plus de quelques factures par mois, le suivi manuel atteint ses limites. Cette vue d’ancienneté et les relances groupées sont précisément ce qu’ajoute un module dédié aux créances / à la gestion des factures.

Est-ce la même chose qu’une vente B2B exonérée de TVA ?

Non. Ce sont deux sujets indépendants. Les conditions de paiement différé concernent le moment où l’argent arrive ; l’exonération de TVA concerne le montant de taxe facturé. Une commande à échéance peut inclure toute la TVA, et c’est aussi le cas d’une vente B2B nationale à 30 jours nets. Si vos clients à échéance sont des entreprises transfrontalières de l’UE, vous aurez probablement besoin des deux : les conditions pour l’aspect trésorerie, et Automatic EU VAT Checker pour l’exonération par autoliquidation. Ils se configurent séparément et ne dépendent pas l’un de l’autre.

La place de ce sujet dans l’ensemble B2B

Le paiement différé est une capacité d’une vraie configuration B2B, pas l’ensemble du dispositif. Si vous construisez une vente aux professionnels à partir de zéro, commencez par la vue d’ensemble, vendre en B2B sur PrestaShop, puis ajoutez les briques : afficher les prix HT aux acheteurs professionnels, automatiser l’exonération de TVA intracommunautaire, et la vérification qui décide qui mérite ou non des délais, vérifier les clients professionnels avant de leur donner accès. Les deux modules qui font le gros du travail sur cette page sont B2B Deferred Payment Terms (le mode réservé, la limite de crédit, la vue d’ancienneté) et Automatic EU VAT Checker (pour que les mêmes acheteurs approuvés bénéficient aussi de leur exonération transfrontalière). Configurez correctement le filtre, l’état de commande et le contrôle de limite de crédit, et le « paiement sur facture » cesse d’être un tableur de risques pour devenir simplement une autre manière pour vos acheteurs approuvés de valider leur commande, celle que leur service achats attend déjà.