Abonnements Avancés pour WooCommerce 2.0.x

Le développement de cette version a coûté 4 360 euros. Le coût de la première version était de 38 000 euros. Le coût cumulé depuis la première version est de 42 360 euros, mais le coût pour vous est seulement la licence à partir de 80€.

Nouvelle branche 2.0.x du plugin Abonnements Avancés pour WooCommerce. C'est une version majeure : le plugin ne dépend plus de l'extension WooCommerce Subscriptions et introduit des paiements récurrents automatiques natifs avec Stripe, PayPal Payments et WooPayments, ainsi que Redsys, qui continue de voyager à l'intérieur du plugin lui-même.

Versions de la branche

• 2.0.0

2.0.0

Important :

• C'est une version majeure. Lisez les notes de mise à jour avant de mettre à jour, surtout si vous facturez actuellement via PayPal Standard.
• Cette version nécessite WordPress 6.5 ou supérieur et WooCommerce 8.0 ou supérieur. L'exigence précédente (WordPress 5.1, WooCommerce 5.1) n'avait jamais été vraiment testée, et en la testant pour cette version, il a été constaté que le plugin ne pouvait pas fonctionner là. Les nouveaux chiffres sont ceux sur lesquels cette version a été vérifiée.
• PayPal Standard n'est plus supporté. WooCommerce le déconseille depuis sa version 5.5 et le bloque dans les nouvelles installations. Si vous facturez actuellement les abonnements avec PayPal Standard, installez WooCommerce PayPal Payments et migrez les méthodes de paiement de vos clients avant de mettre à jour vers la 2.0.0.

Nouveau :

• Paiements récurrents automatiques avec Stripe. Les renouvellements sont maintenant facturés hors session sur la carte enregistrée du client en utilisant le plugin WooCommerce Stripe Payment Gateway (version 9.8.0 ou supérieure requise). Aucune extension de paiement Abonnements n'est nécessaire.
• Paiements récurrents automatiques avec PayPal Payments. Les renouvellements sont facturés via le token du coffre-fort (coffre-fort) de PayPal en utilisant le plugin WooCommerce PayPal Payments (version 3.0 ou supérieure requise). Aucune extension de paiement Abonnements n'est nécessaire.
• Paiements récurrents automatiques avec WooPayments. Les renouvellements sont facturés hors session sur la méthode de paiement enregistrée du client en utilisant le plugin WooPayments (version 7.0 ou supérieure requise). Aucune extension de paiement Abonnements n'est nécessaire.
• Sauvegarde fiable de la méthode de paiement lors du passage à la caisse. Lorsque un client achète un abonnement avec Stripe, PayPal Payments ou WooPayments, le plugin s'assure que la méthode de paiement est sauvegardée pour les renouvellements, même si ces passerelles ne le font normalement que lorsque WooCommerce Subscriptions est actif.
• Gestion de 3D Secure (SCA) lors des renouvellements. Lorsque la banque demande une authentification supplémentaire pour un paiement récurrent, le renouvellement est marqué comme échoué avec un motif clair et le client peut être averti pour autoriser la prochaine tentative.
• Nouvelle tentative automatique des renouvellements échoués. Lorsque un paiement échoue (carte rejetée, solde insuffisant, authentification requise, etc.), le planificateur de nouvelles tentatives reprogramme automatiquement la prochaine tentative.
• Détection des accords PayPal annulés. Si un client annule son autorisation PayPal en dehors de votre boutique, le prochain renouvellement le détecte, l'abonnement passe à « en attente » et la méthode de paiement enregistrée est marquée comme invalide pour que le client puisse la réautoriser.
• Vérification de sécurité de la devise lors des renouvellements. Le plugin refuse de facturer un renouvellement dans une devise différente de celle du paiement original, ce qui évite les doubles facturations accidentelles dans la mauvaise devise après un changement de devise de la boutique.
• Changement de méthode de paiement entre passerelles. Les clients peuvent changer entre Stripe, PayPal Payments et WooPayments depuis Mon compte, et le prochain renouvellement utilise automatiquement la nouvelle méthode.
• Nouvelle option d'administration « Annuler l'abonnement lors du remboursement total d'une commande de renouvellement », dans WooCommerce > Réglages > Abonnements Avancés > Réglages Avancés. Désactivé par défaut. Lorsqu'il est désactivé, un remboursement total ne laisse qu'une note sur l'abonnement ; lorsqu'il est activé, l'abonnement est annulé. Les remboursements partiels n'annulent jamais.
• Les remboursements de la commande du premier paiement (la commande parente) annulent toujours l'abonnement. C'est ce qui est naturellement attendu lors du remboursement de l'achat original, et cela est indépendant de la nouvelle option d'administration.
• Notes automatiques sur l'abonnement chaque fois qu'un renouvellement est remboursé (totalement ou partiellement), afin que la chronologie de l'abonnement soit claire.
• Panneau de compatibilité des passerelles de paiement sur l'écran de réglages du plugin (WooCommerce > Réglages > Abonnements Avancés > Réglages Généraux). Montre d'un coup d'œil si les plugins de passerelle supportés sont installés et actifs, et offre des liens d'installation ou d'activation en un clic lorsqu'ils ne le sont pas.
• Détection des litiges et rétrofacturations sur Stripe et PayPal. Lorsque un client ouvre un litige, la commande associée passe à « en attente » pour que vous puissiez réagir avant le prochain renouvellement.
• Détection de la suppression de la méthode de paiement sur Stripe. Si le token de la carte enregistrée est supprimé, tous les abonnements qui l'utilisent sont marqués et passent à « en attente » pour que le client puisse enregistrer une nouvelle méthode.
• Redsys apparaît dans le panneau de compatibilité des passerelles comme passerelle incluse : il voyage à l'intérieur de ce plugin et n'a jamais besoin d'une installation séparée.

