Die Entwicklung dieser Version hat 1.700 Euro gekostet. Die kumulierten Kosten für dieses Jahr betragen 5.234 Euro. Die kumulierten Kosten seit der ersten Version betragen 40.724 Euro, aber die Kosten für dich sind nur die Lizenz ab 79€.

Neue Version 2.0.0 des Moduls Redsys für PrestaShop Premium. Es ist eine Hauptversion: erweitert die Kompatibilität auf PrestaShop 1.7, 8 und 9 (PHP 7.4 oder höher) und verstärkt vor allem die Sicherheit der Zahlungsbestätigung.

Tabla de contenido

2.0.0

Neu:

Kompatibilität mit PrestaShop 1.7 (PHP 7.4+). Das Modul wird jetzt installiert und funktioniert in PrestaShop 1.7 unter PHP 7.4 oder höher, bleibt aber vollständig kompatibel mit PrestaShop 8 und 9 / PHP 8.x. Die Mindestanforderung für PHP wurde von 8.1 auf 7.4 im Installationsguard gesenkt, in ps_versions_compliancy (jetzt mindestens 1.7.0.0) und in composer.json. PHP 7.1, 7.2 und 7.3 sind nicht mehr kompatibel, da sie am Ende ihrer Lebensdauer sind; ein Shop 1.7.7.x, der diese Versionen noch verwendet, muss sein PHP auf 7.4 aktualisieren, bevor er installiert.

Verbessert:

Die spezifischen Sprachkonstrukte von PHP 8.0 wurden durch kompatible Äquivalente zu PHP 7.4 ersetzt, ohne dass sich das Verhalten ändert: alle Ausdrücke match() wurden umgewandelt in switch (8 Fälle), der Typ mixed wurde entfernt und im Docblock dokumentiert (4 Fälle) und die Unionstypen wurden aus den Methodensignaturen entfernt und in den Docblock verschoben (6 Fälle). Die modernen Funktionen von PHP 7.4 (Pfeilfunktionen, typisierte Eigenschaften, nullable Typen und strict_types) bleiben intakt.
Zahlungsfehler werden jetzt immer protokolliert. Ein neuer Helper, Ps_redsys_gateway::persistPaymentError(), speichert den spezifischen Grund für den Fehler als private Nachricht der Bestellung sowie einen Eintrag im erweiterten Protokoll, und die Fehlerpfade des IPN und der Bestätigung schreiben jetzt einen nicht irreführenden Grund (zum Beispiel „Genehmigungscode ohne Genehmigungscode; Zahlung NICHT bestätigt“ oder „Benachrichtigung ohne Ds_Response“). Kein Zahlungsfehler bleibt unbemerkt.

Sicherheit:

[Kritisch] Eine Bestellung konnte als BEZAHLT markiert werden, ohne dass eine verifizierte Genehmigung von Redsys vorlag. Die Goldene Regel „nie eine Bestellung als bezahlt markieren, es sei denn, Redsys hat die Zahlung tatsächlich genehmigt“ wird jetzt durch eine einzige Quelle der Wahrheit durchgesetzt, Ps_redsys_gateway::isRedsysPaymentAuthorised(), die verlangt, dass der Ds_Response vorhanden ist und strikt im Bereich [0,99] liegt und dass ein Ds_AuthorisationCode nicht leer ist. Dies schließt die Falle (int) null === 0 (ein fehlender Antwortcode wurde als 0 = Erfolg interpretiert) und den Fall eines fehlenden Genehmigungscodes (eine bestätigte Zahlung ohne Genehmigungsnummer) ein. Die Überprüfung wird auf das IPN (controllers/front/ipn.php), die URL-Bestätigung (controllers/front/confirmation.php), Paygold (PaygoldService) und den REST-Autorisierungspunkt (RedsysRestService::trataPeticion) angewendet, und deckt Apple Pay, Google Pay, Bizum, InSite, OneClick, gespeicherte Karte und Paygold ab. Symptom, das behoben wird: Apple Pay-Bestellungen, die als bezahlt angezeigt werden, ohne dass Geld abgebucht wurde oder etwas im Redsys-Panel angezeigt wird.
[Kritisch] Der öffentliche AJAX-Endpunkt expresspay?action=createOrder erstellte die Bestellung direkt im Status bezahlt (REDSYS_ORDER_STATE_COMPLETED) unter Verwendung eines transaction_id , das vom Kunden bereitgestellt wurde, und ohne Überprüfung von Redsys. Jetzt zwingt es pendingState=true, sodass nur eine ausstehende oder wartende Bestellung erstellt werden kann; der Status bezahlt wird später ausschließlich vom durch die Signatur verifizierten IPN angewendet. Als Verteidigung in der Tiefe ExpressCheckoutService::createOrderFromExpressPay wird der Status bezahlt abgelehnt, wenn keine Genehmigungsreferenz vorhanden ist, und sicher auf ausstehend zurückgegriffen.
[Kritisch] Das IPN von Inespay (controllers/front/inespayipn.php) erstellte eine BEZAHLTE Bestellung, indem es sich auf das Feld codStatus einer nicht authentifizierten Benachrichtigung (ohne Signatur, ohne HMAC, ohne Serverbestätigung) verließ, was es ermöglichte, eine Bestellung ohne echte Bankzahlung zu bestätigen. Jetzt InespayApiService::validateCallback() überprüft die Signatur genau so, wie es die API v2.2 von Inespay vorschreibt: HmacSHA256 über den dataReturn Base64-codiert unter Verwendung des API-KEY des Kontos, in hexadezimalen Kleinbuchstaben ausgedrückt und dann in Base64 codiert, verglichen mit signatureDataReturn. Schließt geschlossen: Eine Benachrichtigung ohne dataReturn und eine gültige signatureDataReturn wird abgelehnt und die Bestellung wird niemals als bezahlt markiert. Das codStatus von vertrauenswürdig (OK / SETTLED) wird aus dem signierten Payload gelesen dataReturn, nicht aus dem rohen POST-Körper.