Le développement de cette version a coûté 1.700 euros. Le coût cumulé pour cette année est de 5.234 euros. Le coût cumulé depuis la première version est de 40.724 euros, mais le coût pour vous est seulement la licence à partir de 79€.

Nouvelle version 2.0.0 du module Redsys pour PrestaShop Premium. C'est une version majeure : elle étend la compatibilité à PrestaShop 1.7, 8 et 9 (PHP 7.4 ou supérieur) et, surtout, renforce la sécurité de la confirmation des paiements.

Tabla de contenido

2.0.0

Nouveau :

Compatibilité avec PrestaShop 1.7 (PHP 7.4+). Le module s'installe et fonctionne maintenant sur PrestaShop 1.7 sous PHP 7.4 ou supérieur, tout en restant totalement compatible avec PrestaShop 8 et 9 / PHP 8.x. L'exigence minimale de PHP a été abaissée de 8.1 à 7.4 dans le garde d'installation, dans ps_versions_compliancy (minimum maintenant 1.7.0.0) et dans composer.json. PHP 7.1, 7.2 et 7.3 ne sont pas compatibles car ils sont en fin de vie ; un magasin 1.7.7.x qui utilise encore ces versions doit mettre à jour son PHP à 7.4 avant d'installer.

Amélioré :

Les constructions de langage exclusives à PHP 8.0 ont été remplacées par des équivalents compatibles avec PHP 7.4, sans aucun changement de comportement : toutes les expressions match() converties en switch (8 cas), le type mixed supprimé et documenté dans le docblock (4 cas) et les types union retirés des signatures de méthode et transférés au docblock (6 cas). Les caractéristiques modernes de PHP 7.4 (fonctions fléchées, propriétés typées, types nullables et strict_types) restent intactes.
Les erreurs de paiement sont maintenant toujours enregistrées. Un nouvel helper, Ps_redsys_gateway::persistPaymentError(), conserve la raison précise de l'échec comme message privé de la commande plus une entrée dans le journal étendu, et les chemins d'échec de l'IPN et de la confirmation écrivent maintenant une raison non trompeuse (par exemple, « code d'approbation sans code d'autorisation ; paiement NON confirmé » ou « notification sans Ds_Response »). Aucun échec de paiement n'est silencieux.

Sécurité :

[Critique] Une commande pouvait être marquée comme PAYÉE sans une autorisation de Redsys vérifiée. La règle d'or « ne jamais marquer une commande comme payée à moins que Redsys n'ait réellement autorisé le paiement » s'applique maintenant par une unique source de vérité, Ps_redsys_gateway::isRedsysPaymentAuthorised(), qui exige que le Ds_Response soit présent et strictement dans la plage [0,99] et qu'il existe un Ds_AuthorisationCode non vide. Cela ferme le piège (int) null === 0 (un code de réponse absent était interprété comme 0 = succès) et le cas de manque de code d'autorisation (un paiement confirmé sans numéro d'autorisation). La vérification s'applique à l'IPN (controllers/front/ipn.php), à la confirmation par URL (controllers/front/confirmation.php), à Paygold (PaygoldService) et au point de contrôle d'autorisation REST (RedsysRestService::trataPeticion), couvrant Apple Pay, Google Pay, Bizum, InSite, OneClick, carte enregistrée et Paygold. Symptôme corrigé : commandes d'Apple Pay affichées comme payées sans que de l'argent ne soit prélevé ni que rien n'apparaisse dans le panneau de Redsys.
[Critique] Le point de terminaison public AJAX expresspay?action=createOrder créait la commande directement dans l'état payé (REDSYS_ORDER_STATE_COMPLETED) en utilisant un transaction_id fourni par le client et sans vérification de Redsys. Maintenant, il force pendingState=true, de sorte qu'il ne peut créer qu'une commande en attente ou en attente de paiement ; l'état payé est appliqué ensuite, exclusivement, par l'IPN vérifié par signature. Comme défense en profondeur, ExpressCheckoutService::createOrderFromExpressPay rejette l'état payé lorsqu'il n'y a pas de référence d'autorisation et retombe en toute sécurité en attente.
[Critique] L'IPN d'Inespay (controllers/front/inespayipn.php) créait une commande PAYÉE en se fiant au champ codStatus d'une notification non authentifiée (sans signature, sans HMAC, sans confirmation sur le serveur), ce qui permettait de confirmer une commande sans aucun paiement bancaire réel. Maintenant, InespayApiService::validateCallback() vérifie la signature exactement comme spécifié par l'API v2.2 d'Inespay : HmacSHA256 sur le dataReturn codé en Base64 en utilisant la clé API du compte, exprimé en hexadécimal en minuscules et ensuite codé en Base64, comparé à signatureDataReturn. Échec de manière fermée : une notification sans dataReturn et une signatureDataReturn valide est rejetée et la commande n'est jamais marquée comme payée. Le codStatus de confiance (OK / SETTLED) est lu du payload signé dataReturn, pas du corps POST brut.