Corrigé :

• Désactiver WooCommerce ne fait plus tomber tout le site. Jusqu'à présent, si WooCommerce cessait d'être actif pour une raison quelconque (vous l'éteigniez pour vérifier quelque chose, une mise à jour échouait ou une erreur se produisait), ce plugin continuait d'essayer de l'utiliser et faisait tomber toutes les pages du site, y compris l'administration de WordPress, sans autre recours que le FTP. Maintenant, le plugin détecte que WooCommerce n'est pas là, ne fait rien silencieusement et affiche un avis explicatif dans l'administration. En réactivant WooCommerce, tout se rétablit sans aucune action supplémentaire.
• Les renouvellements pouvaient être programmés au mauvais moment, ou ne pas être programmés, dans les boutiques dont le fuseau horaire était configuré comme décalage UTC au lieu de comme ville. La correction affecte la façon dont le fuseau horaire du site est lu lors du calcul de la date d'échéance d'un paiement programmé.
• Une commande annulée ne laisse plus derrière elle un abonnement fantôme. Si un paiement échouait et que la nouvelle tentative du client générait une NOUVELLE commande au lieu de reprendre la première (ce qui se produit lorsque la session est perdue ou que le panier change), l'abonnement non payé de la commande abandonnée restait pour toujours dans le compte du client. Il n'était jamais facturé et ne pouvait pas être activé, mais le client voyait un abonnement qu'il n'avait jamais payé. Annuler cette commande l'élimine maintenant. Les abonnements déjà actifs ne sont jamais touchés : annuler une commande de renouvellement laisse l'abonnement en cours, comme cela doit être.
• Supprimer le plugin nettoie maintenant ce qui lui appartient. Jusqu'à présent, supprimer le plugin laissait tout derrière : ses réglages, ses blocages de paiement et — celui qui avait des conséquences visibles — ses tâches programmées, que WordPress continuait d'essayer d'exécuter même s'il ne restait rien installé pour les gérer, échouant et les réessayant indéfiniment. En désinstallant maintenant, les réglages propres au plugin sont supprimés et ses tâches programmées sont annulées. Délibérément, vos abonnements, vos commandes ou vos données clients ne sont pas supprimés : ce sont des enregistrements commerciaux, ils restent dans la base de données, et en réinstallant le plugin, ils reviennent exactement comme ils étaient.
• Supprimer le plugin sur un site qui n'a jamais eu WooCommerce ne remplit plus le journal des erreurs. Le nettoyage cherchait des tâches programmées dans une table que WooCommerce n'avait jamais créée, ce qui produisait une erreur de base de données pour chaque groupe de tâches du plugin. Ce n'était jamais fatal (le nettoyage se terminait de toute façon et les messages n'apparaissaient que lorsque le débogage était activé), mais dans un réseau multisite, cela se répétait sur chaque site. Le nettoyage fonctionne toujours exactement de la même manière ; seuls les messages inutiles sont silencieux, et uniquement sur un site où cette table manque réellement.
• Produits variables avec un mélange de variations d'abonnement et de non-abonnement : acheter une variation qui N'EST PAS un abonnement ne sauvegarde plus la carte du client ni ne crée un abonnement. Le plugin décidait si une variation était un abonnement en regardant le réglage du produit parent et ignorait complètement la case « Abonnement » de la variation elle-même, donc dans un produit variable où seules certaines variations sont des abonnements, toutes se comportaient comme telles. Une variation sans réglage propre continue d'hériter de celui du parent, de sorte qu'un produit que vous venez de marquer comme abonnement continue de fonctionner jusqu'à ce que vous configuriez ses variations.
• Un abonnement configuré pour se renouveler manuellement n'est plus facturé automatiquement. Entre le renouvellement programmé et la passerelle de paiement, il n'y avait rien pour vérifier si le client avait demandé un paiement manuel, et à la commande de renouvellement —qui pour les renouvellements manuels est créée délibérément sans méthode de paiement— une méthode était remplie à partir de la commande originale juste avant la facturation. Les renouvellements manuels s'arrêtent maintenant à ces deux points, et toute tentative automatique en attente à leur sujet est annulée.
• Définir la date de début d'un abonnement depuis l'écran d'administration ne provoque plus d'erreur fatale. L'écran appelait une méthode d'écriture de dates qui n'existait pas dans l'objet d'abonnement, donc dans toute boutique sans l'extension WooCommerce Subscriptions, l'enregistrement échouait avec «Appel à une méthode indéfinie». Le flux de commandes avec date de début échouait également à cause d'une seconde méthode inexistante. Les deux sont maintenant implémentés sur le stockage de dates propre au plugin ; un abonnement auquel aucune date de début n'a jamais été écrite continue d'informer de la date de création de sa commande, exactement comme avant.
• Produits variables : les paramètres d'abonnement par variation n'apparaissaient jamais en cochant une variation comme abonnement. L'écran d'édition de produit demandait le script de chargement non minifié indépendamment du paramètre SCRIPT_DEBUG, donc dans les installations qui n'incluent que la ressource minifiée, cela renvoyait un 404 et le panneau de champs —qui reste caché jusqu'à ce que ce script soit exécuté— n'apparaissait pas.
• Les e-mails de notification d'abonnement déclenchés directement via l'API Scheduler du plugin sont maintenant envoyés. L'API acceptait un type de notification et le transmettait, mais la fonction qui se trouvait derrière ne déclarait pas ce paramètre, donc PHP l'ignorait et le type arrivait vide : aucun e-mail n'était envoyé et l'événement de notification n'indiquait aucun type. Les notifications lancées par le planificateur dans leurs propres hooks n'étaient pas affectées.
• Une date de premier paiement fixée depuis l'écran d'administration de l'abonnement est maintenant facturée. L'action programmée était créée avec le nom de hook de WooCommerce Subscriptions, que ce plugin n'écoute pas, donc le paiement n'était tout simplement jamais exécuté dans les boutiques sans cette extension. L'action est maintenant programmée dans le hook de renouvellement propre au plugin et dans le même groupe que les autres actions de paiement, donc annuler, mettre en pause ou supprimer l'abonnement le supprime comme on peut s'y attendre. L'ancien nom de hook est toujours programmé en parallèle pour les boutiques qui en dépendaient, et peut être désactivé avec le filtre aswc_start_date_schedule_legacy_payment_hook.
• Changer une date de premier paiement déjà programmée déplace maintenant ce paiement au lieu d'en ajouter un second.
• L'intégration avec les blocs Panier et Paiement ne disparaît plus sur les sites fonctionnant avec SCRIPT_DEBUG activé. Seul le script minifié était distribué, donc le chemin non minifié que WordPress demande dans ce mode renvoyait un 404 et toute l'intégration cessait de se charger silencieusement, emportant avec elle le contrôle «Voir les produits attachés» des boîtes d'abonnement et les annonces parlées du total récurrent. Maintenant, les deux versions sont générées à partir du même code source.
• Les tableaux de remises des pages de produit chargent maintenant leur feuille de styles et leur script dans les thèmes classiques. Les ressources étaient résolues à partir du produit qui était rendu dans la boucle, qui n'est toujours pas disponible lorsque un thème classique enfile les scripts, donc dans ces thèmes, le tableau apparaissait complètement sans styles et le rafraîchissement des remises des produits variables n'était pas exécuté. Les thèmes de blocs n'étaient pas affectés.
• Passerelle Redsys incluse : les commandes d'abonnement sont maintenant correctement détectées au checkout, de sorte que le token de carte récurrente (COF) est demandé à Redsys et les renouvellements peuvent être facturés automatiquement.
• Passerelle Redsys incluse : la carte d'abonnement enregistrée apparaît maintenant dans Mon compte > Méthodes de paiement (étiquetée comme «Abonnement»). Le filtre des méthodes de paiement enregistrées la masquait lorsqu'il était exécuté en dehors du contexte de checkout.
• Passerelle Redsys incluse : enregistrer le token de l'abonnement n'interrompt plus la notification de paiement lorsque la banque ne renvoie pas le numéro de carte masqué (Ds_Card_Number); un marqueur sécurisé des quatre derniers chiffres est stocké pour que la tokenisation et les renouvellements automatiques continuent de fonctionner.
• Pont PayPal : le conteneur de services du plugin officiel est maintenant obtenu via l'action réelle de démarrage de PPCP (avec une alternative directe), de sorte que les facturations de renouvellement fonctionnent. La recherche précédente dépendait d'un filtre qui n'existe pas dans WooCommerce PayPal Payments.
• Pont PayPal : les charges utiles des webhooks ne sont plus traitées lorsque la vérification de la signature de PayPal a rejeté la demande, ce qui ferme un vecteur de manipulation non authentifiée de l'état des commandes et des abonnements.
• Pont PayPal : les facturations de renouvellement suivent exactement le gestionnaire officiel de renouvellements (seulement vault_id, sans le champ invalide stored_credentials) et le résultat de la facturation est lu à partir de la capture réelle, pas seulement de l'état de la commande de PayPal. Les configurations avec intention d'autorisation sont signalées clairement au lieu d'être marquées comme payées sans capturer les fonds.
• Pont PayPal : les commandes de renouvellement stockent maintenant les métas officielles de PayPal et l'identifiant de transaction, de sorte que les remboursements depuis l'administration de WooCommerce et les requêtes de litiges fonctionnent sur les renouvellements facturés par le pont.
• Pont PayPal : la disponibilité du coffre est lue à partir du système de réglages actuel (avec alternative héritée), les tokens de Venmo et Apple Pay sont envoyés avec leur source de paiement correcte, et la marque de coffre n'est injectée dans le checkout que lorsque l'enregistrement des méthodes de paiement est réellement éligible.
• Pont PayPal : les passerelles de PayPal sont cachées au checkout pour les paniers d'abonnement avec essai gratuit (total zéro), que PayPal ne peut pas enregistrer dans le coffre sans une facturation réelle dans cette configuration.
• Pont Stripe : les exceptions de l'API de Stripe pendant les renouvellements sont capturées et enregistrées comme des échecs de paiement, et chaque facturation de renouvellement envoie une clé d'idempotence déterministe, ce qui évite les facturations en double lorsque une demande expire et est réessayée.
• Pont Stripe : les renouvellements corrects stockent maintenant l'identifiant de charge de Stripe comme identifiant de transaction de la commande, de sorte que les remboursements et les litiges initiés depuis le panneau de Stripe sont associés à la bonne commande.
• Pont Stripe : les renouvellements payés avec des tokens de Stripe Link sont facturés avec le type de méthode de paiement correct, et la vérification de la monnaie d'origine lit la monnaie stockée localement au lieu d'appeler l'API de Stripe à chaque renouvellement.
• Pont Stripe : le support de SEPA est supprimé. L'identifiant de la passerelle SEPA héritée n'existe plus dans Stripe 10.x et ses renouvellements n'ont jamais pu être facturés ; carte et Link restent totalement supportés.
• WooPayments et Stripe : la méthode de paiement est maintenant enregistrée de manière fiable au checkout des blocs (Store API). La détection précédente ne correspondait jamais à cause de la façon dont WooCommerce expose le contexte de paiement, et les abonnements se retrouvaient sans token pour les renouvellements.
• L'enregistrement de la méthode de paiement ne duplique plus la carte lorsque le client paie avec une méthode de paiement déjà enregistrée.
• Changer la méthode de paiement d'un abonnement avec WooPayments ou Stripe tokenise maintenant la nouvelle carte sans facturer le client. Auparavant, le montant total du renouvellement pouvait être facturé au moment du changement.
• Le checkout active et cache automatiquement la case «enregistrer la méthode de paiement» dans les passerelles de carte lorsque le panier contient un abonnement, de sorte que les achats avec 3D Secure se terminent également avec un token enregistré.
• Les hooks de paiement des renouvellements vérifient maintenant que la commande nécessite toujours un paiement avant de facturer (planificateur, ponts et l'action «réessayer le paiement» de l'administration), ce qui évite les facturations en double sur les commandes déjà payées ou autorisées.
• Lorsqu'une méthode de paiement enregistrée cesse d'être valide ou est supprimée, l'abonnement affecté passe maintenant à «en attente» avec une note explicative, au lieu d'échouer silencieusement lors du prochain renouvellement.
• Les lectures de métadonnées dans les boutiques sans HPOS pouvaient renvoyer l'abonnement incorrect ou corrompre les compteurs de réessai en raison d'un argument incorrect passé à get_post_meta(); toutes les appels ont été corrigés.
• Passerelle Redsys incluse : la signature de la réponse REST de renouvellement est vérifiée, les comparaisons de signature utilisent hash_equals(), les notifications sont rejetées lorsqu'aucune clé SHA-256 n'est configurée, et un bug dans la gestion de la clé en mode test a été corrigé. Remarque : les renouvellements facturent intentionnellement le token récurrent (R) le plus récent du client ; lorsqu'un client met à jour sa carte, le nouveau token remplace l'ancien pour tous ses paiements récurrents.

