Module de paiements récurrents - abonnements avec Redsys

27/10/2026
v5.13.0

• Tous les textes du module sont désormais traduits de l'anglais : notifications Telegram, motifs de rejet Redsys, erreurs de virement Stripe, PayPal et SEPA, texte du mandat SEPA, ainsi que l'e-mail de confirmation d'expiration de carte et son objet. Dans une boutique en espagnol, l'affichage reste inchangé ; dans une boutique en anglais (ou dans une autre langue non traduite), l'espagnol n'apparaît plus. Les notifications marchandes sont affichées dans la langue de la boutique, tandis que le client les voit dans sa propre langue.
• Les en-têtes des fichiers CSV de prévisions et de virements SEPA sont désormais en anglais.
• L'écran des paramètres ne plante plus s'il est ouvert sans le contrôleur back-office (ce qui se produisait lors de la révision des modules complémentaires dans PrestaShop). 8.1.2); en cas de défaillance, il affiche un avertissement et le consigne dans le journal, au lieu d'afficher une page cassée.
• Les liens de modification de compte PayPal et de carte Stripe valident la clé et le jeton avant utilisation et redirigent uniquement vers PayPal ou Stripe Checkout via HTTPS. Remarques techniques :
• RkrSubsText::t() (classes/RkrSubsText.php) traduit des phrases entières avec vsprintf et annule l'échappement HTML de l() pour Telegram. Les deux cartes de code Redsys sont combinées en une seule (RkrSubsRedsysHelper). obtenirContenu() wraps renderRkrConfiguration() dans essayer/attraper (Jetable) et les formes prennent les langues de obtenirRkrFormLanguages().

27/10/2026
v5.12.2

• Performances : jQuery UI, son calendrier et le fichier de traduction contenant toutes les langues (environ 110 Ko) ne sont plus chargés sur chaque page produit, liste de produits, page d’accueil, panier et commande. Le calendrier de première livraison s’affiche uniquement sur les produits physiques pour lesquels l’option « Afficher la date de première livraison » est activée ; il est désormais téléchargé lorsque ce champ est rencontré, et uniquement dans la langue de la boutique.
• Sortir avec un console.log qui restait affiché dans la console du navigateur lors du changement de combinaisons.

v5.12.12026/10/22

• Virement bancaire : Le groupe par défaut du client est également utilisé pour afficher le mode de paiement. Un client créé par importation ou via API, sans son groupe associé, ne verra pas ce mode de paiement, même si son groupe est sélectionné.

v5.12.02026/10/22

• Les commandes en attente de virement bancaire peuvent être réglées par carte (Stripe ou Redsys) ou PayPal : cliquez sur le bouton « Payer maintenant avec… » dans le détail de la commande, dans votre compte, ou sur le lien figurant dans les e-mails de confirmation de virement et de rappel. La commande en question est réglée pour son montant exact : aucune nouvelle commande n’est créée.
• La commande ne passe à l'étape « Paiement accepté » que lorsque la plateforme de paiement le confirme (notification de Stripe ou Redsys, ou capture d'écran PayPal de la boutique). Le paiement est alors enregistré avec sa référence, la facture est générée et les téléchargements sont disponibles. Avant cela, aucun accès n'est possible.
• S'il s'agit d'un abonnement, celui-ci est traité via la plateforme de paiement utilisée et les informations de la carte ou du compte PayPal sont enregistrées : les renouvellements suivants sont facturés automatiquement. Aucun rappel de virement ne sera envoyé.
• Un paiement en cours bloque un autre pendant 30 minutes. Une notification répétée de la plateforme de paiement ne constitue pas un doublon. Si un second paiement arrive pour une commande déjà réglée, il n'est pas appliqué et vous êtes notifié par Telegram pour le rembourser. Si le virement arrive ultérieurement, cela sera indiqué sur l'écran « Virements ».
• Le client reçoit un courriel : « Paiement reçu, vous n’avez plus besoin d’effectuer le virement. »
• PayPal est inclus mais n'a pas été entièrement testé (comme le reste de PayPal). Notes techniques :
• RkrSubsTransferPayNow (classes/passerelles/transferts), conducteurs transferpay et retour de paiement de transfert, préfixe P{id_order} dans la notification Redsys, metadata.rkr_pay_order dans l'intention de paiement et de Stripe custom_id = commande-{id} sur PayPal. Nouvelles colonnes dans rkr_subs_transfer et crochet afficherDétails de la commande (mise à niveau 5.12.0).

