Modul für wiederkehrende Zahlungen – Abonnements mit Redsys

27.10.2026
v5.13.0

• Alle Texte des Moduls wurden aus dem Englischen übersetzt: Telegram-Benachrichtigungen, Ablehnungsgründe von Redsys, Fehler bei Stripe, PayPal und SEPA-Überweisungen, der SEPA-Mandattext sowie die E-Mail zur abgelaufenen Karte und deren Betreffzeile. In einem spanischsprachigen Shop werden diese Texte wie zuvor angezeigt; in einem englischsprachigen Shop (oder einem Shop in einer anderen, noch nicht übersetzten Sprache) werden sie nicht mehr auf Spanisch angezeigt. Händlerbenachrichtigungen werden in der Sprache des Shops angezeigt, während Kunden sie in ihrer eigenen Sprache sehen.
• Die Kopfzeilen der Prognose- und SEPA-Überweisungs-CSV-Dateien sind jetzt in Englisch.
• Der Einstellungsbildschirm stürzt nicht mehr ab, wenn er ohne den Backoffice-Controller geöffnet wird (was bei der Addons-Überprüfung in PrestaShop der Fall war). 8.1.2Im Fehlerfall wird eine Warnung angezeigt und im Protokoll vermerkt, anstatt einer fehlerhaften Seite.
• Die Links zur Änderung des PayPal-Kontos und der Stripe-Karte validieren Schlüssel und Token vor der Verwendung und leiten ausschließlich über HTTPS zu PayPal bzw. Stripe Checkout weiter. Technische Hinweise:
• RkrSubsText::t() (classes/RkrSubsText.php) übersetzt ganze Sätze mit vsprintf und macht die HTML-Maskierung rückgängig l() für Telegram. Die beiden Redsys-Code-Maps werden zu einer einzigen kombiniert (RkrSubsRedsysHelper). getContent() Wickel renderRkrConfiguration() In try/catch (Wurfgerät) und die Formen nehmen die Sprachen von getRkrFormLanguages().

27.10.2026
v5.12.2

• Performance: jQuery UI, der zugehörige Kalender und die Übersetzungsdatei mit allen Sprachen (ca. 110 KB) werden nicht mehr auf jeder Produktseite, in jedem Angebot, auf der Startseite, im Warenkorb und bei jeder Bestellung geladen. Der Kalender für das erste Lieferdatum wird nur noch bei physischen Produkten angezeigt, bei denen die Option „Erstes Lieferdatum anzeigen“ aktiviert ist. Er wird nun beim Aufruf dieses Feldes und nur in der Sprache des Shops heruntergeladen.
• Raus mit einem console.log die beim Ändern der Kombinationen in der Browserkonsole erhalten blieben.

22.10.2026
v5.12.1

• Banküberweisung: Die Standardgruppe des Kunden wird auch zur Anzeige der Zahlungsmethode verwendet. Ein Kunde, der per Import oder API angelegt wurde und dessen Gruppeneintrag fehlt, sieht diese nicht, selbst wenn seine Gruppe ausgewählt ist.

22.10.2026
v5.12.0