Sécurité :

• La boîte d'abonnement multiproduit décide maintenant de son propre prix sur le serveur. La demande «ajouter à l'abonnement» contenait le total de la boîte, et ce chiffre était stocké comme prix de ligne du panier, donc une demande manipulée pouvait acheter une boîte pour n'importe quel montant. Le prix est maintenant dérivé des prix des produits de la propre boutique (ou du prix fixe configuré dans la boîte) et le chiffre de la demande est ignoré.
• La boîte d'abonnement multiproduit n'accepte désormais que les produits qu'elle propose réellement. Tant la demande d'ajout que celle de modification acceptaient n'importe quel ID de produit et renvoyaient son nom, son prix et son image sans vérifier ni la configuration de la boîte ni si le produit est visible publiquement, ce qui révélait les prix des produits en brouillon, privés et protégés par mot de passe à des visiteurs non identifiés. Les sélections sont désormais validées par rapport à la liste des produits ou catégories de la boîte elle-même et à la visibilité du produit.
• Enregistrer une variation de produit nécessite désormais la capacité « edit products » à elle seule, en plus de son nonce. Cela n'était pas exploitable auparavant, car WooCommerce n'atteint ce gestionnaire qu'après sa propre vérification des capacités ; c'est une défense en profondeur dans la fonction qui écrit.

