El desarrollo de esta versión ha costado 1.700 euros. El coste acumulado para este año es de 5.234 euros. El coste acumulado desde la primera versión es de 40.724 euros, pero el coste para ti es solo la licencia desde 79€.

Nueva versión 2.0.0 del módulo Redsys for PrestaShop Premium. Es una versión mayor: amplía la compatibilidad a PrestaShop 1.7, 8 y 9 (PHP 7.4 o superior) y, sobre todo, refuerza la seguridad de la confirmación de pagos.

Tabla de contenido

2.0.0

Nuevo:

Compatibilidad con PrestaShop 1.7 (PHP 7.4+). El módulo ahora se instala y funciona en PrestaShop 1.7 sobre PHP 7.4 o superior, manteniéndose totalmente compatible con PrestaShop 8 y 9 / PHP 8.x. El requisito mínimo de PHP se ha rebajado de 8.1 a 7.4 en el guard de instalación, en ps_versions_compliancy (mínimo ahora 1.7.0.0) y en composer.json. PHP 7.1, 7.2 y 7.3 no son compatibles por estar al final de su vida útil; una tienda 1.7.7.x que todavía use esas versiones debe actualizar su PHP a 7.4 antes de instalar.

Mejorado:

Sustituidas las construcciones del lenguaje exclusivas de PHP 8.0 por equivalentes compatibles con PHP 7.4, sin ningún cambio de comportamiento: todas las expresiones match() convertidas a switch (8 casos), el tipo mixed eliminado y documentado en el docblock (4 casos) y los tipos unión retirados de las firmas de método y trasladados al docblock (6 casos). Las características modernas de PHP 7.4 (funciones flecha, propiedades tipadas, tipos nullables y strict_types) se mantienen intactas.
Los errores de pago ahora se registran siempre. Un nuevo helper, Ps_redsys_gateway::persistPaymentError(), guarda el motivo concreto del fallo como mensaje privado del pedido más una entrada en el log extendido, y las rutas de fallo del IPN y de la confirmación escriben ahora un motivo no engañoso (por ejemplo, «approval code without authorisation code; payment NOT confirmed» o «notification without Ds_Response»). Ningún fallo de pago queda silenciado.

Seguridad:

[Crítico] Un pedido podía marcarse como PAGADO sin una autorización de Redsys verificada. La regla de oro «nunca marcar un pedido como pagado salvo que Redsys haya autorizado realmente el pago» ahora se aplica mediante una única fuente de verdad, Ps_redsys_gateway::isRedsysPaymentAuthorised(), que exige que el Ds_Response esté presente y estrictamente dentro del rango [0,99] y que exista un Ds_AuthorisationCode no vacío. Esto cierra la trampa (int) null === 0 (un código de respuesta ausente se interpretaba como 0 = éxito) y el caso de falta de código de autorización (un pago confirmado sin número de autorización). La comprobación se aplica al IPN (controllers/front/ipn.php), a la confirmación por URL (controllers/front/confirmation.php), a Paygold (PaygoldService) y al punto de control de autorización REST (RedsysRestService::trataPeticion), cubriendo Apple Pay, Google Pay, Bizum, InSite, OneClick, tarjeta guardada y Paygold. Síntoma que corrige: pedidos de Apple Pay mostrados como pagados sin que se cobrara dinero ni apareciera nada en el panel de Redsys.
[Crítico] El endpoint público AJAX expresspay?action=createOrder creaba el pedido directamente en estado pagado (REDSYS_ORDER_STATE_COMPLETED) usando un transaction_id facilitado por el cliente y sin verificación de Redsys. Ahora fuerza pendingState=true, de modo que solo puede crear un pedido pendiente o a la espera de pago; el estado pagado lo aplica después, en exclusiva, el IPN verificado por firma. Como defensa en profundidad, ExpressCheckoutService::createOrderFromExpressPay rechaza el estado pagado cuando no hay referencia de autorización y recae de forma segura en pendiente.
[Crítico] El IPN de Inespay (controllers/front/inespayipn.php) creaba un pedido PAGADO confiando en el campo codStatus de una notificación no autenticada (sin firma, sin HMAC, sin confirmación en servidor), lo que permitía confirmar un pedido sin ningún pago bancario real. Ahora InespayApiService::validateCallback() verifica la firma exactamente como especifica la API v2.2 de Inespay: HmacSHA256 sobre el dataReturn codificado en Base64 usando la API KEY de la cuenta, expresado en hexadecimal en minúsculas y luego codificado en Base64, comparado contra signatureDataReturn. Falla de forma cerrada: una notificación sin dataReturn y una signatureDataReturn válida se rechaza y el pedido nunca se marca como pagado. El codStatus de confianza (OK / SETTLED) se lee del payload firmado dataReturn, no del cuerpo POST en bruto.