v5.11.02026/10/22

• Nouveau mode de paiement : virement bancaire, pour les achats individuels et les abonnements, uniquement pour les groupes de clients de votre choix. Vous configurez le titulaire du compte, l’IBAN, le BIC, la banque, la référence de paiement (y compris le numéro de commande) et les instructions.
• La commande reste « En attente de transfert », ce qui ne signifie pas qu'elle est payée : aucun téléchargement n'est disponible, aucune facture n'est émise et aucun paiement n'est en attente (y compris l'abonnement cadeau) tant que vous ne l'avez pas marquée comme payée dans Abonnements > Transferts. Une fois la commande marquée comme payée, son statut passe à « Paiement accepté » et le client reçoit ses liens de téléchargement.
• Les renouvellements sont créés de la même manière, sans paiement, et le client reçoit un courriel contenant les détails du virement.
• Paiements impayés : rappels clients (par défaut à 3 et 7 jours), notification Telegram, et après l’échéance (14 jours par défaut), l’abonnement est suspendu comme pour les paiements échoués. Le fait de le marquer comme payé le réactive automatiquement. Notes techniques :
• Passerelle transfert (identifiant) rkrtransferpayment) dans classes/passerelles/transfert, conseil rkr_subs_transfer, statut de commande (payé=0, enregistrable=0, pas d'e-mail) et écran AdminRkrSubsTransferts. Il est installé désactivé (mise à niveau) 5.11.0).

v5.10.12026/10/22

• Mise à jour depuis une version précédente vers 5.8.0 échec (« Mise à jour depuis 5.5.2 à 5.7.0, 4 mises à jour restantes») et PrestaShop a désactivé le module : la mise à jour de 5.8.0 J'essayais de compléter un tableau qui crée le 5.10.0 et elle n'existait pas encore. Maintenant, elle ignore les tables qui ne sont pas encore là. De la 5.8.0 ou bien cela ne s'est pas produit par la suite.

v5.10.02026/10/22

• Modification d'un abonnement existant : d'autres modules permettent de le transférer vers un autre produit ou de le combiner avec d'autres. RkrProductSubscriptionGlobal::échangerProduct(). Le prochain renouvellement sera facturé au nouveau tarif, à la même date et selon le même mode de paiement. Avec Stripe Billing, le prix est modifié directement dans Stripe, sans prorata (en cas de problème avec Stripe, rien ne change). Chaque modification est visible dans la section « Modifications du forfait » de votre abonnement, accessible depuis votre espace client. Remarques techniques :
• Nouvelle table rkr_subscription_swap (mise à niveau 5.10.0) et crochet actionRkrSubscriptionProductSwapped avec id_abonnement, , avant, , après et note.

v5.9.42026/10/22

• L'ouverture manuelle (ou l'utilisation d'un moteur de recherche comme Bingbot) de l'adresse des appels internes du module, sans paramètres ou avec une action inexistante, a entraîné une erreur PrestaShop (« Missing »).$template'paramètre") qui atteignait le journal d'erreurs. Maintenant, il répond « 400 requête invalide » en JSON et demande aux moteurs de recherche de ne pas l'indexer (X-Robots-Tag : noindexIl en va de même pour tous les contrôleurs de modules qui n'ont pas leur propre page (retours de passerelle, webhooks, cron).

21/10/2026
v5.9.3

• Clé de produit des modules complémentaires PrestaShop (clé_module) pour le produit 99324. Aucun changement de fonctionnement.

21/10/2026
v5.9.2

• Dans les boutiques espagnole, française, italienne, allemande et portugaise, les pages Redsys, SEPA et PayPal étaient affichées en anglais (options de paiement, paramètres, « Mes cartes d’abonnement », page de paiement et confirmation) : 175 textes ont été traduits. En revanche, certaines interfaces Redsys et le panneau Telegram étaient affichés en espagnol dans les boutiques anglophones ; ils sont désormais en anglais.
• La prévision de recouvrement indique la fréquence, le mode de paiement et le statut de chaque recouvrement (« Pas de mandat », « Pas de carte », « Expire »...) dans la langue de l'employé (auparavant, toujours en espagnol).
• Dans PrestaShop 9, l'en-tête du tableau des prévisions de collection était mal aligné sur plusieurs lignes.
• Le lien « Documentation » dans la configuration ouvre le nouveau manuel (espagnol ou anglais selon la langue de l'employé) ; auparavant, il menait à l'ancien manuel, qui n'existe plus.
• Les boutons « Tester PayPal » et « Tester SEPA » affichent correctement le nom de la passerelle de paiement. Remarques techniques :
• Nouvelles sources dans le catalogue de traductions : passerelle rkrsubsredsys, , passerelle rkrsubssepa, , rkrsubscriptionforecast et les modèles redsys_*. 18 chaînes de caractères changent leur texte de base de l'espagnol vers l'anglais (l'espagnol reste dans traductions/es.php).
• Testé à nouveau après la mise à jour de la démo à partir de 5.5.1L'assistant de téléchargement et de migration transfère les mandats, les virements et encaissements SEPA, ainsi que les plans et abonnements Stripe à partir des modules individuels.
• Validateur d'extension (soumission 3780450) : seul le faux positif « Utilisation obligatoire de PaymentOption ».

21/10/2026
v5.9.1

• Prêt pour les modules complémentaires PrestaShop : la bibliothèque Stripe est désormais disponible via Composer, dans le dossier fournisseur/ du module, et le code passe les règles de style et l'analyse statique de PrestaShop (PHPStan).
• Nécessite PHP 8.0 ou supérieur. Dans PrestaShop 8, la personnalisation du panier nécessite un module PHP 8 pour être compatible avec PrestaShop 9. Dans PHP 7, ce module n'est pas installé, et une boutique qui le possède déjà ne copiera pas cette personnalisation lors de la mise à jour.
• Redsys signe toujours avec le code propre au module, exactement le même octet pour octet que la bibliothèque officielle. apiRedsys.php. Si un magasin a laissé ce fichier dans le dossier, il n'est plus utilisé et les signatures ne changent pas.
• Corrections mineures identifiées lors de l'analyse : les notifications de paiement par webhook Stripe affichaient un identifiant vide dans le journal, les montants des forfaits Stripe créés manuellement étaient envoyés en centimes entiers et du code mort a été supprimé des périodes d'essai Stripe et des règles de panier dans la tâche cron. Notes techniques :
• stripe/stripe-php 15.0.0 par Compositeur (composer.json et composer.lock dans le répertoire racine, chargement automatique sans précéder celui de PrestaShop). La mise à jour supprime la copie précédente de classes/passerelles/stripe/fournisseur.
• Correcteur PHP CS avec règles PrestaShop intégrées. Les signatures réparties sur plusieurs lignes sont fusionnées en une seule : la virgule après le dernier paramètre ne compile pas en PHP. 7.4.
• Validateur d'extension (soumission 3780321) : 0 dans toutes les sections sauf « Utilisation obligatoire de PaymentOption », un faux positif qui apparaît dans toutes les sections. Module de paiement (également dans la version officielle) ps_pickupinstore; voir addons.md).
• Testé dans 9.0.0 (installation propre à partir d'un fichier ZIP, captures d'écran en mode débogage), 9.2 (mise à niveau depuis 5.9.0, (commandes avec SEPA et Stripe, cron, back-office) et 8.2.8 (installation à partir de zéro, remplacements et commandes PS 8 par) valider la commande).

21/10/2026
v5.9.0

[destacado]

• PayPal inclus en tant que quatrième passerelle de paiement, Outre Redsys, Stripe et le prélèvement SEPA, le client peut payer via PayPal. Si le panier inclut un abonnement, PayPal enregistre son compte pour les renouvellements, qui sont automatiquement prélevés à chaque date d'échéance, sans intervention du client. Le fonctionnement est identique à celui de Redsys : date et montant de renouvellement modifiables, option de suspension, relances en cas d'échec de paiement via l'adresse e-mail du client et un lien pour modifier son compte PayPal, ainsi qu'une prévision des paiements. La période d'essai gratuite permet uniquement d'autoriser le compte ; aucun prélèvement n'est effectué. L'activation se fait dans Paramètres → Paiement avec les identifiants de l'application PayPal (environnement de test ou de production). Le bouton « Essayer PayPal » vérifie les identifiants et s'assure que l'enregistrement du compte (Coffre-fort) est activé dans l'application ; à défaut, les renouvellements ne seront pas traités.
• Si le client paie via PayPal et ne revient pas en magasin, la tâche cron collecte le paiement et crée la commande ; un paiement que PayPal laisse en attente reste « En attente de paiement PayPal » jusqu’à ce qu’il soit effectué.
• Supprimez tous les vestiges du module d'origine : licence tierce et politique de personnalisation, manuel obsolète et code permettant la communication avec d'autres modules de paiement tiers (portefeuille électronique, WePay, Adyen et un autre module PayPal) que la boutique utilisant ce module n'utilise plus. La licence est désormais AFL 3.0 pour les modules de Rekire.
• Manuel d'utilisation en espagnol et en anglais (README_ES.md, , README_EN.md et leurs PDF dans docs/), qui remplace l'ancien : les podiums, les collections ratées, cron et le quotidien.
• Dans les détails d'un abonnement Stripe avec paiements, le mode débogage de PrestaShop a renvoyé une erreur 500. Notes techniques :
• Têtes de lit avec © Copyright Dans les fichiers qui ne le contenaient pas, les valeurs prévisionnelles et les montants de renouvellement se sont échappés des modèles et en dehors de ceux-ci. retour; Lacunes au niveau de la passerelle. Ce que le validateur d'extensions (bibliothèque Stripe) signale constamment. fournisseur/, (style PHPStan et PHP CS Fixer) était déjà dans le 5.7.0 et il est traité séparément.
• PayPal a été testé dans l'environnement de test jusqu'à la redirection de l'acheteur (clés, coffre-fort, commandes, paiement). L'approbation de l'acheteur, la commande résultante et les renouvellements avec le compte enregistré n'ont pas été entièrement testés : il est nécessaire de passer une commande test dans l'environnement de test avant de passer à un compte réel.
• Les clés primaires des tables d'abonnement sont toujours appelées id_wk_* (id_wk_subscription_products, , _abonnés, , _produits_abonnés, , _ordres, , _calendrier, , _cart_temporaire, , _cacheLes renommer nécessite un TABLE D'AUTEL Avec des abonnements actifs et environ 300 références, une mise à jour timide empêcherait la boutique d'encaisser les paiements, et le profit serait purement symbolique. Ces éléments ne seront pas modifiés.
• RkrProductSubscriptionGlobal::isWkPayPalRecurringEnabled() et estWkAuthorizeNetEnabled() Ils demeurent, toujours dans FAUX, parce que les dérogations de Contrôleur de commandes Ce sont celles déjà installées en magasin. Plus de nouvelles options de dérogation.
• L'onglet du conteneur de menu passe de Module AdminWkSubs à Module AdminRkrSubs; La mise à jour renomme également ses autorisations (rôle_d'autorisation), donc les profils des employés le conservent. Les mises à jour plus anciennes (5.4.6, , 5.4.35Ils continuent de faire référence à l'ancienne classe parce qu'ils sont en avance sur le changement.
• La mise à jour supprime les fichiers laissés par les versions précédentes (le téléchargement d'un fichier ZIP par-dessus ne supprime rien) et supprime l'ancien hook. actionWkSubscriptionAnnuler.

17/10/2026
v5.8.0

[destacado]

• Paiements échoués : le module réessaie et notifie le client. En cas d'échec d'un paiement de renouvellement, le système effectue des nouvelles tentatives selon une planification configurable (par défaut, 1, 3 et 7 jours plus tard) au lieu d'épuiser toutes les tentatives lors de trois exécutions cron consécutives. Après chaque tentative infructueuse, le client reçoit un courriel indiquant la date de la prochaine tentative et un lien sécurisé pour ajouter gratuitement une autre carte sur la page dédiée (Redsys ou Stripe). Si toutes les tentatives sont épuisées, l'abonnement est suspendu (ou annulé, ou maintenu tel quel : cette option est disponible dans Paramètres → Paiement → « Paiements échoués »). Dès que le client ajoute une nouvelle carte, l'abonnement reprend et le solde restant est débité.
• Facturation Stripe : Stripe gère les nouvelles tentatives ; le module notifie le client avec le lien de paiement et indique la décision de Stripe (annulation ou non-paiement). Le webhook enregistré est automatiquement mis à jour lors de nouveaux événements.
• SEPA : Dans la section « Paiements SEPA », un bouton « Rejeté » indique le motif du rejet par la banque. Le paiement rejeté est réintégré dans le prochain lot, sauf en cas d'impossibilité de traitement (compte incorrect ou clôturé, absence de mandat, débiteur décédé). Le client reçoit alors une notification.
• Chaque panneau de détails d'abonnement affiche les tentatives de paiement infructueuses, la prochaine tentative, un lien client, ainsi que les boutons « Réessayer » et « Effacer les tentatives ». La prévision de facturation indique le nombre de tentatives de nouvelle facturation jusqu'à leur date.
• Redsys a débité la carte pour le premier paiement même si le client l'avait modifiée. (Par exemple, à partir de l'avis d'expiration) ou le magasin l'aurait retirée. Envoyez maintenant la carte valide.
• La tâche cron s'arrêtait sans avertissement dans les magasins équipés de certains modules. qui comptabilisent les produits dans le panier lors de sa création : le renouvellement a été donné par « panier vide » et le pass s’est terminé sans que la commande ne soit créée.
• La page de retour après changement de carte affiche le design du magasin.

16/10/2026
v5.7.1

Mise à jour de la version 5.7.1.

16/10/2026
v5.7.0

• Le module inclut Redsys, Stripe et le prélèvement automatique SEPA. Il n'est plus nécessaire d'installer un module de paiement distinct pour la gestion des abonnements : dans Réglages → Paiement, chaque passerelle de paiement dispose d'un bloc dédié avec son option d'activation/désactivation, ses paramètres et un bouton « Tester » permettant de vérifier les clés auprès de la banque ou de Stripe. Redsys enregistre les informations de carte lors du premier achat et gère les renouvellements automatiquement. Stripe prend en charge la page de paiement Stripe ou le formulaire intégré à la boutique et renouvelle les abonnements via Stripe Billing ou par tâche cron avec les informations de carte enregistrées. SEPA collecte le mandat de paiement lors de la commande, envoie la pré-notification et génère la demande de paiement (pain.008) pour la banque depuis le back-office.
• Assistant de migration. Une boutique utilisant déjà les modules autonomes (rkrredsyspayment, rkrstripepayment, rkrsepapayment) peut les transférer ici en un seul clic : les cartes, mandats, paiements, abonnements et paramètres Stripe sont copiés, les statuts de commande sont réutilisés, le webhook Stripe est transféré et le module autonome est désactivé sans suppression de données. Cette opération peut être annulée en un clic. Jusqu’à la fin de la migration, tout reste inchangé.
• Les renouvellements SEPA sont « En attente de paiement ». jusqu'à ce que la banque encaisse. Auparavant, le statut publié par la tâche cron remplaçait le statut de paiement, et les paiements apparaissaient comme payés.
• Réinstaller par-dessus les données d'une version précédente Il ne laisse plus de colonnes non créées (auparavant, il affichait « Colonne inconnue » lors de l'enregistrement d'un produit).
• La désinstallation préserve également les cartes enregistrées, les mandats et les abonnements Stripe, tout comme les abonnés l'étaient déjà.
• Module complémentaire prêt : aucun appel de noyau obsolète ni code HTML obsolète dans PHP, aucun avertissement en mode débogage PrestaShop 9, et avec le même nom et la même description dans config.xml. Testé sur PrestaShop 8.2, 9.0, 9.1 et 9.2.

16/10/2026
v5.6.1

Mise à jour de la version 5.6.1.

16/10/2026
v5.6.0

Mise à jour de la version 5.6.0.

16/10/2026
v5.5.5

• Le prix de renouvellement indiqué sur la carte ne correspondait pas au prix réellement facturé. Un produit avec un « Prix de renouvellement » (par exemple, un module incluant un an de support puis un tarif annuel réduit) affichait auparavant « Prix par période : 12,09 € » et « Ce montant vous sera facturé à chaque période », bien qu’un montant différent soit facturé à partir du deuxième renouvellement. Désormais, le bloc affiche les deux : «Première année : 12,09 €» et "À partir de la deuxième année : 3,03 €/an", avec l'étiquette fiscale correspondante et un avis indiquant que le prix du renouvellement est facturé après le premier paiement. Les étiquettes changent fréquemment lorsqu'un autre forfait est sélectionné (« Premier mois », « À partir du deuxième mois »).
• Le panier d'achat, la page de confirmation et l'e-mail d'inscription le précisent également. La ligne du panier indique « Abonnement, renouvelable annuellement à 3,03 € ». La confirmation de commande ne mentionne plus le premier paiement comme « Montant par renouvellement », et l'e-mail de confirmation d'abonnement ajoute « Chaque renouvellement :… » sous le total. Le calcul s'effectue comme pour un paiement automatique : d'abord le montant défini manuellement pour cet abonnement, puis, le cas échéant, le prix de renouvellement du produit.
• Le rayon des boutons « S'abonner » et « Achat unique » est aligné sur leur étiquette., Et sur mobile, il ne se contente plus de rester sur une ligne au-dessus du texte.
• Le texte du bloc, du panier et des messages de confirmation a été traduit en français, italien, allemand et portugais, alors qu'il était initialement en anglais. La mention « renouvellement annuel » figurait également en espagnol sur le texte du panier.

16/10/2026
v5.5.4

• Grâce à l'option d'expédition améliorée de PrestaShop, la commande mixte n'a pas été créée. PrestaShop 9.1 et 9.2 incluent l'option bêta « improved_shipment » (plusieurs expéditions par commande, désactivée par défaut). Lorsque cette option était activée et que les ventes mixtes (standard et abonnement) étaient activées, le client payait mais la commande n'était pas créée : le module continuait d'envoyer les produits à PrestaShop au format précédent. Désormais, il crée une commande pour l'abonnement et une autre pour les produits standard, chacune avec sa propre expédition, et les frais de port ne sont facturés que pour la commande d'abonnement, comme lorsque l'option était désactivée ; le total des commandes correspond au montant payé, et l'e-mail de confirmation liste les produits de chaque commande. Lorsque l'option était désactivée, et dans 1.7.8, Entre les versions 8 et 9.0, rien ne change.
• Lors de la mise à jour, le module copie son override/classes/PaymentModule.php dans le magasin.

15/10/2026
v5.5.3

• Prêt pour PrestaShop 9.2. Le module remplace la validation des commandes de PrestaShop, et la version 9.2 l'a modifiée de trois manières que le module effectue désormais également : il compare de manière sécurisée la clé de sécurité du panier (hash_égal), joindre la facture à l'e-mail de confirmation selon l'option de statut qui demande de joindre la facture au format PDF, et, si la commande est expédiée en plusieurs envois, préciser dans l'e-mail quel transporteur prend en charge chaque produit. 1.7.8, 8, 9.0 et 9.1 la facture et le transporteur restent tels quels dans leur propre version de PrestaShop.
• Les commandes provenant d'autres modules de paiement ont perdu leur référence. Lorsque la vente mixte (normale et par abonnement) est désactivée, le module a transmis la validation à PrestaShop sans la référence de commande que certains modules de paiement envoient, et PrestaShop en a généré une autre.
• L'e-mail de confirmation peut annuler la commande lors du passage à la caisse. Si la commande était validée depuis la page de commande elle-même, le prix de chaque ligne de l'e-mail arrivait au module sous forme de liste et non sous forme d'objet ; avec le débogage activé, l'avertissement PHP coupait la commande après sa création et sans envoyer l'e-mail.
• Lors de la mise à jour, le module copie son override/classes/PaymentModule.php dans le magasin.

07/10/2026
v5.5.2

• Les fiches produits vérifiaient si le produit nécessitait un abonnement. Dans une catégorie de 36 produits, on a dénombré 180 requêtes quasi identiques (provenant du module de paiement, la surcharge de Lien et les hooks eux-mêmes), sans qu'aucun abonnement ne soit affiché. Désormais, le module lit tous les identifiants d'abonnement de la boutique en une seule fois et répond directement en mémoire au reste de la requête. Le bloc de prix s'affiche instantanément pour les produits hors abonnement, sans avoir à charger le produit ni à traduire neuf chaînes de caractères. La mémoire est effacée lors de la création, de la modification ou de la suppression d'un abonnement et est gérée séparément par boutique. L'utilisateur retrouve ainsi la même expérience qu'auparavant, avec moins de requêtes.

29/09/2026
v5.5.1

• Le prix du jeton est resté inchangé lors du choix d'une autre fréquence. Le module l'a demandé via AJAX et l'a écrit dans Prix-actuel du thème, qui n'est pas disponible dans de nombreuses boutiques : le module lui-même masque le prix du thème dans les produits « sur abonnement uniquement », et dans rekire.com le remplace rkrdualprice. La réponse arrivait, mais il n'y avait nulle part où la noter ; le client voyait donc le prix du catalogue quel que soit son choix. Désormais, le bloc d'abonnement s'affiche. "Prix pour chaque période" Le prix est calculé instantanément en fonction de l'option choisie. Le prix de chaque option est calculé automatiquement sur le serveur grâce au même système que celui utilisé pour les paiements du panier. Ainsi, le prix affiché est le prix à payer : aucune requête au serveur ni aucune dépendance au thème. Avec l'option « Achat unique », l'article est masqué car son prix normal est appliqué.