Die Entwicklung dieser Version hat 4.360 Euro gekostet. Die Kosten der ersten Version betrugen 38.000 Euro. Die kumulierten Kosten seit der ersten Version belaufen sich auf 42.360 Euro, aber die Kosten für dich sind nur die Lizenz ab 80€.
Neue Version 2.0.x des Plugins Erweiterte Abonnements für WooCommerce. Es ist eine Hauptversion: Das Plugin ist nicht mehr von der WooCommerce Subscriptions-Erweiterung abhängig und bietet jetzt native automatische wiederkehrende Zahlungen mit Stripe, PayPal Payments und WooPayments, sowie Redsys, das weiterhin innerhalb des Plugins funktioniert.
Versionen des Zweigs
2.0.0
Wichtig:
- Dies ist eine Hauptversion. Lies die Aktualisierungsnotizen, bevor du aktualisierst, insbesondere wenn du derzeit über PayPal Standard Zahlungen erhältst.
- Diese Version erfordert WordPress 6.5 oder höher und WooCommerce 8.0 oder höher. Die vorherige Anforderung (WordPress 5.1, WooCommerce 5.1) wurde nie wirklich getestet, und bei der Prüfung für diese Version wurde festgestellt, dass das Plugin dort nicht funktionieren konnte. Die neuen Zahlen sind die, auf denen diese Version verifiziert wurde.
- PayPal Standard wird nicht mehr unterstützt. WooCommerce selbst rät seit Version 5.5 davon ab und blockiert es in neuen Installationen. Wenn du derzeit Abonnements mit PayPal Standard erhältst, installiere WooCommerce PayPal Payments und migriere die Zahlungsmethoden deiner Kunden, bevor du auf 2.0.0 aktualisierst.
Neu:
- Automatische wiederkehrende Zahlungen mit Stripe. Die Erneuerungen werden jetzt off-session auf der gespeicherten Karte des Kunden über das Plugin WooCommerce Stripe Payment Gateway abgerechnet (Version 9.8.0 oder höher erforderlich). Es ist keine zusätzliche Zahlungs-Erweiterung für Abonnements erforderlich.
- Automatische wiederkehrende Zahlungen mit PayPal Payments. Die Erneuerungen werden über das Token des Tresors (vault) von PayPal unter Verwendung des Plugins WooCommerce PayPal Payments abgerechnet (Version 3.0 oder höher erforderlich). Es ist keine zusätzliche Zahlungs-Erweiterung für Abonnements erforderlich.
- Automatische wiederkehrende Zahlungen mit WooPayments. Die Erneuerungen werden off-session auf der gespeicherten Zahlungsmethode des Kunden über das Plugin WooPayments abgerechnet (Version 7.0 oder höher erforderlich). Es ist keine zusätzliche Zahlungs-Erweiterung für Abonnements erforderlich.
- Zuverlässige Speicherung der Zahlungsmethode beim Checkout. Wenn ein Kunde ein Abonnement mit Stripe, PayPal Payments oder WooPayments kauft, stellt das Plugin sicher, dass die Zahlungsmethode für die Erneuerungen gespeichert wird, auch wenn diese Zahlungs-Gateways normalerweise nur speichern, wenn WooCommerce Subscriptions aktiv ist.
- Management von 3D Secure (SCA) bei den Erneuerungen. Wenn die Bank zusätzliche Authentifizierung bei einer wiederkehrenden Zahlung anfordert, wird die Erneuerung als fehlgeschlagen markiert mit einem klaren Grund, und der Kunde kann benachrichtigt werden, um den nächsten Versuch zu autorisieren.
- Automatischer Wiederholungsversuch bei fehlgeschlagenen Erneuerungen. Wenn eine Zahlung fehlschlägt (Karte abgelehnt, unzureichendes Guthaben, Authentifizierung erforderlich usw.), plant der Wiederholungsplaner automatisch den nächsten Versuch neu.
- Erkennung von stornierten PayPal-Vereinbarungen. Wenn ein Kunde seine PayPal-Autorisierung außerhalb deines Shops storniert, erkennt die nächste Erneuerung dies, das Abonnement wird auf „ausstehend“ gesetzt und die gespeicherte Zahlungsmethode wird als ungültig markiert, damit der Kunde sie erneut autorisieren kann.
- Währungs-Sicherheitsprüfung bei den Erneuerungen. Das Plugin weigert sich, eine Erneuerung in einer anderen Währung als der ursprünglichen Zahlung zu berechnen, was doppelte versehentliche Belastungen in der falschen Währung nach einer Währungsänderung des Shops verhindert.
- Ändern der Zahlungsmethode zwischen Gateways. Kunden können zwischen Stripe, PayPal Payments und WooPayments in Mein Konto wechseln, und die nächste Erneuerung verwendet automatisch die neue Methode.
- Neue Verwaltungseinstellung „Abonnement bei vollständiger Rückerstattung einer Erneuerungsbestellung stornieren“ in WooCommerce > Einstellungen > Erweiterte Abonnements > Erweiterte Einstellungen. Standardmäßig deaktiviert. Wenn es deaktiviert ist, hinterlässt eine vollständige Rückerstattung nur eine Notiz im Abonnement; wenn es aktiviert ist, wird das Abonnement storniert. Teilrückerstattungen stornieren niemals.
- Rückerstattungen der Bestellung der ersten Zahlung (die übergeordnete Bestellung) stornieren immer das Abonnement. Das wird natürlich erwartet, wenn die ursprüngliche Bestellung zurückerstattet wird, und ist unabhängig von der neuen Verwaltungseinstellung.
- Automatische Notizen im Abonnement jedes Mal, wenn eine Erneuerung (vollständig oder teilweise) zurückerstattet wird, damit die Chronologie des Abonnements klar bleibt.
- Kompatibilitätsübersicht der Zahlungs-Gateways auf dem Einstellungsbildschirm des Plugins (WooCommerce > Einstellungen > Erweiterte Abonnements > Allgemeine Einstellungen). Zeigt auf einen Blick, ob die unterstützten Gateway-Plugins installiert und aktiv sind, und bietet Ein-Klick-Installations- oder Aktivierungslinks, wenn sie es nicht sind.
- Erkennung von Streitigkeiten und Rückbuchungen in Stripe und PayPal. Wenn ein Kunde einen Streit eröffnet, wird die zugehörige Bestellung auf „ausstehend“ gesetzt, damit du vor der nächsten Erneuerung reagieren kannst.
- Erkennung der Löschung der Zahlungsmethode in Stripe. Wenn das Token der gespeicherten Karte gelöscht wird, werden alle Abonnements, die es verwenden, markiert und auf „ausstehend“ gesetzt, damit der Kunde eine neue Zahlungsmethode speichern kann.
- Redsys erscheint im Kompatibilitätsübersicht der Gateways als enthaltenes Gateway: es reist innerhalb dieses Plugins und benötigt niemals eine separate Installation.
Behoben:
- Deaktivieren von WooCommerce stürzt die gesamte Seite nicht mehr ab. Bisher, wenn WooCommerce aus irgendeinem Grund nicht mehr aktiv war (du hast es deaktiviert, um etwas zu überprüfen, ein Update schlug fehl oder es gab einen eigenen Fehler), versuchte dieses Plugin weiterhin, es zu verwenden und brachte alle Seiten der Seite, einschließlich der WordPress-Verwaltung, zum Absturz, ohne einen anderen Rückweg als FTP. Jetzt erkennt das Plugin, dass WooCommerce nicht vorhanden ist, tut nichts stillschweigend und zeigt eine erklärende Warnung in der Verwaltung an. Wenn WooCommerce wieder aktiviert wird, wird alles ohne zusätzliche Maßnahmen zurückgesetzt.
- Die Erneuerungen konnten zur falschen Zeit geplant werden oder wurden nicht geplant in Shops, deren Zeitzone als UTC-Versatz anstelle von Stadt konfiguriert ist. Die Korrektur betrifft, wie die Zeitzone des Shops gelesen wird, um zu berechnen, wann eine geplante Zahlung fällig ist.
- Eine stornierte Bestellung hinterlässt kein Geisterabonnement mehr. Wenn eine Zahlung fehlschlug und der Wiederholungsversuch des Kunden eine NEUE Bestellung anstelle der ersten generierte (was passiert, wenn die Sitzung verloren geht oder der Warenkorb wechselt), blieb das unbezahlte Abonnement der stornierten Bestellung für immer im Konto des Kunden. Es wurde nie abgerechnet und konnte nicht aktiviert werden, aber der Kunde sah ein Abonnement, das er nie bezahlt hatte. Das Stornieren dieser Bestellung entfernt es jetzt. Bereits aktive Abonnements werden niemals berührt: Das Stornieren einer Erneuerungsbestellung lässt das Abonnement aktiv, wie es sein sollte.
- Das Löschen des Plugins bereinigt jetzt, was ihm gehört. Bisher ließ das Entfernen des Plugins alles zurück: seine Einstellungen, seine Zahlungsblockaden und — was sichtbare Folgen hatte — seine geplanten Aufgaben, die WordPress weiterhin zu erledigen versuchte, obwohl nichts mehr installiert war, um sie zu betreuen, was zu Fehlern führte und sie unendlich wiederholte. Bei der Deinstallation werden jetzt die eigenen Einstellungen des Plugins entfernt und seine geplanten Aufgaben storniert. Absichtlich werden deine Abonnements, Bestellungen oder Kundendaten nicht gelöscht: Sie sind Geschäftsdaten, bleiben in der Datenbank und beim erneuten Installieren des Plugins kommen sie genau so zurück, wie sie waren.
- Das Löschen des Plugins auf einer Seite, die nie WooCommerce hatte, füllt das Fehlerprotokoll nicht mehr. Die Bereinigung suchte nach geplanten Aufgaben in einer Tabelle, die WooCommerce nie erstellt hatte, was bei jeder Gruppe von Aufgaben des Plugins einen Datenbankfehler verursachte. Es war nie fatal (die Bereinigung endete trotzdem und die Nachrichten erschienen nur mit aktivierter Fehlersuche), aber in einem Multisite-Netzwerk wiederholte es sich auf jeder Seite. Die Bereinigung funktioniert weiterhin genau gleich; es werden nur die nutzlosen Nachrichten unterdrückt, und nur auf einer Seite, auf der diese Tabelle tatsächlich fehlt.
- Variable Produkte mit einer Mischung aus Abonnement- und Nicht-Abonnementvariationen: Der Kauf einer Variation, die KEIN Abonnement ist, speichert jetzt die Karte des Kunden nicht und erstellt kein Abonnement. Das Plugin entschied, ob eine Variation ein Abonnement war, indem es die Einstellung des übergeordneten Produkts betrachtete und die „Abonnement“-Checkbox der Variation vollständig ignorierte, sodass in einem variablen Produkt, bei dem nur einige Variationen Abonnements sind, sich alle wie solche verhielten. Eine Variation ohne eigene Einstellung erbt weiterhin die des übergeordneten Produkts, sodass ein Produkt, das du gerade als Abonnement markiert hast, weiterhin funktioniert, bis du seine Variationen konfigurierst.
- Ein manuell erneuertes Abonnement wird nicht mehr automatisch abgebucht. Zwischen der geplanten Erneuerung und dem Zahlungsgateway gab es nichts, was überprüfte, ob der Kunde manuell bezahlen wollte, und bei der Erneuerungsanfrage — die für manuelle Erneuerungen absichtlich ohne Zahlungsmethode erstellt wird — wurde eine aus der ursprünglichen Bestellung kurz vor der Abbuchung ausgefüllt. Manuelle Erneuerungen werden jetzt an beiden Punkten gestoppt, und alle ausstehenden automatischen Wiederholungsversuche werden gelöscht.
- Das Festlegen des Startdatums eines Abonnements über den Administrationsbildschirm verursacht keinen fatalen Fehler mehr. Der Bildschirm rief eine Datums-Schreibmethode auf, die im Abonnementobjekt nicht existierte, sodass in jedem Shop ohne die WooCommerce Subscriptions-Erweiterung das Speichern mit „Call to undefined method“ fehlschlug. Der Bestellfluss mit Startdatum schlug ebenfalls aufgrund einer zweiten nicht vorhandenen Methode fehl. Beide sind jetzt über die eigene Datenspeicherung des Plugins implementiert; ein Abonnement, dem nie ein Startdatum zugewiesen wurde, zeigt weiterhin das Erstellungsdatum seiner Bestellung an, genau wie zuvor.
- Variable Produkte: Die Abonnementeinstellungen pro Variation wurden nie angezeigt, wenn eine Variation als Abonnement markiert wurde. Der Produktbearbeitungsbildschirm forderte das nicht minimierte Lade-Skript unabhängig von der Einstellung an.
SCRIPT_DEBUG, sodass in Installationen, die nur die minimierte Ressource enthalten, ein 404 zurückgegeben wurde und das Feldpanel — das verborgen bleibt, bis dieses Skript ausgeführt wird — nicht angezeigt wurde. - Die Benachrichtigungs-E-Mails für Abonnements, die direkt über die Scheduler API des Plugins ausgelöst wurden, werden jetzt gesendet. Die API akzeptierte einen Benachrichtigungstyp und gab ihn weiter, aber die dahinterstehende Funktion erklärte diesen Parameter nicht, sodass PHP ihn ignorierte und der Typ leer ankam: Es wurde keine E-Mail gesendet und das Benachrichtigungsereignis gab keinen Typ an. Benachrichtigungen, die vom Scheduler in ihren eigenen Hooks ausgelöst wurden, waren nicht betroffen.
- Ein von der Administrationsoberfläche des Abonnements festgelegtes erstes Zahlungsdatum wird jetzt abgebucht. Die geplante Aktion wurde mit dem Hook-Namen von WooCommerce Subscriptions erstellt, den dieses Plugin nicht abhört, sodass die Zahlung einfach nie in Shops ohne diese Erweiterung ausgeführt wurde. Die Aktion wird jetzt im eigenen Erneuerungs-Hook des Plugins und in derselben Gruppe wie die anderen Zahlungsaktionen geplant, sodass das Abbrechen, Pausieren oder Löschen des Abonnements es wie erwartet entfernt. Der alte Hook-Name wird weiterhin parallel für Shops, die davon abhingen, geplant und kann mit dem Filter deaktiviert werden.
aswc_start_date_schedule_legacy_payment_hook. - Das Ändern eines bereits geplanten ersten Zahlungsdatums verschiebt jetzt diese Zahlung, anstatt eine zweite hinzuzufügen.
- Die Integration mit den Warenkorb- und Zahlungsblöcken verschwindet nicht mehr auf Seiten, die mit
SCRIPT_DEBUGaktiviert sind. Es wurde nur das minimierte Skript verteilt, sodass der nicht minimierte Pfad, den WordPress in diesem Modus anfordert, einen 404 zurückgab und die gesamte Integration stillschweigend nicht geladen wurde, wodurch die Kontrolle „View Attached Products“ der Abonnementkästen und die gesprochenen Ankündigungen des wiederkehrenden Gesamtbetrags verloren gingen. Jetzt werden beide Versionen aus demselben Quellcode generiert. - Die Rabatttabellen auf den Produktseiten laden jetzt ihr Stylesheet und ihr Skript in klassischen Themen. Die Ressourcen wurden aus dem Produkt aufgelöst, das im Loop gerendert wurde, das noch nicht verfügbar ist, wenn ein klassisches Thema die Skripte anstellt, sodass in diesen Themen die Tabelle völlig ohne Styles erschien und das Aktualisieren der Rabatte für variable Produkte nicht ausgeführt wurde. Blockthemen waren nicht betroffen.
- Redsys-Gateway enthalten: Abonnementbestellungen werden jetzt korrekt an der Kasse erkannt, sodass Redsys nach dem Token für wiederkehrende Karten (COF) fragt und die Erneuerungen automatisch abgebucht werden können.
- Redsys-Gateway enthalten: Die gespeicherte Abonnementkarte erscheint jetzt in Mein Konto > Zahlungsmethoden (mit der Bezeichnung „Subscription“). Der Filter für gespeicherte Zahlungsmethoden verbarg sie, wenn er außerhalb des Kassenkontexts ausgeführt wurde.
- Redsys-Gateway enthalten: Das Speichern des Tokens des Abonnements bricht die Zahlungsbenachrichtigung nicht mehr ab, wenn die Bank die maskierte Kartennummer nicht zurückgibt (
Ds_Card_Number); es wird ein sicherer Marker der letzten vier Ziffern gespeichert, damit die Tokenisierung und die automatischen Erneuerungen weiterhin funktionieren. - PayPal-Brücke: Der Dienstcontainer des offiziellen Plugins wird jetzt über die tatsächliche Startaktion von PPCP (mit einer direkten Alternative) abgerufen, sodass die Erneuerungszahlungen funktionieren. Die vorherige Suche hing von einem Filter ab, der in WooCommerce PayPal Payments nicht existiert.
- PayPal-Brücke: Die Payloads der Webhooks werden nicht mehr verarbeitet, wenn die PayPal-Signaturüberprüfung die Anfrage abgelehnt hat, was einen nicht authentifizierten Manipulationsvektor des Bestell- und Abonnementstatus schließt.
- PayPal-Brücke: Die Erneuerungszahlungen folgen genau dem offiziellen Handler für Erneuerungen (nur
vault_id, ohne das ungültige Feldstored_credentials) und das Ergebnis der Zahlung wird aus der tatsächlichen Erfassung gelesen, nicht nur aus dem Status der PayPal-Bestellung. Die Konfigurationen mit der Absicht zur Autorisierung werden klar angezeigt, anstatt als bezahlt markiert zu werden, ohne die Mittel zu erfassen. - PayPal-Brücke: Die Bestellungen für Erneuerungen speichern jetzt die offiziellen Ziele von PayPal und die Transaktions-ID, sodass Rückerstattungen von der WooCommerce-Verwaltung und Streitabfragen für die über die Brücke abgebuchten Erneuerungen funktionieren.
- PayPal-Brücke: Die Verfügbarkeit des vault wird aus dem aktuellen Einstellsystem gelesen (mit vererbter Alternative), die Tokens von Venmo und Apple Pay werden mit ihrer payment source korrekt gesendet, und das Zeichen von vault wird nur an der Kasse injiziert, wenn das Speichern von Zahlungsmethoden tatsächlich berechtigt ist.
- PayPal-Brücke: Die PayPal-Gateways werden an der Kasse für Warenkörbe mit Abonnements mit kostenloser Testphase (Gesamt null) ausgeblendet, die PayPal nicht im vault ohne eine tatsächliche Abrechnung in dieser Konfiguration speichern kann.
- Stripe-Brücke: Die Ausnahmen der Stripe-API während der Erneuerungen werden erfasst und als Zahlungsfehler protokolliert, und jede Erneuerungszahlung sendet einen deterministischen Idempotenzschlüssel, um doppelte Zahlungen zu vermeiden, wenn eine Anfrage abläuft und erneut versucht wird.
- Stripe-Brücke: Die korrekten Erneuerungen speichern jetzt die Stripe-Transaktions-ID als Bestelltransaktions-ID, sodass Rückerstattungen und Streitigkeiten, die vom Stripe-Panel aus initiiert werden, mit der richtigen Bestellung verknüpft sind.
- Stripe-Brücke: Erneuerungen, die mit Stripe Link-Tokens bezahlt werden, werden mit dem richtigen Zahlungsmethoden-Typ abgebucht, und die Überprüfung der ursprünglichen Währung liest die lokal gespeicherte Währung, anstatt bei jeder Erneuerung die Stripe-API aufzurufen.
- Stripe-Brücke: Die Unterstützung für SEPA wird entfernt. Die ID des vererbten SEPA-Gateways existiert in Stripe 10.x nicht mehr und ihre Erneuerungen konnten nie abgebucht werden; Karte und Link werden weiterhin vollständig unterstützt.
- WooPayments und Stripe: Die Zahlungsmethode wird jetzt zuverlässig an der Blockkasse (Store API) gespeichert. Die vorherige Erkennung stimmte nie überein, aufgrund der Art und Weise, wie WooCommerce den Zahlungs-Kontext exponiert, und die Abonnements hatten kein Token für die Erneuerungen.
- Das Speichern der Zahlungsmethode dupliziert die Karte nicht mehr, wenn der Kunde mit einer bereits gespeicherten Zahlungsmethode bezahlt.
- Das Ändern der Zahlungsmethode eines Abonnements mit WooPayments oder Stripe tokenisiert jetzt die neue Karte, ohne den Kunden abzubuchen. Zuvor konnte der volle Betrag der Erneuerung zum Zeitpunkt der Änderung abgebucht werden.
- Die Kasse aktiviert und versteckt automatisch das Kästchen „Zahlungsmethode speichern“ in den Kartengateways, wenn der Warenkorb ein Abonnement enthält, sodass Käufe mit 3D Secure ebenfalls mit einem gespeicherten Token enden.
- Die Zahlungs-Hooks der Erneuerungen überprüfen jetzt, ob die Bestellung weiterhin eine Zahlung benötigt, bevor sie abbuchen (Scheduler, Brücken und die Aktion „retry payment“ der Verwaltung), was doppelte Abbuchungen bei bereits bezahlten oder autorisierten Bestellungen verhindert.
- Wenn eine gespeicherte Zahlungsmethode ungültig wird oder gelöscht wird, wechselt das betroffene Abonnement jetzt in den Status „ausstehend“ mit einer erklärenden Notiz, anstatt stillschweigend bei der nächsten Erneuerung zu fehlschlagen.
- Die Metadatenlesungen in Shops ohne HPOS konnten das falsche Abonnement zurückgeben oder die Wiederholungszähler durch ein falsches Argument, das an
get_post_meta(); alle Aufrufe wurden korrigiert. - Redsys-Gateway enthalten: Die Signatur der REST-Antwort zur Erneuerung wird überprüft, die Signaturvergleiche verwenden
hash_equals(), die Benachrichtigungen werden abgelehnt, wenn kein SHA-256-Schlüssel konfiguriert ist, und ein Fehler im Umgang mit dem Schlüssel im Testmodus wurde behoben. Hinweis: Die Erneuerungen ziehen absichtlich das neueste wiederkehrende Token (R) des Kunden ein; wenn ein Kunde seine Karte aktualisiert, ersetzt das neue Token das vorherige für alle seine wiederkehrenden Abbuchungen.
Sicherheit:
- Die Mehrprodukt-Abonnementbox bestimmt jetzt ihren eigenen Preis auf dem Server. Die Anfrage „zum Abonnement hinzufügen“ enthielt den Gesamtbetrag der Box, und dieser Betrag wurde als Zeilenpreis des Warenkorbs gespeichert, sodass eine manipulierte Anfrage eine Box zu jedem Betrag kaufen konnte. Der Preis wird jetzt aus den Produktpreisen des Shops selbst (oder dem festgelegten Festpreis in der Box) abgeleitet, und der Betrag der Anfrage wird ignoriert.
- Das Mehrprodukt-Abonnement akzeptiert jetzt nur noch die Produkte, die es tatsächlich anbietet. Sowohl die Anfrage zum Hinzufügen als auch die zum Bearbeiten akzeptierten jede Produkt-ID und gaben ihren Namen, Preis und Bild zurück, ohne die Konfiguration des Abonnements oder die Sichtbarkeit des Produkts zu überprüfen, was Preise von Entwurf, privaten und passwortgeschützten Produkten an nicht identifizierte Besucher offenbarte. Die Auswahl wird jetzt gegen die Liste der Produkte oder Kategorien des Abonnements und gegen die Sichtbarkeit des Produkts validiert.
- Das Speichern einer Produktvariation erfordert jetzt die Fähigkeit „Produkte bearbeiten“ allein, zusätzlich zu ihrem Nonce. Es war vorher nicht ausnutzbar, da WooCommerce nur nach seiner eigenen Berechtigungsprüfung zu diesem Handler gelangt; es ist eine Verteidigung in der Tiefe in der Funktion, die schreibt.
Aktualisiert:
- Wenn die Zeitzone der Website nicht gelesen werden kann, wird dies jetzt im eigenen Protokoll des Plugins vermerkt. Es hat immer weitergemacht, anstatt zu scheitern, und auf die UTC-Verschiebung der Website zurückgegriffen und, falls nicht vorhanden, auf die eigene UTC. Dies stillschweigend zu tun bedeutete, dass eine zu einer unerwarteten Zeit berechnete Erneuerung nichts hatte, was sie erklärte. Das alternative Verhalten ändert sich nicht; es wird jetzt protokolliert und nur, wenn es tatsächlich passiert.
- Interne Bereinigung: Das Plugin mischt seine Daten nicht mehr mit denen der WooCommerce Subscriptions-Erweiterung, was Konflikte vermeidet, wenn beide Plugins auf derselben Website koexistieren.
- Aktualisierte Dokumentation für Entwickler. Die Referenz der Hooks deckt jetzt alle neuen Aktionen und Filter ab, die von den Zahlungsbrücken eingeführt werden (siehe
docs/hooks-reference.md). - Inklusive Redsys-Gateway: Das Protokoll migriert von der veralteten API
WC_Logger::add()zum modernen Logger, und die Modul-ID in den Protokollen spiegelt jetzt dieses Plugin wider (Advanced_Subscriptions_Redsys) anstelle des eigenständigen Redsys Light-Gateways.
Kompatibilität:
- Getestet bis WordPress 7.1 und WooCommerce 11.1.0.
- Benötigt WooCommerce Stripe Payment Gateway 9.8.0 oder höher für die Stripe-Brücke.
- Benötigt WooCommerce PayPal Payments 3.0 oder höher für die PayPal-Brücke.
- Benötigt WooPayments 7.0 oder höher für die WooPayments-Brücke.
- Vollständig kompatibel mit der Hochleistungsbestellungsspeicherung von WooCommerce (HPOS).
- Das Plugin ist nicht mehr von der WooCommerce Subscriptions-Erweiterung abhängig. Es funktioniert autonom.







