Lo sviluppo di questa versione è costato 1.700 euro. Il costo accumulato per quest'anno è di 5.234 euro. Il costo accumulato dalla prima versione è di 40.724 euro, ma il costo per te è solo la licenza da 79€.

Nuova versione 2.0.0 del modulo Redsys per PrestaShop Premium. È una versione maggiore: amplia la compatibilità a PrestaShop 1.7, 8 e 9 (PHP 7.4 o superiore) e, soprattutto, rafforza la sicurezza della conferma dei pagamenti.

Tabla de contenido

2.0.0

Nuovo:

Compatibilità con PrestaShop 1.7 (PHP 7.4+). Il modulo ora si installa e funziona in PrestaShop 1.7 su PHP 7.4 o superiore, mantenendosi totalmente compatibile con PrestaShop 8 e 9 / PHP 8.x. Il requisito minimo di PHP è stato abbassato da 8.1 a 7.4 nel guard di installazione, in ps_versions_compliancy (minimo ora 1.7.0.0) e in composer.json. PHP 7.1, 7.2 e 7.3 non sono compatibili poiché al termine della loro vita utile; un negozio 1.7.7.x che utilizza ancora quelle versioni deve aggiornare il proprio PHP a 7.4 prima di installare.

Migliorato:

Sostituite le costruzioni del linguaggio esclusive di PHP 8.0 con equivalenti compatibili con PHP 7.4, senza alcun cambiamento di comportamento: tutte le espressioni match() convertite in switch (8 casi), il tipo mixed eliminato e documentato nel docblock (4 casi) e i tipi unione rimossi dalle firme di metodo e trasferiti nel docblock (6 casi). Le caratteristiche moderne di PHP 7.4 (funzioni freccia, proprietà tipizzate, tipi nullabili e strict_types) rimangono intatte.
Gli errori di pagamento ora vengono sempre registrati. Un nuovo helper, Ps_redsys_gateway::persistPaymentError(), salva il motivo specifico del fallimento come messaggio privato dell'ordine più una voce nel log esteso, e i percorsi di fallimento dell'IPN e della conferma scrivono ora un motivo non ingannevole (ad esempio, «approval code without authorisation code; payment NOT confirmed» o «notification without Ds_Response»). Nessun fallimento di pagamento rimane silenzioso.

Sicurezza:

[Critico] Un ordine poteva essere contrassegnato come PAGATO senza un'autorizzazione di Redsys verificata. La regola d'oro «non contrassegnare un ordine come pagato a meno che Redsys non abbia realmente autorizzato il pagamento» ora si applica tramite un'unica fonte di verità, Ps_redsys_gateway::isRedsysPaymentAuthorised(), che richiede che il Ds_Response sia presente e rigorosamente all'interno dell'intervallo [0,99] e che esista un Ds_AuthorisationCode non vuoto. Questo chiude la trappola (int) null === 0 (un codice di risposta assente veniva interpretato come 0 = successo) e il caso di mancanza di codice di autorizzazione (un pagamento confermato senza numero di autorizzazione). La verifica si applica all'IPN (controllers/front/ipn.php), alla conferma tramite URL (controllers/front/confirmation.php), a Paygold (PaygoldService) e al punto di controllo di autorizzazione REST (RedsysRestService::trataPeticion), coprendo Apple Pay, Google Pay, Bizum, InSite, OneClick, carta salvata e Paygold. Sintomo che corregge: ordini di Apple Pay mostrati come pagati senza che fosse stato incassato denaro né apparisse nulla nel pannello di Redsys.
[Critico] L'endpoint pubblico AJAX expresspay?action=createOrder creava l'ordine direttamente in stato pagato (REDSYS_ORDER_STATE_COMPLETED) utilizzando un transaction_id fornito dal cliente e senza verifica di Redsys. Ora forza pendingState=true, in modo che possa creare solo un ordine in attesa o in attesa di pagamento; lo stato pagato viene applicato successivamente, in esclusiva, dall'IPN verificato per firma. Come difesa in profondità, ExpressCheckoutService::createOrderFromExpressPay rifiuta lo stato pagato quando non c'è riferimento di autorizzazione e ricade in modo sicuro in attesa.
[Critico] L'IPN di Inespay (controllers/front/inespayipn.php) creava un ordine PAGATO fidandosi del campo codStatus di una notifica non autenticata (senza firma, senza HMAC, senza conferma sul server), il che permetteva di confermare un ordine senza alcun pagamento bancario reale. Ora InespayApiService::validateCallback() verifica la firma esattamente come specificato dall'API v2.2 di Inespay: HmacSHA256 su dataReturn codificato in Base64 utilizzando la API KEY dell'account, espresso in esadecimale in minuscolo e poi codificato in Base64, confrontato con signatureDataReturn. Fallisce in modo chiuso: una notifica senza dataReturn e una signatureDataReturn valida viene rifiutata e l'ordine non viene mai contrassegnato come pagato. Il codStatus di fiducia (OK / SETTLED) viene letto dal payload firmato dataReturn, non dal corpo POST grezzo.