Mis à jour :

• Lorsque le fuseau horaire du site ne peut pas être lu, le plugin le mentionne désormais dans son propre journal. Il a toujours continué plutôt que d'échouer, en se basant sur le décalage UTC du site et, à défaut, sur l'UTC lui-même. Le faire en silence signifiait qu'un renouvellement facturé à une heure inattendue n'avait rien pour l'expliquer. Le comportement alternatif ne change pas ; il est désormais enregistré, et seulement lorsqu'il se produit réellement.
• Nettoyage interne : le plugin ne mélange plus ses données avec celles de l'extension WooCommerce Subscriptions, ce qui évite les conflits lorsque les deux plugins coexistent sur le même site.
• Documentation pour développeurs mise à jour. La référence des hooks couvre désormais toutes les nouvelles actions et filtres introduits par les passerelles de paiement (voir docs/hooks-reference.md).
• Passerelle Redsys incluse : l'enregistrement migre de l'API obsolète WC_Logger::add() au logger moderne, et l'identifiant de module dans les journaux reflète désormais ce plugin (Advanced_Subscriptions_Redsys) au lieu de la passerelle indépendante Redsys Light.

Compatibilité :

• Testé jusqu'à WordPress 7.1 et WooCommerce 11.1.0.
• Nécessite WooCommerce Stripe Payment Gateway 9.8.0 ou supérieur pour le pont Stripe.
• Nécessite WooCommerce PayPal Payments 3.0 ou supérieur pour le pont PayPal.
• Nécessite WooPayments 7.0 ou supérieur pour le pont WooPayments.
• Entièrement compatible avec le stockage de commandes haute performance de WooCommerce (HPOS).
• Le plugin ne dépend plus de l'extension WooCommerce Subscriptions. Il fonctionne de manière autonome.