Ce qu'il faut retenir
En e-commerce, les impayés ne ressemblent pas à ceux du B2B classique : ce sont des transactions refusées en temps réel, des cartes expirées, des abonnements qui ne se renouvellent pas. Ces pertes passent souvent sous le radar parce qu'aucune facture ne traîne dans un tiroir pour les rappeler. Trois cas reviennent régulièrement : le dunning sur les abonnements, les factures B2B à paiement différé, et les litiges en attente. Pour chacun, les plateformes (Shopify, WooCommerce, Stripe) proposent des modules natifs. Le vrai sujet n'est pas l'outil, c'est la connexion propre entre la boutique, la solution de paiement, le CRM et l'ERP, le terrain sur lequel IT Systèmes accompagne les PME et ETI.
En B2B classique, un impayé est visible : une facture émise, une échéance dépassée, une relance à envoyer. En e-commerce, c'est plus sournois. Le paiement échoue au moment de la transaction, le client ne le voit pas toujours, et l'entreprise non plus si rien ne remonte l'information. Une carte expire, un plafond saute, un renouvellement d'abonnement ne passe pas. Personne n'a rien oublié, et pourtant l'argent n'arrive pas.
Ces pertes passent souvent sous le radar parce qu'aucune facture ne traîne dans un tiroir pour les rappeler. C'est l'un des angles morts classiques d'un SI qui s'est construit par couches successives, un sujet que nous abordons plus largement dans notre article sur la digitalisation des entreprises.
Ce guide couvre les trois situations les plus fréquentes et la façon de les traiter automatiquement, que la boutique tourne sur Shopify, WooCommerce, Stripe ou en facturation B2B différée.
Trois types d'impayés propres au e-commerce
Le dunning : les paiements échoués sur abonnement
Le dunning, c'est la gestion automatisée des paiements refusés sur un modèle récurrent. Carte expirée, plafond dépassé, refus bancaire : à chaque échec, un client peut partir sans même l'avoir décidé, simplement parce que personne ne lui a signalé que son moyen de paiement ne fonctionnait plus.
La règle tient en une phrase : relancer vite, avec un lien direct pour mettre à jour la carte. Pas de justification, pas de paragraphe d'explication. Un lien, une action.
Les factures B2B à paiement différé
Certaines boutiques vendent à des entreprises avec un délai de paiement à 30 ou 60 jours. La plateforme e-commerce génère bien la facture, mais elle ne sait pas gérer une relance progressive dans le temps. Il faut connecter la boutique à un logiciel comptable (Pennylane, Sage, Sellsy) ou à un outil d'automatisation (Make, Power Automate) via API. Ces factures suivent ensuite le même rythme qu'une relance B2B classique : rappel amiable, relance ferme, mise en demeure.
Les litiges et remboursements en attente
Un client conteste une transaction, ou attend un avoir qui n'a pas encore été émis. Lui envoyer une relance de paiement dans ce contexte, c'est le meilleur moyen de transformer une réclamation en chargeback. Le système doit reconnaître ces statuts et sortir les transactions concernées du circuit de relance. Cela suppose une synchronisation fiable avec la plateforme de paiement et c'est précisément là que les choses se compliquent quand l'intégration est bâclée.
La mise en place selon votre plateforme
Sur Shopify. Les paiements échoués sur abonnement sont gérés nativement via Shopify Payments et Shopify Subscriptions. Pour aller plus loin (SMS, segmentation par valeur client, lien vers le CRM), Klaviyo ou ActiveCampaign se branchent directement sur les événements de paiement Shopify.
Sur WooCommerce. WooCommerce Subscriptions gère les paiements récurrents et les nouvelles tentatives automatiques en cas d'échec. AutomateWoo permet ensuite de créer des règles conditionnelles depuis WordPress : arrêter les relances dès le paiement reçu, adapter le message au nombre de tentatives, écarter les clients en litige. Pour les cas courants, aucun développement n'est nécessaire.
Pour un modèle par abonnement. Stripe Billing et Chargebee intègrent le dunning de base : retentatives selon un calendrier configurable, e-mail à chaque tentative, suspension conditionnelle du service. Pour des abonnements simples, Stripe Billing suffit. Pour des scénarios plus lourds (multidevise, relances B2B, lien CRM poussé), Chargebee ou Recurly donnent plus de marge.
Pour une boutique B2B avec facturation différée. La plateforme génère la facture mais n'orchestre pas les relances échelonnées. La solution consiste à connecter la boutique à l'outil comptable ou à Make / Power Automate. Le flux récupère les factures ouvertes, surveille les échéances et déclenche les relances selon vos scénarios.
Voici une séquence type sur paiement échoué, à adapter selon votre activité :
Ce qui change vraiment les résultats
La rapidité de la première relance pèse plus que tout le reste. Tant que l'achat est frais dans l'esprit du client, une mise à jour de carte se fait en quelques secondes. Quelques jours plus tard, l'intention est retombée.
Le lien d'action doit être direct. Un bouton qui renvoie vers la page de mise à jour du moyen de paiement, pas vers l'accueil ni vers l'espace client global. Chaque clic en trop fait perdre des clients.
L'arrêt automatique n'est pas un détail. Dès que le paiement est enregistré, la séquence doit s'interrompre. Une relance envoyée après règlement crée plus de problèmes qu'elle n'en résout et abîme la relation client.
Le plafond de tentatives compte aussi. Passé quelques relances, l'effort ne rapporte plus grand-chose et finit par agacer. Savoir s'arrêter fait partie du dispositif.
Enfin, une personnalisation minimale suffit : prénom, produit concerné, montant exact. Inutile d'en dire plus que nécessaire.
L'intégration : le vrai sujet technique
Choisir l'outil est rarement le point dur. Ce qui coince, c'est la connexion entre la plateforme e-commerce, la solution de paiement, le CRM et l'ERP. Un flux mal câblé produit exactement ce qu'on voulait éviter : des relances envoyées après paiement, des doublons, ou des angles morts sur certains segments de clients.
Pour une PME ou une ETI, ce travail d'intégration touche souvent à un système d'information déjà en place, avec ses contraintes et son historique. C'est là qu'IT Systèmes intervient : audit des flux existants, mise en place des connexions entre boutique, paiement et outils internes, notamment sur les environnements Shopify, WooCommerce, Stripe et Microsoft 365. Ce type de chantier relève de notre expertise en développement et automatisation, où l'enjeu est moins d'écrire du code que de faire dialoguer proprement des outils qui ne se parlent pas nativement.
Questions fréquentes
Stripe Billing suffit-il pour gérer les relances d'une boutique par abonnement ? Pour des abonnements simples, oui. Stripe Billing propose un dunning configurable avec retentatives automatiques et e-mails de relance. Pour des scénarios plus complexes (multidevise, relances B2B, lien CRM avancé), Chargebee ou Recurly apportent plus de souplesse.
Peut-on automatiser les relances sur WooCommerce sans développement ? Oui, avec WooCommerce Subscriptions et AutomateWoo. Ces extensions permettent de configurer des séquences de relance depuis WordPress, sans écrire de code, pour la plupart des cas courants.
Comment éviter d'envoyer une relance à un client qui a déjà payé ? En synchronisant le statut de paiement en temps réel avec l'outil de relance. Sur Stripe ou Shopify, les webhooks de paiement permettent de stopper une séquence en quelques secondes. Sur des systèmes moins réactifs, comme un ERP avec rapprochement quotidien, un délai de grâce dans les déclencheurs réduit le risque.
Faut-il un outil différent pour le B2B et pour les abonnements ? Pas forcément, mais les logiques diffèrent. Les abonnements relèvent du dunning (retentative de carte), le B2B différé relève de la relance de facture (rappel échelonné). Beaucoup d'entreprises font cohabiter les deux : un module de dunning côté paiement, et un flux relié au logiciel comptable côté facturation.



