Une gestion d’abonnement doit séparer le plan choisi, la période facturée, l’état du paiement et les droits réellement ouverts.
Un client peut changer de formule, suspendre son compte ou régler une facture en retard. L’application ne doit pas déduire l’accès d’un simple bouton de paiement. Elle doit suivre les événements reçus du fournisseur et appliquer une règle métier documentée.
Définir les états
Distinguez actif, période d’essai, suspendu, résilié et en attente de paiement. Chaque état indique les fonctions accessibles et la prochaine action. Une facture échouée ne signifie pas forcément que l’accès doit disparaître immédiatement.
Gérer les changements
Un changement de formule peut prendre effet immédiatement ou à la prochaine période. Le logiciel doit afficher la date et le prorata éventuel. Les montants et devises doivent suivre les règles de calcul monétaire.
Un événement de paiement peut être reçu plusieurs fois ou dans le désordre. Conservez son identifiant et vérifiez la version de l’abonnement avant de modifier les droits. Les tests de contrat API doivent couvrir les erreurs.
Séparer paiement et autorisation
Le fournisseur confirme un état de paiement ; votre application décide l’accès selon le contrat. Un utilisateur de support ne doit pas pouvoir prolonger un abonnement en modifiant un paramètre côté navigateur. Journalisez les changements administratifs.
Tester la fin de vie
Testez l’essai expiré, la carte refusée, l’annulation, le remboursement et la restauration d’un paiement. Vérifiez les notifications, les exports et les données conservées après résiliation.
Sources : Stripe, abonnements, OWASP, contrôle d’accès.
Décrire le plan
Un plan doit indiquer les fonctions, les limites, la période, la devise et les conditions de changement. Les limites peuvent concerner le nombre d’utilisateurs, les fichiers, les espaces ou les opérations. Le logiciel doit afficher l’usage courant et la prochaine limite avant un blocage.
Les fonctions accessibles doivent être calculées côté serveur. Un bouton masqué améliore l’interface, mais une route doit encore vérifier le plan et le rôle. Une entreprise peut avoir plusieurs utilisateurs et des droits différents au sein du même abonnement.
Traiter les périodes
Un changement immédiat peut créer un prorata ou une nouvelle facture. Un changement à la prochaine échéance doit conserver la demande et sa date. Affichez la décision avant confirmation et gardez l’historique des changements.
Un paiement en attente ne doit pas produire deux relances si le fournisseur renvoie le même événement. Utilisez une clé d’événement, une version et une règle de reprise. Les webhooks doivent accepter les doublons et les retards.
Gérer la fin de contrat
Une résiliation peut laisser l’accès actif jusqu’à la fin de la période ou prendre effet immédiatement. Les données doivent rester disponibles selon la règle de conservation et être exportables dans un délai connu. Les pièces et les utilisateurs doivent suivre le même état.
Un remboursement ou un litige peut modifier l’état de paiement après la résiliation. Ne réactivez pas automatiquement un accès sans vérifier les droits et le contrat. Le support doit pouvoir expliquer le résultat avec un identifiant d’opération.
Mesurer et tester
Testez l’essai, l’upgrade, le downgrade, l’échec, le remboursement, la résiliation et une réponse externe en retard. Comparez le plan affiché, les droits, la facture, l’e-mail et l’export. Un tableau de bord doit séparer les abonnements actifs, suspendus et arrivés à échéance.