• Bestellungen, die noch per Banküberweisung bezahlt werden müssen, können per Karte (Stripe oder Redsys) oder PayPal beglichen werden: Klicken Sie dazu in Ihrem Konto in den Bestelldetails auf „Jetzt bezahlen mit…“ oder folgen Sie dem Link in den Überweisungs- und Erinnerungs-E-Mails. Die gleiche Bestellung wird zum exakten Betrag bezahlt; es wird keine neue Bestellung erstellt.
• Die Bestellung wechselt erst dann zu „Zahlung akzeptiert“, wenn das Zahlungsportal die Zahlung bestätigt (Benachrichtigung von Stripe oder Redsys bzw. ein Screenshot von PayPal aus dem Shop). Anschließend wird die Zahlung mit ihrer Referenznummer erfasst, die Rechnung erstellt und die Downloads werden freigegeben. Vorher ist kein Zugriff möglich.
• Bei Abonnementbestellungen wird das Abonnement über das verwendete Zahlungsportal abgewickelt und die Karte oder das PayPal-Konto gespeichert: Zukünftige Verlängerungen werden automatisch abgebucht. Zahlungserinnerungen werden nicht mehr versendet.
• Eine laufende Zahlung blockiert eine weitere für 30 Minuten. Eine erneute Benachrichtigung des Zahlungsanbieters führt nicht zu einer doppelten Zahlung. Geht eine zweite Zahlung für eine bereits bezahlte Bestellung ein, wird diese nicht verbucht, und Sie werden per Telegram benachrichtigt, die Zahlung zurückzuerstatten. Trifft die Überweisung später ein, wird dies im Überweisungsbildschirm angezeigt.
• Der Kunde erhält eine E-Mail: „Zahlung erhalten, Sie müssen die Überweisung nicht mehr durchführen.“
• PayPal ist enthalten, aber (wie der Rest von PayPal) nicht vollständig getestet. Technische Hinweise:
• RkrSubsTransferPayNow (Klassen/Gateways/Transfers), Fahrer Transferpay Und Transferpayreturn, Präfix P{id_order} in der Redsys-Benachrichtigung, metadata.rkr_pay_order in Stripes PaymentIntent und custom_id = order-{id} auf PayPal. Neue Spalten in rkr_subs_transfer und Haken Bestelldetails anzeigen (Upgrade) 5.12.0).

22.10.2026
v5.11.0

• Neue Zahlungsmethode: Banküberweisung, für Einzelkäufe und Abonnements, nur für die von Ihnen ausgewählten Kundengruppen. Sie legen Kontoinhaber, IBAN, BIC, Bank, Verwendungszweck (inkl. Bestellnummer) und Zahlungsanweisungen fest.
• Die Bestellung hat weiterhin den Status „Überweisung ausstehend“, was NICHT bedeutet, dass sie bezahlt ist: Es gibt keine Downloads, keine Rechnung und es steht keine Zahlung aus (einschließlich des Geschenkabonnements), bis Sie sie unter Abonnements > Überweisungen als bezahlt markieren. Sobald Sie die Bestellung als bezahlt markieren, ändert sich der Status zu „Zahlung akzeptiert“, und der Kunde erhält seine Download-Links.
• Verlängerungen werden auf die gleiche Weise erstellt, ohne Zahlung, und der Kunde erhält eine E-Mail mit den Überweisungsdetails.
• Nicht bezahlte Überweisungen: Kundenerinnerungen (standardmäßig 3 und 7 Tage), Telegram-Benachrichtigung und nach Ablauf der Frist (standardmäßig 14 Tage) wird das Abonnement wie bei fehlgeschlagenen Zahlungen pausiert. Durch Markieren als bezahlt wird es automatisch wieder aktiviert. Technische Hinweise:
• Laufsteg überweisen (Kennung) rkrtransferpayment) In Klassen/Zugangspunkte/Transfer, Planke rkr_subs_transfer, eigenen Bestellstatus (bezahlt=0, protokollierbar=0, keine E-Mail) und Bildschirm AdminRkrSubsTransfers. Es ist installiert und ausgeschaltet (Upgrade). 5.11.0).

22.10.2026
v5.10.1

• Aktualisierung von einer früheren Version auf 5.8.0 fehlgeschlagen ("Aktualisiert von 5.5.2 Zu 5.7.0, 4 verbleibende Updates») und PrestaShop deaktivierte das Modul: das Update des 5.8.0 Ich versuchte, eine Tabelle auszufüllen, die Folgendes erstellt: 5.10.0 und es existierte noch nicht. Jetzt werden die Tabellen übersprungen, die noch nicht vorhanden sind. 5.8.0 oder später geschah es nicht.

22.10.2026
v5.10.0

• Änderung des Tarifs eines bestehenden Abonnements: Andere Module können es auf ein anderes Produkt oder eine Kombination mit einem anderen Produkt übertragen. RkrProductSubscriptionGlobal::swapProduct(). Die nächste Verlängerung wird zum neuen Tarifpreis, am selben Datum und mit derselben Zahlungsmethode abgerechnet. Bei Stripe Billing wird der Preis in Stripe ohne anteilige Berechnung angepasst (bei einem Stripe-Fehler ändert sich nichts). Jede Änderung wird im Bereich „Tarifänderungen“ des Abonnements im Backend angezeigt. Technische Hinweise:
• Neuer Tisch rkr_subscription_swap (Upgrade) 5.10.0) und Haken actionRkrSubscriptionProductSwapped mit id_subscription, , vor, , nach Und Notiz.

