O desenvolvemento desta versión custou 1.700 euros. O custo acumulado para este ano é de 5.234 euros. O custo acumulado desde a primeira versión é de 40.724 euros, pero o custo para ti é só a licencia desde 79€.

Nova versión 2.0.0 do módulo Redsys para PrestaShop Premium. É unha versión maior: amplía a compatibilidade a PrestaShop 1.7, 8 e 9 (PHP 7.4 ou superior) e, sobre todo, refuerza a seguridade da confirmación de pagos.

Tabla de contenido

2.0.0

Novo:

Compatibilidade con PrestaShop 1.7 (PHP 7.4+). O módulo agora instálase e funciona en PrestaShop 1.7 sobre PHP 7.4 ou superior, mantendo totalmente compatible con PrestaShop 8 e 9 / PHP 8.x. O requisito mínimo de PHP rebaixouse de 8.1 a 7.4 no gardián de instalación, en ps_versions_compliancy (mínimo agora 1.7.0.0) e en composer.json. PHP 7.1, 7.2 e 7.3 non son compatibles por estar ao final da súa vida útil; unha tenda 1.7.7.x que siga usando esas versións debe actualizar o seu PHP a 7.4 antes de instalar.

Mellorado:

Substituíronse as construcións do linguaxe exclusivas de PHP 8.0 por equivalentes compatibles con PHP 7.4, sen ningún cambio de comportamento: todas as expresións match() convertidas a switch (8 casos), o tipo mixed eliminado e documentado no docblock (4 casos) e os tipos unión retirados das firmas de método e trasladados ao docblock (6 casos). As características modernas de PHP 7.4 (funcións flecha, propiedades tipadas, tipos nullables e strict_types) mantéñense intactas.
Os erros de pago agora se rexistran sempre. Un novo helper, Ps_redsys_gateway::persistPaymentError(), garda o motivo concreto do fallo como mensaxe privada do pedido máis unha entrada no log estendido, e as rutas de fallo do IPN e da confirmación escriben agora un motivo non enganoso (por exemplo, «approval code without authorisation code; payment NOT confirmed» ou «notification without Ds_Response»). Ningún fallo de pago queda silenciado.

Seguridade:

[Crítico] Un pedido podía marcarse como PAGADO sen unha autorización de Redsys verificada. A regra de ouro «nunca marcar un pedido como pagado salvo que Redsys autorizase realmente o pago» agora aplícase mediante unha única fonte de verdade, Ps_redsys_gateway::isRedsysPaymentAuthorised(), que esixe que o Ds_Response estea presente e estritamente dentro do rango [0,99] e que exista un Ds_AuthorisationCode non baleiro. Isto pecha a trampa (int) null === 0 (un código de resposta ausente interpretábase como 0 = éxito) e o caso de falta de código de autorización (un pago confirmado sen número de autorización). A comprobación aplícase ao IPN (controllers/front/ipn.php), á confirmación por URL (controllers/front/confirmation.php), a Paygold (PaygoldService) e ao punto de control de autorización REST (RedsysRestService::trataPeticion), cubrindo Apple Pay, Google Pay, Bizum, InSite, OneClick, tarxeta gardada e Paygold. Síntoma que corrige: pedidos de Apple Pay mostrados como pagados sen que se cobrara diñeiro nin aparecese nada no panel de Redsys.
[Crítico] O endpoint público AJAX expresspay?action=createOrder creaba o pedido directamente en estado pagado (REDSYS_ORDER_STATE_COMPLETED) usando un transaction_id facilitado polo cliente e sen verificación de Redsys. Agora forza pendingState=true, de modo que só pode crear un pedido pendente ou á espera de pago; o estado pagado aplícase despois, en exclusiva, polo IPN verificado por firma. Como defensa en profundidade, ExpressCheckoutService::createOrderFromExpressPay rexeita o estado pagado cando non hai referencia de autorización e recae de forma segura en pendente.
[Crítico] O IPN de Inespay (controllers/front/inespayipn.php) creaba un pedido PAGADO confiando no campo codStatus dunha notificación non autenticada (sen firma, sen HMAC, sen confirmación en servidor), o que permitía confirmar un pedido sen ningún pago bancario real. Agora InespayApiService::validateCallback() verifica a firma exactamente como especifica a API v2.2 de Inespay: HmacSHA256 sobre o dataReturn codificado en Base64 usando a API KEY da conta, expresado en hexadecimal en minúsculas e logo codificado en Base64, comparado contra signatureDataReturn. Falla de forma cerrada: unha notificación sen dataReturn e unha signatureDataReturn válida séguese rexeitando e o pedido nunca se marca como pagado. O codStatus de confianza (OK / SETTLED) lémbrese do payload firmado dataReturn, non do corpo POST en bruto.