---
title: "Redsys for PrestaShop Premium 2.0.0"
description: "Nueva versión 2.0.0 de Redsys for PrestaShop Premium: compatibilidad con PrestaShop 1.7, 8 y 9 (PHP 7.4+) y tres correcciones críticas de seguridad para que ningún pedido se marque como pagado sin una autorización real de Redsys."
url: https://plugins.joseconti.com/2026/06/24/redsys-for-prestashop-premium-2-0-0/
date: 2026-06-24
modified: 2026-06-24
author: "jconti"
image: https://plugins.joseconti.com/wp-content/uploads/2026/06/redsys-prestashop-premium-2-0-0-v2-scaled.jpg
categories: ["General"]
type: post
lang: es
---

# Redsys for PrestaShop Premium 2.0.0

> 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 (https://plugins.joseconti.com/product/redsys-for-prestashop-premium/) desde 79€.

Nueva versión 2.0.0 del módulo (https://plugins.joseconti.com/product/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.

## 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:

- **** 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.

- **** 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.

- **** 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.