22.10.2026
v5.9.4

• Das manuelle Öffnen (oder die Verwendung einer Suchmaschine wie Bingbot) der Adresse der internen Aufrufe des Moduls ohne Parameter oder mit einer nicht existierenden Aktion führte zu einem PrestaShop-Fehler („Fehlend“).$template'Parameter"), der im Fehlerprotokoll landete. Jetzt antwortet es mit "400 Ungültige Anfrage" in JSON und fordert Suchmaschinen auf, sie nicht zu indexieren (X-Robots-Tag: noindexGleiches gilt für alle Modul-Controller, die keine eigene Seite haben (Gateway-Rückgaben, Webhooks, Cron).

21.10.2026
v5.9.3

• PrestaShop Addons Produktschlüssel (Modulschlüssel) für Produkt 99324. Keine Änderungen im Betrieb.

21.10.2026
v5.9.2

• Redsys, SEPA und PayPal wurden in den spanischen, französischen, italienischen, deutschen und portugiesischen Shops auf Englisch angezeigt (Zahlungsoptionen, Einstellungen, „Meine Abonnementkarten“, Zahlungsseite und Bestätigung): 175 Texte wurden übersetzt. Umgekehrt wurden einige Redsys-Bildschirme und das Telegram-Panel in den englischen Shops auf Spanisch angezeigt; nun sind sie auf Englisch.
• Die Zahlungsprognose zeigt die Häufigkeit, die Zahlungsmethode und den Status jeder Zahlung („Kein Mandat“, „Keine Karte“, „Läuft ab“...) in der Sprache des Mitarbeiters an (bisher immer auf Spanisch).
• In PrestaShop 9 war die Kopfzeile der Prognosetabelle über mehrere Zeilen hinweg falsch ausgerichtet.
• Der Link „Dokumentation“ in der Konfiguration öffnet das neue Handbuch (Spanisch oder Englisch, je nach Sprache des Mitarbeiters); früher führte er zum alten Handbuch, das nicht mehr existiert.
• Die Schaltflächen „PayPal testen“ und „SEPA testen“ geben den Namen des Zahlungsanbieters korrekt aus. Technische Hinweise:
• Neue Quellen im Übersetzungskatalog: rkrsubsredsysgateway, , rkrsubssepagateway, , rkrsubscriptionforecast und die Vorlagen redsys_*. 18 Zeichenketten ändern ihren Basistext von Spanisch zu Englisch (das Spanische bleibt erhalten). translations/es.php).
• Nach dem Aktualisieren der Demoversion erneut getestet. 5.5.1Der Upload- und Migrationsassistent überträgt Mandate, SEPA-Überweisungen und -Einzüge sowie Stripe-Tarife und -Abonnements aus den einzelnen Modulen.
• Addon-Validator (Einreichung 3780450): nur das falsch positive Ergebnis „Obligatorische Verwendung von PaymentOption“.

21.10.2026
v5.9.1

