El desenvolupament d'aquesta versió ha costat 1.700 euros. El cost acumulat per a aquest any és de 5.234 euros. El cost acumulat des de la primera versió és de 40.724 euros, però el cost per a tu és només la llicència des de 79€.

Nova versió 2.0.0 del mòdul Redsys per PrestaShop Premium. És una versió major: amplia la compatibilitat a PrestaShop 1.7, 8 i 9 (PHP 7.4 o superior) i, sobretot, reforça la seguretat de la confirmació de pagaments.

Tabla de contenido

2.0.0

Nou:

Compatibilitat amb PrestaShop 1.7 (PHP 7.4+). El mòdul ara s'instal·la i funciona en PrestaShop 1.7 sobre PHP 7.4 o superior, mantenint-se totalment compatible amb PrestaShop 8 i 9 / PHP 8.x. El requisit mínim de PHP s'ha rebaixat de 8.1 a 7.4 en el guard d'instal·lació, en ps_versions_compliancy (mínim ara 1.7.0.0) i en composer.json. PHP 7.1, 7.2 i 7.3 no són compatibles per estar al final de la seva vida útil; una botiga 1.7.7.x que encara utilitzi aquestes versions ha d'actualitzar el seu PHP a 7.4 abans d'instal·lar.

Millorat:

Substituïdes les construccions del llenguatge exclusives de PHP 8.0 per equivalents compatibles amb PHP 7.4, sense cap canvi de comportament: totes les expressions match() convertides a switch (8 casos), el tipus mixed eliminat i documentat en el docblock (4 casos) i els tipus unió retirats de les signatures de mètode i traslladats al docblock (6 casos). Les característiques modernes de PHP 7.4 (funcions fletxa, propietats tipades, tipus nullables i strict_types) es mantenen intactes.
Els errors de pagament ara es registren sempre. Un nou helper, Ps_redsys_gateway::persistPaymentError(), guarda el motiu concret del fallament com a missatge privat de la comanda més una entrada en el log estès, i les rutes de fallament de l'IPN i de la confirmació escriuen ara un motiu no enganyós (per exemple, «approval code without authorisation code; payment NOT confirmed» o «notification without Ds_Response»). Cap fallament de pagament queda silenciat.

Seguretat:

[Crític] Una comanda podia marcar-se com a PAGADA sense una autorització de Redsys verificada. La regla d'or «mai marcar una comanda com a pagada llevat que Redsys hagi autoritzat realment el pagament» ara s'aplica mitjançant una única font de veritat, Ps_redsys_gateway::isRedsysPaymentAuthorised(), que exigeix que el Ds_Response estigui present i estrictament dins del rang [0,99] i que existeixi un Ds_AuthorisationCode no buit. Això tanca la trampa (int) null === 0 (un codi de resposta absent s'interpretava com a 0 = èxit) i el cas de falta de codi d'autorització (un pagament confirmat sense número d'autorització). La comprovació s'aplica a l'IPN (controllers/front/ipn.php), a la confirmació per URL (controllers/front/confirmation.php), a Paygold (PaygoldService) i al punt de control d'autorització REST (RedsysRestService::trataPeticion), cobrint Apple Pay, Google Pay, Bizum, InSite, OneClick, targeta guardada i Paygold. Síntoma que corregeix: comandes d'Apple Pay mostrades com a pagades sense que es cobrés diners ni aparegués res al panell de Redsys.
[Crític] L'endpoint públic AJAX expresspay?action=createOrder creava la comanda directament en estat pagat (REDSYS_ORDER_STATE_COMPLETED) utilitzant un transaction_id facilitat pel client i sense verificació de Redsys. Ara força pendingState=true, de manera que només pot crear una comanda pendent o a l'espera de pagament; l'estat pagat l'aplica després, en exclusiva, l'IPN verificat per firma. Com a defensa en profunditat, ExpressCheckoutService::createOrderFromExpressPay rechaza l'estat pagat quan no hi ha referència d'autorització i recau de forma segura en pendent.
[Crític] L'IPN d'Inespay (controllers/front/inespayipn.php) creava una comanda PAGADA confiant en el camp codStatus d'una notificació no autenticada (sense firma, sense HMAC, sense confirmació en servidor), el que permetia confirmar una comanda sense cap pagament bancari real. Ara InespayApiService::validateCallback() verifica la firma exactament com especifica l'API v2.2 d'Inespay: HmacSHA256 sobre el dataReturn codificat en Base64 utilitzant la API KEY del compte, expressat en hexadecimal en minúscules i després codificat en Base64, comparat contra signatureDataReturn. Falla de forma tancada: una notificació sense dataReturn i una signatureDataReturn vàlida es rebutja i la comanda mai es marca com a pagada. El codStatus de confiança (OK / SETTLED) es llegeix del payload signat dataReturn, no del cos POST en brut.