Die Entwicklung dieser Version hat 2.800 Euro gekostet. Die kumulierten Kosten für dieses Jahr betragen 13.350 Euro. Die kumulierten Kosten seit der ersten Version betragen 212.080 Euro, aber die Kosten für dich sind nur die Lizenz von 79€.
Neue Version 31.0.0 des Redsys-Plugins für WooCommerce von WooCommerce.com.
31.0.0
Neu:
- Neue Oberfläche des A2A-Protokolls (Agent2Agent). Optional und standardmäßig deaktiviert. Veröffentlicht eine Agent Card in /.well-known/agent-card.json und einen JSON-RPC 2.0-Endpunkt in /wp-json/wc-redsys-a2a/v1/rpc mit sieben Fähigkeiten: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card und recurrent_charge. Die Authentifizierung verwendet den OAuth 2.1 + PKCE-Autorisierungsserver von UCP mit Scopes a2a:payments:* (und einem optionalen Sandbox-Bearer für Tests unter WP_DEBUG).
- Wiederherstellbarer Stream von Server-Sent Events unter /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream für Live-Task-Updates, mit Wiederherstellung über Last-Event-ID und Heartbeats alle 15s.
- Ausgehende Push-Benachrichtigungen, die an eine vom Kunden registrierte push_url signiert werden. Header X-A2A-Signature: sha256=<hmac> über <timestamp>.<body>, mit Wiederholungen nach 1m/5m/30m/2h (maximal 4), geliefert über Action Scheduler.
- Neue Verwaltungsregisterkarte "A2A (Agent2Agent)" innerhalb von Redsys Erweitert -> Agentic Commerce, mit Status / Kunden (erstellen / widerrufen / Sandbox-Bearer rotieren) / Limits und Modi (max_amount, sensitive_threshold und exponierte Zahlungsmethoden) / Bestätigungen (Genehmigung von Rückerstattungen oder gestoppten wiederkehrenden Gebühren in input-required).
- Limits pro Fähigkeit: max_amount ist ein striktes Höchstlimit, das die Aufgabe mit limit_exceeded fehlschlagen lässt; sensitive_threshold stoppt die Aufgabe in input-required, bis ein Administrator sie bestätigt. Beide ohne Standardlimit (optional).
- Append-only-Audit-Log in wp_redsys_a2a_audit_log. Payloads werden niemals im Rohformat gespeichert: nur ein SHA-256-Hash und eine bereinigte einzeilige Zusammenfassung, die PAN, Tokens, Geheimnisse und den lokalen Teil der E-Mails maskiert.
- Selbstreparierender Speicher. Die vier A2A-Tabellen werden bei Bedarf über das ensure_table() jeder Store neu erstellt, sodass eine gelöschte Tabelle niemals einen fatalen Fehler verursacht.
- Unterstützung für KI-Einkaufsagenten (ChatGPT, Claude, Gemini, Perplexity und andere). KI-Agenten können jetzt deine Produkte entdecken, Warenkörbe erstellen, Zahlungen abschließen und Bestellupdates aus deinem Shop erhalten. Sowohl der ACP-Standard von OpenAI/Stripe als auch der offene UCP-Standard (unterstützt von Google, Shopify und anderen) werden unterstützt, und jeder kann unabhängig aktiviert oder deaktiviert werden.
- Neue Untersektion "Agentic Commerce" innerhalb der Einstellungen von Redsys Erweitert, mit Schaltern nach Funktion (Warenkörbe, Rabatte, Fulfillment, Käuferzustimmung, dynamische Kundenregistrierung usw.) und Ein-Klick-Buttons zum Testen der Agentenentdeckungsflüsse, OAuth und Webhook.
- Webhook-Signatur mit einem Button "Signaturschlüssel rotieren". Die rotierten Schlüssel bleiben 7 Tage lang gültig, damit bestehende Integrationen während des Wechsels weiterhin funktionieren.
- Das Modal für benutzerdefinierte Felder von Express (Apple Pay / Google Pay) erfasst jetzt auch die über die Blocks-API registrierten Felder in klassischen Checkouts, sodass NIF/DNI und ähnliche Felder unabhängig vom verwendeten Checkout immer angezeigt werden.
- Optionale Massenaktion "Genehmigung der Vorautorisierung" für die Bestellliste (Redsys-Weiterleitung). Standardmäßig aus Sicherheitsgründen deaktiviert; aktiviere sie in den Einstellungen der Gateway nur, wenn du vorautorisierte Bestellungen in großen Mengen bestätigen musst.
Hinweis:
- Die Aktivierung dieser Unterstützung bedeutet NICHT, dass KI-Assistenten ab dem ersten Tag beginnen werden, Einkäufe in deinem Shop abzuschließen. Der vollständige Checkout-Fluss, der von Agenten gesteuert wird, wird noch ausgerollt, insbesondere in Europa, wo die Anforderungen an SCA/3DS, PSD2 und RGPD-Zustimmung dazu führen, dass die meisten Agenten heute beim Entdecken von Produkten oder im Vor-Warenkorb stoppen und die endgültige Zahlung an den Kunden zurückgeben. Dein Shop ist bereit für den Tag, an dem jeder Agent den vollständigen Fluss in deinem Markt aktiviert.
Aktualisiert:
- Das Modal für benutzerdefinierte Felder von Express lädt jetzt seine Konfiguration beim Laden der Seite vor und startet Apple Pay synchron beim Klicken, wodurch die Fälle behoben werden, in denen iOS Safari das Zahlungsblatt abbrach.
- Die benutzerdefinierten Felder von Express auf der Produktseite verwenden wieder das Standardmodal. Das Online-Formular, das in 30.4.1 eingeführt wurde, ist jetzt optional über einen Filter.
Behoben:
- [Kritisch] Die Verlängerungen von Abonnements konnten mit dem Fehler Redsys SIS0502 ("Id Oper stimmt nicht überein") auf Hosting-Diensten mit Redis, Memcached oder anderen persistenten Objekt-Caches fehlschlagen. Zwei parallele Verlängerungs-Worker konnten zwei unterschiedliche Bestellreferenzen an Redsys für dasselbe Abonnement senden, was dazu führte, dass die Verlängerung fehlschlug und viele Male wiederholt wurde. Die doppelte Zahlungsblockierung und die Bestellreferenz werden jetzt unabhängig vom Cache-Backend zuverlässig gespeichert. Betrifft die Redsys-Weiterleitungs- und InSite-Gateways.
- Die Verlängerungen von InSite-Abonnements hatten keinen Schutz gegen Konkurrenz (die Sperre wurde bei Fehlern entfernt, aber nie erstellt). Jetzt gilt für die Verlängerungen von InSite derselbe Schutz wie für das Weiterleitungsgateway.
- Der intern zwischengespeicherte Status, der während des Checkouts verwendet wird (3DS-Daten, gespeicherte Karten-ID, Signatur-Cache, OAuth-Status, temporärer IMAP-Status usw.), wird jetzt so gespeichert, dass er in Hosting-Diensten mit persistenten Objekt-Caches korrekt funktioniert. Zuvor konnte dieser Status in schlecht funktionierenden Caches während des Checkouts stillschweigend verschwinden und Fehler SIS0502 verursachen.
- Die Express-Buttons von Apple Pay und Google Pay (Block-Checkout und Produktseite) schlugen in iOS Safari mit "Must create a new ApplePaySession from a user gesture handler" fehl, wenn das Modal für benutzerdefinierte Felder von Express aktiviert war. Das Modal verbraucht jetzt nicht mehr den Klick des Benutzers, bevor Apple Pay gestartet wird.
- Die IRPF von Premium-Selbständigen wurde im Express-Zahlung (Apple Pay / Google Pay) auf der Produktseite falsch berechnet, als der Kunde den Benutzertyp im Express-Modal auswählte, da das Speichern des Modals mit dem ersten Serveraufruf von Apple Pay konkurrierte. Der Benutzertyp wird jetzt zusammen mit jeder Anfrage von Express Pay gesendet, sodass die Gesamtbeträge immer korrekt sind.
- Auf Produktseiten mit virtuellen Produkten zeigte das Apple Pay-Blatt kurz den korrekten Gesamtbetrag (Zwischensumme + Steuern) und kehrte dann zum Preis des Produkts ohne Steuern zurück. Der Versand-Callback hält jetzt den letzten Gesamtbetrag, der vom Server zurückgegeben wurde.
- Beim Speichern der Einstellungen von Agentic Commerce wurde das "Änderungen speichern"-Versenden von WooCommerce stillschweigend verworfen, aufgrund von geschachtelten HTML-Formularen. Die Einstellungsseite wurde umstrukturiert und alle Ein-Klick-Aktionen (Agentenentdeckung testen, OAuth testen, Webhook-Aktionen usw.) funktionieren jetzt korrekt zusammen mit dem Hauptspeicher-Button.
- Die Express-Buttons von Apple Pay und Google Pay auf der Produktseite wiesen die falsche Versandzone zu, wenn die Region des Kunden nach Provinz eingeschränkt war. Apple/Google Pay sendet den lokalisierten Namen des Bundesstaates (z. B. "Barcelona") in administrativeArea, aber die Versandzonen von WooCommerce stimmen nach Bundesstaat-Code (z. B. "B"); die landesweite Zone nach Bundesstaat stimmte nicht überein und der Warenkorb fiel in eine teurere Zone (z. B. "Rest von Europa"). Die Bundesstaatnamen werden jetzt vor der Suche nach Versandzonen und der Erstellung der Bestellung auf WooCommerce-Bundesstaatcodes normalisiert.
- Der InSite-Checkout mit Blöcken konnte doppelte Bestellungen erstellen, wenn Redsys das gleiche postMessage von Zahlungstoken mehr als einmal ausgab (oder wenn das Speichern gleichzeitig ausgeführt wurde). Jetzt verhindert ein Schutz die Erstellung von doppelten/konkurrenten Bestellungen und wird zurückgesetzt, wenn das Zahlungsformular nach einem Fehler aktualisiert wird.
- Das REST-Debug-Protokoll von InSite verwies auf das falsche Objekt, um das Debug-Flag zu lesen, sodass das Payload "REST behandelt Anfrage" unabhängig von der Debug-Einstellung des Gateways protokolliert (oder übersprungen) werden konnte. Jetzt verwendet es das eigene Debug-Flag des Gateways.
31.0.1
Aktualisiert:
- Der Countdown des Bizum-Modals auf der Zahlungsseite zeigte 7 Minuten an. Jetzt zeigt es korrekt 5 Minuten an, und die serverseitige Zeitkontrolle, die zum Checkout umleitet, wurde entsprechend angepasst (60 Iterationen * 5 Sekunden = 5 Minuten).
Behoben:
- Bizum auf der Zahlungsseite (Bizum InSite) sendete die Beschreibung nicht an Redsys. Die tatsächliche Belastung über das Modal erfolgt über die REST-API (trataPeticionREST), und diese Anfrage enthielt nicht den Parameter DS_MERCHANT_PRODUCTDESCRIPTION, sodass die konfigurierte "Redsys-Beschreibung" (zum Beispiel "Bestell-ID") leer im Redsys-Panel ankam. Die Beschreibung wird jetzt basierend auf der ausgewählten Einstellung berechnet und in der REST-Anfrage gesendet.
31.0.2
Sicherheit:
- Der SHA-256-Geheimschlüssel des Händlers wird nicht mehr im Klartext in den Debug-Protokollen von WooCommerce geschrieben. Alle Debug-Einträge maskieren jetzt den Schlüssel und zeigen nur die letzten 4 Zeichen an, mithilfe des neuen Hilfsprogramms WCRed()->mask_secret(). Angewendet auf alle Zahlungs-Gateways (Weiterleitung, InSite, Bizum, Google Pay, Apple Pay, PayGold, Bankeinzug und die unterstützenden Klassen von Blocks).
- Die Signaturen der Benachrichtigungen (IPN) von Redsys werden jetzt mit hash_equals() (zeitkonstante Vergleich) in allen Benachrichtigungs-Handlern überprüft, wodurch sie mit der Überprüfung vereinheitlicht werden, die bereits von InSite und dem REST-Client verwendet wurde. Härtung gegen Timing-Angriffe.
- Der AJAX-Handler zum Löschen eines einzelnen Tokens auf dem Token-Management-Bildschirm erfordert jetzt die Fähigkeit manage_woocommerce zusätzlich zum nonce, wodurch er dem Handler für das Massenlöschen entspricht.
Aktualisiert:
- Der Filter redsys_modify_data_to_send erhält jetzt 'context' => 'add_payment_method' und 'user_id' im Datenarray für den "Zahlungsmethode hinzufügen"-Flow, sodass benutzerdefinierte Snippets und bedingte Regeln die Tokenisierung an das richtige Terminal (Terminal + SHA256) weiterleiten können, ohne von einer Bestellung abhängig zu sein, die in diesem Flow nicht existiert.
- Alle Übersetzungen aktualisiert.
Behoben:
- Das Hinzufügen einer Karte von Mein Konto ("Zahlungsmethode hinzufügen") in Multicurrency-Shops konnte von Redsys mit einem Währungsfehler abgelehnt werden. Die Anfrage wurde mit der Währung der Kundensitzung (zum Beispiel ARS, 32) gesendet, jedoch mit dem Standardterminal, das für eine andere Währung (zum Beispiel EUR, 978) konfiguriert ist. Die Kartentokenisierung ist eine Nullbetragsoperation ohne eine Bestellung im Hintergrund, sodass, wenn kein Filter oder keine bedingte Regel die Anfrage an ein anderes Terminal weiterleitet, jetzt die Basiswährung des Shops gesendet wird, die immer mit der Konfiguration des Standardterminals übereinstimmt.
- Das Hinzufügen einer Karte von Mein Konto (oder über den E-Mail-Link im Profil) registrierte die Karte immer als One-Click in Redsys (DS_MERCHANT_COF_TYPE 'C'), selbst wenn der Kunde die Abonnementoption auswählte. Der Token-Typ wurde von dem falschen internen Schlüssel gelesen, sodass 'R' nie gesendet wurde. Der Token wurde korrekt als R in WooCommerce gespeichert, aber das COF-Abkommen wurde als C in Redsys erstellt, was dazu führen konnte, dass einige Emittenten spätere Abonnementverlängerungen (MIT) mit diesen Tokens ablehnten. Karten, die mit der Abonnementoption hinzugefügt wurden, senden jetzt korrekt DS_MERCHANT_COF_TYPE 'R'. Die während des Fehlers erstellten Tokens können nicht umklassifiziert werden; wenn eine Verlängerung abgelehnt wird, wird der Kunde aufgefordert, die Karte erneut hinzuzufügen.
- Zahlungen, die mit einer gespeicherten Karte (Token R) und Abonnementverlängerungen durchgeführt wurden, respektierten nicht die Einstellungen zur Vorautorisierung. Mit "Alle Bestellungen vorautorisieren" aktiviert (oder einem Produkt, das zur Vorautorisierung markiert ist), wurde die Belastung als normale Verkaufstransaktion (Typ 0) ausgeführt, aber die Bestellung wurde dennoch als "Vorautorisierte" markiert, sodass die spätere Bestätigung der Vorautorisierung in Redsys mit SIS0059 fehlschlug ("Es gibt keine Operation, die bestätigt werden kann"). Beide Flows senden jetzt eine echte Vorautorisierung vom Typ 1, die später bestätigt werden kann, und eine Bestellung wird nur dann als "Vorautorisierte" markiert, wenn eine echte Vorautorisierung durchgeführt wurde. Dies ermöglicht auch vorautorisierte Abonnementverlängerungen (zum Beispiel Waren, die nach Gewicht verkauft werden, bei denen jede Verlängerung vor der endgültigen Belastung angepasst wird).
31.0.3
Neu:
- Abschnitt "Apps und Plugins" innerhalb von Redsys Erweitert -> Erweiterte Einstellungen von Redsys. Eine schreibgeschützte Landingpage, die die native Verwaltungs-App für macOS (mit Download, Anforderungen und Plattformen "demnächst") anzeigt und die restlichen kostenlosen und Premium-Plugins, Websites und Portale, Claude-Fähigkeiten und Entwicklerprofile von José Conti auflistet, jeweils nach Typ gruppiert mit einem Link. Jede Liste ist filterbar (redsys_apps_plugins_mac_app, redsys_apps_plugins_free, redsys_apps_plugins_premium, redsys_apps_plugins_webs, redsys_apps_plugins_skills, redsys_apps_plugins_profiles).
Sicherheit:
- Ein Umgehungscode zur Überprüfung der Benachrichtigungssignatur wurde entfernt, der es einer anonymen Anfrage ermöglichen konnte, eine Bestellung als bezahlt zu markieren, wenn der SHA-256-Geheimschlüssel leer oder falsch konfiguriert war. Der IPN-Listener von Redsys (öffentlicher Endpunkt wc-api) hatte ein veraltetes Fallback, das, wenn kein geheimer Schlüssel konfiguriert war, eine Benachrichtigung nur akzeptierte, weil der gesendete Ds_MerchantCode mit dem FUC des Händlers übereinstimmte, einem öffentlichen und nicht geheimen Wert, den ein Angreifer bereitstellen kann. Diese Akzeptanz, die nur auf dem Händlerschlüssel basierte, wurde aus allen Gateways entfernt (Weiterleitung, Bizum, Bizum InSite, Google Pay-Checkout und -Weiterleitung, Apple Pay, PayGold, Bankeinzug, MasterPass und Banküberweisung): Wenn kein geheimer Schlüssel zur Überprüfung des HMAC vorhanden ist, schlägt die Anfrage jetzt sicher fehl (HTTP-Ablehnung), anstatt vertraut zu werden. Darüber hinaus gibt die gemeinsame Überprüfungsroutine (WooRedsysAPI::verify_signature_notif) jetzt false zurück, wenn der Händlerschlüssel oder die empfangene Signatur leer sind, sodass weder check_ipn_request_is_valid() noch successful_request() eine Zahlung mit einem berechnbaren HMAC eines leeren Schlüssels des Angreifers abschließen können. InSite erforderte bereits eine gültige Signatur (ohne Fallback durch den Händlerschlüssel) und Inespay ist nicht betroffen (verknüpft die Bestellungen über ihre eigene payin-ID). Echte Geschäfte sind nicht betroffen, da das Konfigurieren eines geheimen Schlüssels obligatorisch ist, um Zahlungen zu akzeptieren.
Behoben:
- Die Benachrichtigungen von Bizum wurden mit einem Fehler bei der Signaturüberprüfung abgelehnt, wodurch die Bestellung unbezahlt blieb, obwohl die Zahlung in Redsys genehmigt worden war. Der Händlerschlüssel und die Bestellnummer waren korrekt (die Signatur der Anfrage stimmte perfekt überein), aber die Signatur der Benachrichtigung ist ein HMAC, der über die Ds_MerchantParameters-Zeichenfolge genau so berechnet wird, wie sie empfangen wird, und die Benachrichtigungen von Bizum kommen mit dem letzten Padding-Zeichen "=" von Base64 entfernt an, während Redsys über den Wert mit dem kanonischen Padding signiert, sodass das lokal berechnete HMAC niemals übereinstimmte. Die gemeinsame Benachrichtigungsroutine (create_merchant_signature_notif in WooRedsysAPI) füllt jetzt die Nutzlast wieder auf ein Vielfaches von vier auf, bevor sie gehasht wird, und die Überprüfung (verify_signature_notif) vergleicht jetzt beide Signaturen, wobei das letzte Padding-Zeichen "=" ignoriert wird (das keine Entropie beiträgt, sodass der Vergleich weiterhin zeitkonstant bleibt). Die Kartennutzlasten sind jetzt kanonisch und bleiben unverändert, sodass der Rest der Gateways ohne Änderungen funktioniert. Diese Routine wird von allen Benachrichtigungs-Handlern geteilt (Weiterleitung, Bizum, InSite, PayGold, Google Pay, Apple Pay, Bankeinzug, Banküberweisung und die REST/A2A-Clients).
- Die Benachrichtigungen von Karte und Wallet konnten mit einem "signature mismatch" abgelehnt werden, sodass der Kunde, der zur Dankesseite zurückkehrte (und der IPN-Server zu Server), die Bestellung nicht als bezahlt markieren konnte, bis ein späterer IPN-Versuch zufällig erfolgreich war; Rückerstattungen und später bezahlte PayGold-Links konnten unbestätigt bleiben. Es gibt zwei Padding-Probleme: Neben dem Padding der vorherigen Bizum-Nutzlast liefert Redsys die Signatur der Benachrichtigung (Ds_Signature) in Base64 URL-sicher mit dem letzten "=" entfernt, während die lokal berechnete Signatur dies beibehält, sodass ein strenger Vergleich auch für normale Kartenzahlungen fehlschlägt. Der padding-tolerante Vergleich lebt in verify_signature_notif(), aber die meisten Handler verglichen weiterhin die Signatur in einer strengen hash_equals()/!==-Überprüfung, die die Empfindlichkeit wieder einführte. Jetzt delegieren alle Handler an verify_signature_notif(), sodass die Korrektur alle erreicht: Kartenzahlungsweiterleitung (sowohl IPN-Validatoren als auch REST-SOAP-Antwortprüfungen für Erfassung/Rückerstattung), Bizum, Bizum InSite, InSite (IPN, successful_request und die beiden REST-Antwort-Validatoren), PayGold, Google Pay (Checkout und Weiterleitung), Apple Pay, Bankeinzug, Banküberweisung, MasterPass und der REST-Client von InSite. Regression eingeführt, als die Signaturprüfungen pro Gateway in verify_signature_notif() mit einem strengen und padding-sensiblen Vergleich vereinheitlicht wurden.
- Die Benachrichtigungen von Bizum in Multicurrency-/Dual-Terminal-Shops (die jede Bestellung an ein anderes Terminal weiterleiten, indem sie den Filter bizum_modify_data_to_send oder eine bedingte Regel verwenden) lösen jetzt den tatsächlichen Signaturschlüssel pro Bestellung auf, bevor sie die Signatur überprüfen (den Schlüssel der Einstellungen, der vom Kunden angepasst wurde, den transienten Wert, der beim Generieren des Zahlungsformulars gespeichert wurde, oder den Bestellmeta _redsys_secretsha256), und eine nicht überprüfbare Benachrichtigung wird mit HTTP 400 abgelehnt.
- Die InSite-Kartenzahlungen, die eine 3DS-Herausforderung erforderten, zeigten einen leeren Bestätigungsbildschirm in Safari (iPhone/Mac), sodass der Kunde den SMS/PIN-Code nicht eingeben konnte und die Zahlung fehlschlug (der gleiche Ablauf funktionierte in Chrome). Die Herausforderung selbst war bereits eine vollständige und hochrangige Seitennavigation, aber davor leitete das Plugin den Browser zur URL der 3DS-Methode des Emittenten (threeDSMethodURL) um, um den Fingerabdruck des Browsers zu erfassen, und die intelligente Nachverfolgungsprävention (ITP) von Safari blockiert die Drittanbieter-Cookies, die dieser Schritt benötigt, was zu einer leeren ACS-Seite führte (Symptom: die ACS-URL kommt mit ";jsessionidpa=" an, weil die Cookies nicht fließen). Der Schritt der 3DS-Methode im Browser ist optional, daher leitet das Plugin den Browser nicht mehr zu threeDSMethodURL um: es sendet immer threeDSCompInd = 'N' und fährt direkt mit der Authentifizierung fort. Anwendbar auf alle InSite-Abläufe – neue Karte und gespeicherte Karte (One-Click/Token), sowohl im Block-Checkout als auch im klassischen (Shortcode) – und auf die REST/Token-Abläufe des Redirect-Gateways (pay_with_token_c, receipt_page und successful_request), da derselbe leere Bildschirm beim Einlösen eines Tokens einer gespeicherten Karte erscheinen konnte.
- Wenn eine InSite-Kartenzahlung fehlschlug, weil ein Pflichtfeld im Checkout fehlte oder die Daten nicht übereinstimmten (zum Beispiel führte ein leerer Nachname zu einem "Signature Mismatch"), gab die Fehlermeldung der Karte die Schuld ("…Bitte geben Sie Ihre Kartendaten erneut ein"), sodass die Kunden dachten, ihre Karte sei abgelehnt worden und die Bestellung abbrachen. Die Nachricht ist jetzt neutral und weist zuerst auf die Checkout-Felder hin: Sie fordert den Kunden auf, sicherzustellen, dass alle Checkout-Felder (Vorname, Nachname, Adresse usw.) und die Kartendaten korrekt ausgefüllt sind, bevor er es erneut versucht. Anwendbar auf die klassischen und Block-Checkouts (Blocks).
- Rückerstattungen und verzögerte Zahlungen für Bestellungen mit großen Bestell-IDs (der bereits behobene "Milliarden-Bug" für den Sofort-Checkout) wurden fälschlicherweise gegen die falsche Bestellung registriert oder gar nicht registriert. Die Benachrichtigung (IPN) von Redsys ruft die WooCommerce-Bestell-ID aus der Bestellnummer über clean_order_number() ab, die zuerst nach einem gespeicherten Transienten sucht, als die Bestellnummer generiert wurde, und im Falle eines Fehlens auf eine substr/ltrim-Heuristik zurückgreift, die die hohen Ziffern von IDs mit 10 oder mehr Ziffern verwirft. Dieser Transient hat eine TTL von 1 Stunde, sodass der Fallback immer aktiviert wurde, wenn die Benachrichtigung mehr als eine Stunde nach der Generierung der Bestellnummer eintraf: jede Rückerstattung (die Tage oder Wochen später verarbeitet wurde) und die Zahlungslinks von PayGold (die vom Kunden später bezahlt wurden), unter anderem. Drei Änderungen machen es robust für alle Zahlungsmethoden: (1) Die gemeinsame Rückerstattungsroutine (ask_for_refund) speichert jetzt das Mapping Bestellnummer -> tatsächliche Bestell-ID zum Zeitpunkt der Rückerstattung mit einer TTL von 24 Stunden; (2) clean_order_number(), wenn der Transient nicht mehr existiert, sucht jetzt umgekehrt nach der Bestellung anhand des persistierten Metas der Bestellnummer (_payment_order_number_redsys / _redsys_transaction_id2), bevor sie jemals die heuristische Verlustheuristik verwendet; und (3) PayGold speichert jetzt die Bestellnummer im Meta, wenn der Link erstellt wird, sodass ein viel später bezahlter Link weiterhin zur genauen Bestellung aufgelöst wird. Gilt für alle Gateways (Redirect, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold und Bankeinzug). Inespay ist nicht betroffen (verknüpft die Bestellungen über ihre eigene payin-ID).
- Die InSite-Kartenzahlungen im Block-Checkout (Blocks) schlugen beim ERSTEN Versuch mit "msg18" fehl (der Kunde sah "Bitte überprüfen Sie, ob die Checkout/Kartendaten ausgefüllt sind") und funktionierten nur beim zweiten Versuch. Das InSite-SDK von Redsys erfordert, dass die Seite eine "domain"-Nachricht an das Karten-iFrame sendet, damit Redsys den Händler validieren kann; das SDK tut dies über ein onload="setMerchantDomain(0)" im iFrame. Das Block-Skript überschreibt diesen Handler mit seinem eigenen iFrame.onload (verwendet zum Dimensionieren des iFrames) direkt nach dem ersten Rendering, sodass die Händlerdomain niemals gesendet wurde und Redsys die Tokenisierung mit msg18 ablehnte ("Ungültige Händlervalidierung"). Bei der automatischen Aktualisierung des Formulars wurde die Überschreibung nicht ausgeführt, sodass der zweite Versuch funktionierte. Das Plugin ruft jetzt setMerchantDomain explizit auf, nachdem das Formular erstellt wurde (wie es die eigene Integration des SDK-Zahlungsbuttons tut) und überschreibt nicht mehr das onload des iFrames, sodass der erste Versuch funktioniert.
- InSite Block-Checkout: Das Handling des postMessage von Redsys wurde robuster gestaltet und End-to-End-Diagnosen wurden hinzugefügt. Der Handler akzeptiert jetzt Nachrichten von jeder Redsys-Subdomain (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es), anstatt eine exakte Übereinstimmung von Host/Port zu verlangen (Redsys veröffentlicht von mehr als einem Host), entfernt jeden Listener, der von einem vorherigen Rendering hinterlassen wurde, damit ein einzelnes Token nicht mehrere Sendungen auslösen kann, und bereinigt die Token-/Fehlerfelder nach dem Lesen, sodass ein veralteter Neuauslöser sie nicht erneut senden kann. Wenn das Debugging-Logging von InSite aktiviert ist, wird der gesamte Tokenisierungsprozess auf der Client-Seite (Bestellnummer, postMessage von Redsys, Token/Fehlercode, Speicherung und Bestellung aufgeben) im "insite"-Log von WooCommerce protokolliert, sodass Fehler beim ersten Versuch, die niemals PHP erreichen, diagnostiziert werden können.
- Die InSite-Kartenzahlungen im Block-Checkout (Blocks) wurden von Redsys mit SIS0574 abgelehnt ("EMV3DS-Authentifizierungsoperation abgelehnt, browserUserAgent nicht angegeben"): Der 3DS-Fingerabdruck des Browsers (User-Agent, Bildschirmgröße, Sprache, Farbtiefe, Zeitzone) kam niemals zur Bestellung, da der Hook, der ihn normalerweise zur Bestellung kopiert (woocommerce_checkout_create_order), im Store-API-Checkout (Blocks) nicht ausgeführt wird. Das InSite-Formular von Blocks erfasst jetzt den Fingerabdruck und sendet ihn zusammen mit dem Transaktions-Token, und er wird in die tatsächliche Bestellung (neben dem Token) geschrieben, bevor process_payment ausgeführt wird, sodass die EMV3DS-Authentifizierung die benötigten Daten hat.
- Die InSite-Kartenzahlungen im Block-Checkout (Blocks) wurden mit einem "Tokenlosen Fehlercode" abgelehnt (dem Kunden angezeigt als "Bitte überprüfen Sie, ob die Checkout/Kartendaten ausgefüllt sind"), sodass die Karte nach mehreren Versuchen nicht einmal tokenisiert werden konnte. Da die Bestellung im Block-Checkout (Bestell-ID 0) noch nicht existiert, wurde die vorbereitete Redsys-Bestellnummer aus der ID 0 generiert, was einen nahezu konstanten Wert erzeugte – nur ~999 mögliche Nummern, die alle mit neun Nullen endeten – und Redsys lehnt eine wiederverwendete Bestellnummer ab ("Wiederholte Bestellung", SIS0051). Wenn die ID der Entwurfbestellung noch nicht verfügbar ist, verwendet das InSite-Formular von Blocks jetzt dieselbe temporäre Bestellnummer wie der InSite-Checkout-Shortcode (create_checkout_insite_number: beginnt immer mit 1, global eindeutig durch einen gemeinsamen inkrementellen Zähler), sodass es niemals zu Kollisionen kommt; wenn die ID der Entwurfbestellung verfügbar ist, wird die Redsys-Nummer aus ihr erstellt. Die Nummer wird wieder mit der tatsächlichen Bestell-ID verknüpft, wenn die Bestellung aufgegeben wird.
- Die InSite-Kartenzahlungen im Block-Checkout (Blocks) schlugen fehl: Der Kunde sah eine irreführende Nachricht "Bitte überprüfen Sie, ob die Checkout/Kartendaten ausgefüllt sind" und die Bestellung wurde niemals bezahlt (die Konsole des Browsers zeigte einen 404 bei der Anfrage save_order_data). Der Grund dafür ist, dass WooCommerce die Bestellung nicht mehr erstellt, bis der Kunde auf "Bestellung aufgeben" klickt – während der Eingabe der Kartendaten gibt der Store des Block-Checkouts die Bestell-ID 0 zurück – sodass der InSite-Transaktions-Token (idOper) und die vorbereitete Redsys-Bestellnummer nicht persistiert werden konnten: Der vorherige Ablauf sendete sie an einen REST-Pfad (save_order_data), der versuchte, sie der Bestellung 0 anzuhängen und "Ungültige Bestellung" (404) zurückgab, und die generierte Bestellnummer wurde der Bestellung 0 zugeordnet (sodass nicht einmal eine spätere Benachrichtigung die Bestellung finden konnte). Jetzt, wenn die Karte tokenisiert wird, werden der Token und die vorbereitete Bestellnummer in der WooCommerce-Sitzung über admin-ajax gespeichert (die WC-Sitzung ist in benutzerdefinierten REST-Pfaden nicht verfügbar, weshalb der vorherige REST-Ansatz sie nicht verwenden konnte) und in die tatsächliche Bestellung übertragen, während WooCommerce sie aus der Anfrage des Checkouts erstellt (woocommerce_store_api_checkout_update_order_from_request), bevor process_payment ausgeführt wird, sodass process_payment_block() _insite_token und _payment_order_number_redsys wie im klassischen Checkout findet. Der Transient der Bestellnummer wird auch wieder mit der tatsächlichen Bestell-ID verknüpft, damit die Benachrichtigung (IPN) die Bestellung auflöst. Die Browserfingerabdruckdaten (3DS) verwendeten bereits denselben Sitzungsweg. Der klassische/Shortcode-Checkout ist nicht betroffen.
Entwicklung:
- Die laute Debug-Ausgabe console.log aus den Produktions-Frontend-Skripten (minifiziert) wurde entfernt: Apple Pay, Google Pay, capture-order-id und die Modalitäten des Express-Checkouts. Das Skript von Apple Pay Express protokollierte insbesondere bei jeder DOM-Änderung (überwacht das gesamte Dokument nach seinem Button), was die Konsole des Browsers im Block-Checkout überflutete. Die minifizierten Dateien entfernen jetzt console.log/console.warn/console.info/console.debug und behalten console.error bei; die unminifizierten Quellen bleiben unverändert für die Entwicklung.
31.0.4
Behoben:
- Die Abonnementsverlängerungen (mit jedem Abonnement-Plugin) respektieren jetzt den konfigurierten Bestellnummerntyp von Redsys und schlagen nicht mehr beim erneuten Versuch mit "doppelte Bestellnummer" (SIS0051) fehl. Zwei Probleme wurden behoben.
- Das erste: Die Verlängerungsgebühr erzeugte die Bestellnummer von Redsys, indem sie die Einstellung "Bestellnummerntyp" (redsysordertype/subfix) ignorierte; sie griff immer auf das standardmäßige Zufallschema zurück, anstatt den für das Gateway konfigurierten Typ zu verwenden, im Gegensatz zur ursprünglichen Zahlung beim Checkout. Jetzt wird das Gateway so übergeben, dass die Verlängerungen denselben Bestellnummerntyp wie der Checkout respektieren.
- Das zweite: Die Bestellnummer wurde während der gesamten Lebensdauer der Bestellung beibehalten, sodass, wenn eine Verlängerungsgebühr abgelehnt wurde und das Abonnement-Plugin es erneut über dieselbe Verlängerungsbestellung versuchte, genau dieselbe DS_MERCHANT_ORDER erneut gesendet wurde und Redsys den legitimen erneuten Versuch als Duplikat blockierte. Jetzt ist die Unterscheidung zwischen "Flow" und "erneutem Versuch" explizit: Ein einzelner Zahlungsfluss (sein Paar iniciaPeticion/trataPeticion, die gleichzeitigen Verlängerungsprozesse und jede erneute Ausführung über den Action Scheduler eines Prozesses, der während der Gebühr gestorben ist) behält dieselbe Bestellnummer bei, um Id Opers (SIS0502) nicht zu kreuzen und idempotent gegenüber doppelten Gebühren zu sein; aber sobald Redsys eine Ablehnung bestätigt (eine signierte Antwort ohne Autorisierungscode, d.h. ohne Geldbewegung), wird die Nummer freigegeben, damit der nächste erneute Versuch eine neue und einzigartige Nummer generiert, die den konfigurierten Typ respektiert. Der Neustart erfolgt NUR bei einer bestätigten Ablehnung, niemals bei Transportfehlern oder Zeitüberschreitungen, bei denen das Ergebnis unbekannt ist, sodass eine erneute Ausführung aufgrund einer verlorenen Antwort niemals die Gebühr duplizieren kann.
- Es gilt für die Weiterleitungs- und InSite-Gateways und für alle Abonnement-Plugins, die sie verwenden (WooCommerce Subscriptions, Subscriptions for WooCommerce, YITH, WebToffee, SUMO, Advanced Subscriptions; Google Pay und Apple Pay delegieren an das Weiterleitungsgateway).
- Als Sicherheitsnetz, wenn kein gültiger Bestellnummerntyp konfiguriert ist (leer oder ein geerbter oder nicht erkannter Wert), greift der Generator IMMER auf das Standard-Schema "3 zufällige Ziffern + Nullen + Bestell-ID" zurück, das einzige, das bei den erneuten Versuchen niemals kollidiert. Hinweis: Der Typ "einfache Bestellnummer" hat keine zufällige Komponente, weshalb er aus Designgründen mit den erneuten Versuchen von Abonnements inkompatibel ist und nicht verwendet werden sollte, wenn aktive Abonnements vorhanden sind.