• Bereit für PrestaShop-Add-ons: Die Stripe-Bibliothek wird nun von Composer bereitgestellt und befindet sich im Ordner Verkäufer/ des Moduls, und der Code erfüllt die Stilregeln und die statische Analyse von PrestaShop (PHPStan).
• Erfordert PHP 8.0 oder höher. In PrestaShop 8 benötigt die Warenkorb-Überschreibung ein PHP-8-Modul, um mit PrestaShop 9 kompatibel zu sein. In PHP 7 ist das Modul nicht installiert, und ein Shop, der es bereits verwendet, kopiert diese Überschreibung beim Aktualisieren nicht.
• Redsys signiert immer mit dem eigenen Code des Moduls, Byte für Byte identisch mit dem der offiziellen Bibliothek. apiRedsys.php. Wenn ein Geschäft diese Datei im Ordner belassen hat, wird sie nicht mehr verwendet, und die Signaturen ändern sich nicht.
• Im Rahmen der Analyse wurden kleinere Fehler behoben: Stripe-Webhook-Zahlungsbenachrichtigungen zeigten eine leere Kennung im Protokoll an, manuell erstellte Stripe-Tarifbeträge wurden in Cent-Beträgen gesendet, und nicht mehr benötigter Code wurde aus Stripe-Testzeiträumen und Warenkorbregeln im Cronjob entfernt. Technische Hinweise:
• stripe/stripe-php 15.0.0 vom Komponisten (composer.json Und composer.lock im Stammverzeichnis, Autoload ohne vorherige Installation der PrestaShop-Datei). Das Upgrade löscht die vorherige Kopie von Klassen/Gateways/Streifen/Anbieter.
• PHP CS Fixer mit PrestaShop-Regeln im gesamten Modul. Signaturen, die sich über mehrere Zeilen erstrecken, werden zu einer einzigen Zeile zusammengefasst: Das Komma nach dem letzten Parameter führt in PHP zu einem Kompilierungsfehler. 7.4.
• Addon-Validierung (Einreichung 3780321): 0 in allen Abschnitten außer „Obligatorische Verwendung von PaymentOption“, ein falsch positives Ergebnis, das in allen Abschnitten auftritt Zahlungsmodul (auch in der offiziellen Fassung) ps_pickupinstore; sehen addons.md).
• Getestet in 9.0.0 (Neuinstallation aus ZIP-Datei, Screenshots im Debug-Modus), 9.2 (Upgrade von 5.9.0, (Bestellungen mit SEPA und Stripe, Cronjobs, Backoffice) und 8.2.8 (Neuinstallation, PS 8-Überschreibungen und -Befehle) Bestellung validieren).

21.10.2026
v5.9.0

[destacado]

