PrestaShop est construit autour d’un acte unique : un panier, une commande, un paiement. L’abonnement suppose l’inverse, un engagement qui produit des paiements dans le temps sans que le client revienne. Ces deux modèles ne se rejoignent pas naturellement.
Voici l’architecture qui fonctionne, et les points où les implémentations cassent.
Qui détient la vérité
Première décision, et elle conditionne tout le reste.
Une plateforme de paiement comme Stripe dispose d’un moteur de facturation récurrente complet : abonnements, échéances, relances, gestion des cartes expirées. Reconstruire cela dans PrestaShop serait une erreur.
La répartition qui tient : Stripe détient l’abonnement, c’est-à-dire le cycle, les échéances et l’encaissement. PrestaShop détient le catalogue, le client et les commandes générées à chaque échéance.
Concrètement, chaque prélèvement réussi crée une commande dans PrestaShop, qui suit ensuite votre processus normal de préparation et d’expédition. C’est ce qui permet de garder vos statistiques, vos factures et votre logistique cohérentes.
Les webhooks à écouter
C’est le cœur de l’intégration, et le point où le travail est réellement.
Cinq événements doivent être traités, chacun avec un comportement précis.
- Le paiement d’échéance réussi. Crée la commande dans PrestaShop, décrémente le stock, déclenche l’email de confirmation.
- Le paiement échoué. Ne crée pas de commande, place l’abonnement en attente, déclenche la séquence de relance.
- L’abonnement mis à jour. Changement de formule, de quantité, de date. Doit se répercuter côté boutique.
- L’abonnement annulé. Coupe l’accès si vous vendez du contenu, arrête les envois si vous vendez du physique.
- Le moyen de paiement expirant. Déclenche une relance avant échec, ce qui évite l’interruption.
Trois règles techniques sur les webhooks. Vérifiez la signature de chaque notification, sinon n’importe qui peut créer des commandes chez vous. Traitez-les de façon idempotente : le même événement peut être livré plusieurs fois, et vous ne devez pas créer deux commandes. Et répondez rapidement en accusant réception, puis traitez en tâche de fond, faute de quoi la plateforme considère l’appel en échec et le rejoue.
DataFirefly Subscriptions — Abonnements et paiement récurrent Stripe pour PrestaShop 8 & 9Le module abonnement pour PrestaShop 8 et 9 : Stripe card-on-file, dunning, espace client self-service.€169.00
Les cartes expirées, premier poste de perte
Sur un abonnement, la majorité des résiliations subies vient d’un moyen de paiement devenu invalide, pas d’une décision du client.
Trois mécanismes se cumulent pour limiter la casse. La mise à jour automatique des cartes, proposée par les réseaux et relayée par les plateformes de paiement, qui récupère le nouveau numéro sans intervention. La relance avant expiration, déclenchée un mois avant la date de fin de validité. Et la séquence de nouvelle tentative après un échec, étalée sur une à deux semaines plutôt que répétée le lendemain.
Prévoyez une période de grâce pendant laquelle le service reste actif malgré l’échec. Couper immédiatement transforme un incident bancaire en résiliation définitive.
Le tunnel : ne pas mélanger
Question de conception souvent tranchée trop tard. Un panier contenant un abonnement et des produits en achat unique pose un problème : le premier crée un engagement récurrent, le second non.
Deux approches acceptables. Le tunnel dédié, où l’abonnement se souscrit seul, sans possibilité d’y ajouter autre chose. Plus simple, plus clair pour le client, et c’est le choix par défaut recommandé.
Ou le panier mixte, où la commande initiale contient les deux, avec un paiement unique qui couvre les produits et déclenche l’abonnement. Techniquement plus lourd, et il faut être très clair sur ce qui sera prélevé ensuite.
Ce qu’il ne faut pas faire : laisser deux abonnements différents dans le même panier. Les cycles de facturation divergent immédiatement et la gestion devient inextricable.
L’authentification forte
La réglementation européenne sur les paiements impose une authentification du porteur pour de nombreuses transactions. Sur un abonnement, le premier paiement est authentifié par le client, les suivants relèvent d’un cadre différent puisqu’ils sont initiés par le marchand.
Deux conséquences pratiques. Le mandat doit être correctement enregistré lors du premier paiement, ce que les plateformes gèrent à condition que l’intention de paiement soit créée avec les bons paramètres. Et certaines échéances peuvent malgré tout exiger une authentification, ce qui suppose un parcours prévu pour ramener le client vers une page d’authentification, plutôt qu’un échec silencieux.
Le cadre légal
Trois obligations, contrôlées et régulièrement manquées.
L’information avant souscription : durée, montant, périodicité et modalités de résiliation doivent être visibles sur la page d’achat, pas seulement dans les conditions générales.
La résiliation en ligne, aussi simple que la souscription, accessible depuis l’espace client sans avoir à écrire ni téléphoner.
L’information avant reconduction pour les abonnements à tacite reconduction, dans un délai qui laisse au client le temps de refuser.
Les trois chiffres du modèle
Le revenu récurrent mensuel, qui donne la base économique. Le taux d’attrition mensuel, en distinguant les résiliations volontaires des échecs de paiement, parce que les remèdes diffèrent. Et la durée de vie moyenne d’un abonné, qui découle du second et qui détermine combien vous pouvez dépenser pour en acquérir un.
Le module Subscriptions pour PrestaShop met en place cette architecture sur PrestaShop 8 et 9 : abonnements adossés à Stripe, création automatique des commandes à chaque échéance, traitement des webhooks avec vérification de signature, gestion des échecs de paiement et espace client pour modifier ou résilier.