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 alle 1m/5m/30m/2h (maximal 4), geliefert über Action Scheduler.
- Neue Verwaltungsregisterkarte "A2A (Agent2Agent)" innerhalb von Redsys Advanced -> Agentic Commerce, mit Status / Kunden (erstellen / widerrufen / rotieren von Sandbox-Bearers) / Limits und Modi (max_amount, sensitive_threshold und exponierte Zahlungsmethoden) / Bestätigungen (Genehmigung von Rückerstattungen oder gestoppten wiederkehrenden Zahlungen 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 haben standardmäßig kein Limit (optional).
- Append-only-Audit-Log in wp_redsys_a2a_audit_log. Rohpayloads werden niemals gespeichert: nur ein SHA-256-Hash und eine bereinigte Zusammenfassung in einer Zeile, die PAN, Tokens, Geheimnisse und den lokalen Teil der E-Mails maskiert.
- Selbstreparierender Speicher. Die vier A2A-Tabellen werden bei Bedarf über ensure_table() jedes Stores 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 Advanced, mit Schaltern nach Funktion (Warenkörbe, Rabatte, Fulfillment, Zustimmung des Käufers, dynamische Kundenregistrierung usw.) und Ein-Klick-Buttons zum Testen der Agentenentdeckungsflüsse, OAuth und Webhook.
- Webhook-Signatur mit einem Button "Schlü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 immer unabhängig vom verwendeten Checkout angezeigt werden.
- Optionale Massenaktion "Genehmigung der Vorautorisierung" für die Bestellliste (Redsys-Weiterleitung). Standardmäßig aus Sicherheitsgründen deaktiviert; aktiviere sie in den Einstellungen des Gateways, 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 bei der Produktentdeckung oder dem Pre-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 korrigiert 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-Anbietern 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 zuverlässig unabhängig vom Cache-Backend gespeichert. Betrifft die Redsys-Weiterleitungs- und InSite-Gateways.
- Die InSite-Abonnementverlängerungen hatten keinen Schutz gegen Parallelität (die Sperre wurde bei Fehlern entfernt, aber niemals erstellt). Jetzt gilt für die InSite-Verlängerungen derselbe Schutz, der im Weiterleitungs-Gateway verwendet wird.
- 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 korrekt auf Hosting-Anbietern mit persistenten Objekt-Caches 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 beim Express-Zahlung (Apple Pay / Google Pay) auf der Produktseite falsch berechnet, wenn 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 Gesamtsummen immer korrekt sind.
- Auf Produktseiten mit virtuellen Produkten zeigte das Apple Pay-Blatt kurz den korrekten Gesamtbetrag (Zwischensumme + Steuern) und wechselte dann zurück zum Preis des Produkts ohne Steuern. Der Versand-Callback hält jetzt den letzten vom Server zurückgegebenen Gesamtbetrag.
- Beim Speichern der Einstellungen von Agentic Commerce wurde die "Änderungen speichern"-Übermittlung 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") überein; die länderspezifische Zone stimmte nicht überein und der Warenkorb fiel in eine teurere Zone (z. B. "Rest von Europa"). Die Bundesstaat-Namen werden jetzt vor der Suche nach der Versandzone und der Erstellung der Bestellung auf WooCommerce-Bundesstaat-Codes normalisiert.
- Der InSite-Checkout mit Blöcken konnte doppelte Bestellungen erstellen, wenn Redsys dieselbe postMessage von Zahlungstoken mehr als einmal ausgab (oder wenn das Speichern gleichzeitig ausgeführt wurde). Jetzt verhindert ein Schutz die Erstellung von doppelten/konkurrierenden Bestellungen und wird zurückgesetzt, wenn das Zahlungsformular nach einem Fehler aktualisiert wird.
- Der REST-Debugging-Handler von InSite verwies auf das falsche Objekt, um das Debugging-Flag zu lesen, sodass das Payload "REST trataPeticion" unabhängig von der Debugging-Einstellung des Gateways protokolliert (oder übersprungen) werden konnte. Jetzt verwendet es das eigene Debugging-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 vom Modal erfolgt über die REST-API (trataPeticionREST), und diese Anfrage enthielt nicht den Parameter DS_MERCHANT_PRODUCTDESCRIPTION, sodass die konfigurierte "Redsys-Beschreibung" (z. B. "Bestell-ID") leer im Redsys-Panel ankam. Die Beschreibung wird jetzt aus der ausgewählten Einstellung berechnet und in der REST-Anfrage gesendet.
31.0.2
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"-Fluss, sodass benutzerdefinierte Snippets und bedingte Regeln die Tokenisierung an das richtige Terminal (Terminal + SHA256) ohne Abhängigkeit von einer Bestellung, die in diesem Fluss nicht existiert, weiterleiten können.
- Alle Übersetzungen aktualisiert.
Behoben:
- Eine Karte von Mein Konto aus ("Zahlungsmethode hinzufügen") in Multicurrency-Shops konnte von Redsys mit einem Währungsfehler abgelehnt werden. Die Anfrage wurde mit der Währung der Kundensitzung (z. B. ARS, 32) gesendet, aber mit dem Standardterminal, das für eine andere Währung (z. B. EUR, 978) konfiguriert ist. Die Kartentokenisierung ist eine Nullbetrag-Operation ohne Bestellung dahinter, 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.
- Eine Karte von Mein Konto aus (oder über den Link in der Profil-E-Mail) wurde immer als One-Click (DS_MERCHANT_COF_TYPE 'C') in Redsys registriert, selbst wenn der Kunde die Abonnementoption auswählte. Der Token-Typ wurde von dem falschen internen Schlüssel gelesen, sodass 'R' niemals gesendet wurde. Der Token wurde korrekt als R in WooCommerce gespeichert, aber die COF-Vereinbarung wurde als C in Redsys erstellt, was dazu führen konnte, dass einige Emittenten später die Abonnementverlängerungen (MIT) mit diesen Tokens ablehnten. Die mit der Abonnementoption hinzugefügten Karten 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, bitte den Kunden, die Karte erneut hinzuzufügen.
- Zahlungen, die mit einer gespeicherten Karte (Token R) und Abonnementverlängerungen getätigt wurden, respektierten nicht die Vorautorisierungseinstellungen. Bei aktivierter "Alle Bestellungen vorautorisieren"-Option (oder einem Produkt, das für die Vorautorisierung markiert ist) wurde die Belastung als normale Verkaufstransaktion (Typ 0) ausgeführt, aber die Bestellung wurde dennoch als "Vorautorisiert" markiert, sodass die spätere Bestätigung der Vorautorisierung in Redsys mit SIS0059 ("Es gibt keine Operation, auf die die Bestätigung angewendet werden kann") fehlschlug. Beide Flüsse senden jetzt eine echte Vorautorisierung vom Typ 1, die später bestätigt werden kann, und eine Bestellung wird nur als "Vorautorisiert" markiert, wenn eine echte Vorautorisierung durchgeführt wurde. Dies ermöglicht auch vorautorisierte Abonnementverlängerungen (z. B. Produkte, die nach Gewicht verkauft werden, bei denen jede Verlängerung vor der endgültigen Belastung angepasst wird).
Sicherheit:
- Der geheime SHA-256-Schlüssel des Handels 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 Helpers WCRed()->mask_secret(). In allen Gateways angewendet (Weiterleitung, InSite, Bizum, Google Pay, Apple Pay, PayGold, Bankeinzug und die Supportklassen 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, um ihn mit dem Handler für das Massenlöschen abzugleichen.