• PayPal ist als viertes Zahlungsportal integriert., Neben Redsys, Stripe und SEPA-Lastschrift kann der Kunde auch mit PayPal bezahlen. Enthält der Warenkorb ein Abonnement, speichert PayPal das Konto des Kunden für die automatische Verlängerung. Das Modul bucht den Betrag automatisch zum jeweiligen Verlängerungsdatum ab, ohne dass der Kunde erneut vorgehen muss. Die Funktionsweise ist identisch mit der von Redsys: Verlängerungsdatum und -betrag sind anpassbar, es gibt eine Pausenoption, bei fehlgeschlagenen Zahlungen werden die E-Mail-Adresse des Kunden verwendet, und es wird ein Link zur Änderung des PayPal-Kontos bereitgestellt. Außerdem wird eine Zahlungsprognose angezeigt. Während der kostenlosen Testphase wird das Konto lediglich autorisiert; es fallen keine Gebühren an. Die Aktivierung erfolgt unter Einstellungen → Zahlung mit PayPal-App-Zugangsdaten (Sandbox oder Live). Mit dem Button „PayPal testen“ werden die Zugangsdaten überprüft und sichergestellt, dass die Kontospeicherung (Vault) in der App aktiviert ist. Andernfalls werden keine Verlängerungen verarbeitet.
• Wenn der Kunde über PayPal bezahlt und nicht in den Shop zurückkehrt, holt der Cronjob die Zahlung ein und erstellt die Bestellung; eine Zahlung, die PayPal ausstehend lässt, bleibt so lange unter "Warten auf Zahlung von PayPal", bis sie abgeschlossen ist.
• Entfernen Sie alle Überreste des ursprünglichen Moduls: Drittanbieterlizenz und -anpassungsrichtlinie, veraltetes Handbuch sowie Code, der mit anderen Drittanbieter-Zahlungsmodulen (Wallet, WePay, Adyen und einem weiteren PayPal-Modul) kommunizierte, die ein Shop, der dieses Modul verwendet, nicht mehr nutzt. Die Lizenz für die Module lautet nun AFL 3.0. Rekire.
• Eigene Bedienungsanleitung in Spanisch und Englisch (README_ES.md, , README_EN.md und deren PDFs in Dokumente/), das das Alte ersetzt: Laufstege, gescheiterte Kollektionen, Cronjobs und den Alltag.
• Bei der Überprüfung der Details eines Stripe-Abonnements mit Zahlungen gab der Debug-Modus von PrestaShop einen 500-Fehler zurück. Technische Hinweise:
• Kopfteile mit @Copyright In den Dateien, die diese Angaben nicht enthielten, gelangten Prognosewerte und Erneuerungsbeträge in die Vorlagen und außerhalb der zurückkehren; Gateway-Lücken. Was der Addons-Validator (Stripe-Bibliothek) immer wieder beanstandet. Verkäufer/, PHPStan und PHP CS Fixer-Stil) war bereits vorhanden 5.7.0 und es wird gesondert behandelt.
• PayPal wurde in der Sandbox bis zur Käuferweiterleitung (Schlüssel, Vault, Bestellungen, Checkout) getestet. Die Käufergenehmigung, die daraus resultierende Bestellung und Verlängerungen mit dem gespeicherten Konto wurden noch nicht vollständig getestet: Es wurde eine Testbestellung in der Sandbox durchgeführt, bevor auf ein Live-Konto umgestellt wurde.
• Die Primärschlüssel der Abonnementtabellen werden weiterhin so genannt id_wk_* (id_wk_subscription_products, , _Abonnenten, , _Abonnentenprodukte, , Bestellungen, , _Zeitplan, , _temp_cart, , _cache). Das Umbenennen erfordert ein ALTER TABLE Bei aktiven Abonnements und rund 300 Referenzen würde ein halbherziges Upgrade dazu führen, dass der Shop keine Zahlungen mehr einziehen kann und der Gewinn nur noch minimal ist. Daher wird nichts geändert.
• RkrProductSubscriptionGlobal::isWkPayPalRecurringEnabled() Und isWkAuthorizeNetEnabled() Sie bleiben, immer in FALSCH, weil die Überschreibungen von OrderController Es handelt sich um die bereits in den Geschäften installierten Geräte. Neue Überschreibungen sind nicht mehr erforderlich.
• Der Menücontainer-Tab geht von AdminWkSubsModule Zu AdminRkrSubsModule; Das Upgrade benennt auch die Berechtigungen um (Autorisierungsrolle), sodass die Mitarbeiterprofile diese Information beibehalten. Ältere Aktualisierungen (5.4.6, , 5.4.35Sie sprechen immer wieder von der alten Klasse, weil sie der Veränderung voraus sind.
• Das Upgrade löscht die von früheren Versionen hinterlassenen Dateien (das Überschreiben dieser Dateien mit einer ZIP-Datei löscht nichts) und entfernt den alten Hook. actionWkSubscriptionCancel.

17.10.2026
v5.8.0

[destacado]

• Fehlgeschlagene Zahlungen: Das Modul versucht es erneut und benachrichtigt den Kunden. Schlägt eine Verlängerungszahlung fehl, versucht das System die Zahlung gemäß einem konfigurierbaren Zeitplan erneut (standardmäßig nach 1, 3 und 7 Tagen), anstatt alle Versuche in drei aufeinanderfolgenden Cron-Läufen zu verbrauchen. Nach jedem fehlgeschlagenen Versuch erhält der Kunde eine E-Mail mit dem Datum des nächsten Versuchs und einem sicheren Link, über den er kostenlos eine weitere Karte auf der Redsys- oder Stripe-Seite hinzufügen kann. Sind alle Versuche ausgeschöpft, wird das Abonnement pausiert (oder gekündigt oder unverändert gelassen: dies kann unter Einstellungen → Zahlung → „Fehlgeschlagene Zahlungen“ ausgewählt werden). Sobald der Kunde eine neue Karte hinzufügt, wird das Abonnement fortgesetzt und der ausstehende Betrag abgebucht.
• Stripe-Abrechnung: Stripe kümmert sich um Wiederholungsversuche; das Modul benachrichtigt den Kunden mit dem Zahlungslink und gibt die Entscheidung von Stripe wieder (Stornierung oder Nichtzahlung). Der registrierte Webhook wird automatisch mit neuen Ereignissen aktualisiert.
• SEPA: Im Bereich „SEPA-Zahlungen“ befindet sich eine Schaltfläche „Zurückgegeben“ mit dem Rücklastschriftgrund der Bank. Die zurückgegebene Zahlung wird im nächsten Zahlungsdurchlauf erneut übermittelt, es sei denn, sie kann nicht korrekt verarbeitet werden (falsches oder geschlossenes Konto, fehlendes Mandat, verstorbener Zahlungspflichtiger). In diesem Fall erhält der Kunde eine Benachrichtigung.
• Jedes Detailfenster für Abonnements zeigt fehlgeschlagene Zahlungsversuche, den nächsten Versuch, einen Kundenlink sowie die Schaltflächen „Wiederholen“ und „Versuche löschen“ an. Die Abrechnungsprognose zeigt die Wiederholungsversuche bis zum jeweiligen Datum an.
• Redsys belastete die Karte mit der ersten Zahlung, obwohl der Kunde sie zuvor geändert hatte. (zum Beispiel aufgrund der Ablaufbenachrichtigung) oder das Geschäft hätte sie entfernt. Senden Sie nun die aktive Karte.
• Der Cronjob stoppte in Filialen mit einigen Modulen ohne Vorwarnung. die die Produkte im Warenkorb beim Erstellen der Bestellung zählen: Die Verlängerung wurde durch "leerer Warenkorb" ausgelöst und der Vorgang endete, ohne dass die Bestellung erstellt wurde.
• Die Rückkehrseite nach dem Kartenwechsel zeigt das Design des Shops an.

16.10.2026
v5.7.1

Versionsaktualisierung 5.7.1.

16.10.2026
v5.7.0

• Redsys, Stripe und SEPA-Lastschrift sind im Modul enthalten. Die Installation eines separaten Zahlungsmoduls für Abonnementzahlungen ist nicht mehr erforderlich: Unter Einstellungen → Zahlung finden Sie für jedes Zahlungsgateway einen eigenen Bereich mit Schalter, Einstellungen und einer Schaltfläche „Testen“, die die Schlüssel bei der Bank oder Stripe überprüft. Redsys speichert die Kartendaten für den ersten Kauf und verarbeitet Verlängerungen automatisch. Stripe unterstützt die Stripe-Zahlungsseite oder das Formular im Shop und verlängert Abonnements über Stripe Billing oder per Cronjob mit den gespeicherten Kartendaten. SEPA erfasst das Mandat in der Bestellung, versendet die Vorankündigung und generiert im Backoffice die Zahlungsanforderung (pain.008) für die Bank.
• Migrationsassistent. Ein Shop, der bereits die eigenständigen Module (rkrredsyspayment, rkrstripepayment, rkrsepapayment) nutzt, kann diese mit einem einzigen Klick hierher übertragen: Karten, Mandate, Zahlungen, Stripe-Abonnements und Einstellungen werden kopiert, Bestellstatus werden wiederverwendet, der Stripe-Webhook wird verschoben und das eigenständige Modul wird deaktiviert, ohne dass Daten gelöscht werden. Dieser Vorgang kann mit einem weiteren Klick rückgängig gemacht werden. Bis zum Abschluss der Migration bleibt alles unverändert.
• SEPA-Verlängerungen haben den Status „Zahlung ausstehend“. bis die Bank den Betrag einzieht. Zuvor überschrieb der vom Cronjob gemeldete Status den Zahlungsstatus, und die Zahlungen wurden als bezahlt angezeigt.
• Neuinstallation mit Überschreiben der Daten einer vorherigen Version Es werden keine Spalten mehr nicht erstellt (früher wurde beim Speichern eines Produkts die Meldung "Unbekannte Spalte" angezeigt).
• Durch die Deinstallation bleiben auch gespeicherte Karten, Mandate und Stripe-Abonnements erhalten, genau wie die Abonnenten bereits erhalten wurden.
• Addon-fähig: Keine veralteten Kernaufrufe oder HTML-Code innerhalb von PHP, keine Warnungen im PrestaShop 9-Debug-Modus und mit demselben Namen und derselben Beschreibung in config.xml. Getestet auf PrestaShop 8.2, 9.0, 9.1 und 9.2.

16.10.2026
v5.6.1

Versionsaktualisierung 5.6.1.

16.10.2026
v5.6.0

Versionsaktualisierung 5.6.0.

16.10.2026
v5.5.5

• Der auf der Karte angegebene Verlängerungspreis entsprach nicht dem tatsächlich berechneten Preis. Bei einem Produkt mit einem „Verlängerungspreis“ (z. B. einem Modul mit einem Jahr Support und anschließend einer niedrigeren Jahresgebühr) wurde bisher „Preis pro Periode: 12,09 €“ und „Dieser Betrag wird Ihnen pro Periode in Rechnung gestellt“ angezeigt, obwohl ab der zweiten Verlängerung ein anderer Betrag berechnet wurde. Jetzt zeigt der Block beides an: "Erstes Jahr: 12,09 €" Und „Ab dem zweiten Jahr: 3,03 €/Jahr“, mit dem entsprechenden Steueretikett und dem Hinweis, dass der Verlängerungspreis nach der ersten Zahlung fällig wird. Die Etiketten ändern sich häufig, wenn ein anderer Tarif ausgewählt wird („Erster Monat“, „Ab dem zweiten Monat“).
• Das steht auch im Warenkorb, auf der Bestätigungsseite und in der Registrierungs-E-Mail. Im Warenkorb steht „Abonnement, jährliche Verlängerung für 3,03 €“. Die Bestellbestätigung bezeichnet die erste Zahlung nicht mehr als „Betrag pro Verlängerung“, und in der Abonnement-E-Mail wird unter dem Gesamtbetrag „Jede Verlängerung: …“ hinzugefügt. Die Berechnung erfolgt wie bei einer automatischen Zahlung: Zuerst wird der manuell für das Abonnement festgelegte Betrag berechnet, und falls kein Betrag festgelegt wurde, der Verlängerungspreis des Produkts.
• Der Radius für „Abonnieren“ und „Einmalkauf“ entspricht dem jeweiligen Label., Und auf Mobilgeräten bleibt es nicht mehr einfach in einer Zeile über dem Text.
• Der Text im Block, im Warenkorb und in den Bestätigungsnachrichten wurde ins Französische, Italienische, Deutsche und Portugiesische übersetzt, obwohl er ursprünglich auf Englisch war. In der Warenkorbzeile stand außerdem „erneuert jährlich“ auf Spanisch.

16.10.2026
v5.5.4

• Da der erweiterte Versand von PrestaShop aktiviert war, wurde keine gemischte Bestellung erstellt. PrestaShop 9.1 und 9.2 enthalten die Beta-Option „improved_shipment“ (mehrere Teillieferungen pro Bestellung, standardmäßig deaktiviert). Bei aktivierter Option und gemischten Verkäufen (Standard- und Abonnementprodukte) zahlte der Kunde zwar, die Bestellung wurde jedoch nicht erstellt: Das Modul übermittelte die Produkte weiterhin im vorherigen Format an PrestaShop. Jetzt wird eine Bestellung für das Abonnement und eine weitere für die Standardprodukte erstellt, jeweils mit eigener Teillieferung. Die Versandkosten werden, wie bei deaktivierter Option, nur für die Abonnementbestellung berechnet. Der Gesamtbetrag der Bestellungen entspricht dem gezahlten Betrag, und die Bestätigungs-E-Mail listet die Produkte jeder Bestellung auf. 1.7.8, 8 und 9.0, nichts ändert sich.
• Beim Aktualisieren kopiert das Modul seine override/classes/PaymentModule.php im Laden.

15.10.2026
v5.5.3

• Bereit für PrestaShop 9.2. Das Modul ersetzt die Bestellvalidierung von PrestaShop, die in Version 9.2 in dreierlei Hinsicht geändert wurde, die das Modul nun ebenfalls übernimmt: Es vergleicht sicher den Sicherheitsschlüssel des Warenkorbs (hash_gleich), fügen Sie die Rechnung der Bestätigungs-E-Mail entsprechend der Statusoption bei, die das Anhängen der Rechnung im PDF-Format erfordert, und geben Sie in der E-Mail an, welcher Spediteur für welches Produkt zuständig ist, falls die Bestellung in mehreren Teillieferungen versendet wird. 1.7.8, Bei den Versionen 8, 9.0 und 9.1 bleiben Rechnung und Spediteur wie in der jeweiligen Version von PrestaShop.
• Bestellungen aus anderen Zahlungsmodulen haben ihre Referenz verloren. Wenn der gemischte Verkauf (normal und Abonnement) deaktiviert ist, hat das Modul die Validierung ohne die von einigen Zahlungsmodulen gesendete Bestellreferenz an PrestaShop weitergeleitet, woraufhin PrestaShop eine neue Bestellreferenz generiert hat.
• Die Bestätigungs-E-Mail könnte die Bestellung während des Bezahlvorgangs auf einer Seite stornieren. Wurde die Bestellung direkt auf der Bestellseite validiert, gelangte der Preis jeder Position der E-Mail als Liste und nicht als Objekt an das Modul; bei aktiviertem Debugging brach die PHP-Warnung die Bestellung nach der Erstellung ab, ohne die E-Mail zu versenden.
• Beim Aktualisieren kopiert das Modul seine override/classes/PaymentModule.php im Laden.

07.10.2026
v5.5.2

• Die Produktlisten überprüften die Karte, um festzustellen, ob für das Produkt ein Abonnement bestand. In einer Kategorie von 36 Produkten gab es 180 nahezu identische Anfragen (aus dem Zahlungsmodul, der Überschreibung von Link und die Hooks selbst), ohne dass Abonnements angezeigt werden. Das Modul liest nun alle Abonnement-IDs des Shops auf einmal und beantwortet den Rest der Anfrage direkt aus dem Speicher. Der Preisblock für Produkte ohne Abonnement wird sofort angezeigt, ohne das Produkt zu laden oder neun Zeichenketten zu übersetzen. Der Speicher wird beim Erstellen, Ändern oder Löschen eines Abonnements geleert und ist nach Shop getrennt, sodass der Kunde mit weniger Abfragen dasselbe sieht wie zuvor.

29.09.2026
v5.5.1

• Der Preis des Tokens änderte sich nicht, als eine andere Frequenz gewählt wurde. Das Modul hat es per AJAX angefordert und geschrieben. .aktueller-preis des Themes, das in vielen Shops nicht erhältlich ist: Das Modul selbst blendet den Preis des Themes bei Produkten aus, die nur im Abonnement erhältlich sind, und in https://rekire.com/de/module/rkrtotaltranslator/urlstranslation ersetzt es rkrdualprice. Die Antwort würde zwar eintreffen, aber es gab keine Möglichkeit, sie zu notieren, sodass der Kunde unabhängig von seiner Auswahl immer den Katalogpreis sah. Jetzt wird der Abonnementblock angezeigt. "Preis für jeden Zeitraum" Der Preis wird anhand der gewählten Option sofort berechnet. Die Preisberechnung erfolgt serverseitig automatisch über dasselbe System, das auch die Warenkorb-Zahlungen abwickelt. Sie zahlen also genau den angezeigten Preis – ohne Serveranfragen und unabhängig vom Theme. Bei „Einzelkauf“ wird der entsprechende Artikel ausgeblendet, da der reguläre Preis des Produkts verwendet wird.