O desenvolvimento desta versão custou 1.700 euros. O custo acumulado para este ano é de 5.234 euros. O custo acumulado desde a primeira versão é de 40.724 euros, mas o custo para você é apenas a licença a partir de 79€.

Nova versão 2.0.0 do módulo Redsys para PrestaShop Premium. É uma versão maior: amplia a compatibilidade para PrestaShop 1.7, 8 e 9 (PHP 7.4 ou superior) e, acima de tudo, reforça a segurança da confirmação de pagamentos.

Tabla de contenido

2.0.0

Novo:

Compatibilidade com PrestaShop 1.7 (PHP 7.4+). O módulo agora é instalado e funciona no PrestaShop 1.7 sobre PHP 7.4 ou superior, mantendo-se totalmente compatível com PrestaShop 8 e 9 / PHP 8.x. O requisito mínimo de PHP foi reduzido de 8.1 para 7.4 na guarda de instalação, em ps_versions_compliancy (mínimo agora 1.7.0.0) e em composer.json. PHP 7.1, 7.2 e 7.3 não são compatíveis por estarem no final de sua vida útil; uma loja 1.7.7.x que ainda use essas versões deve atualizar seu PHP para 7.4 antes de instalar.

Melhorado:

Substituídas as construções de linguagem exclusivas do PHP 8.0 por equivalentes compatíveis com PHP 7.4, sem nenhuma mudança de comportamento: todas as expressões match() convertidas para switch (8 casos), o tipo mixed removido e documentado no docblock (4 casos) e os tipos união retirados das assinaturas de método e transferidos para o docblock (6 casos). As características modernas do PHP 7.4 (funções flecha, propriedades tipadas, tipos anuláveis e strict_types) permanecem intactas.
Os erros de pagamento agora são sempre registrados. Um novo helper, Ps_redsys_gateway::persistPaymentError(), guarda o motivo específico da falha como mensagem privada do pedido mais uma entrada no log estendido, e as rotas de falha do IPN e da confirmação agora escrevem um motivo não enganoso (por exemplo, «código de aprovação sem código de autorização; pagamento NÃO confirmado» ou «notificação sem Ds_Response»). Nenhuma falha de pagamento fica silenciada.

Segurança:

[Crítico] Um pedido poderia ser marcado como PAGO sem uma autorização do Redsys verificada. A regra de ouro «nunca marcar um pedido como pago a menos que o Redsys tenha realmente autorizado o pagamento» agora se aplica por meio de uma única fonte de verdade, Ps_redsys_gateway::isRedsysPaymentAuthorised(), que exige que o Ds_Response esteja presente e estritamente dentro do intervalo [0,99] e que exista um Ds_AuthorisationCode não vazio. Isso fecha a armadilha (int) null === 0 (um código de resposta ausente era interpretado como 0 = sucesso) e o caso de falta de código de autorização (um pagamento confirmado sem número de autorização). A verificação se aplica ao IPN (controllers/front/ipn.php), à confirmação por URL (controllers/front/confirmation.php), ao Paygold (PaygoldService) e ao ponto de controle de autorização REST (RedsysRestService::trataPeticion), cobrindo Apple Pay, Google Pay, Bizum, InSite, OneClick, cartão guardado e Paygold. Sintoma que corrige: pedidos de Apple Pay mostrados como pagos sem que dinheiro fosse cobrado ou aparecesse nada no painel do Redsys.
[Crítico] O endpoint público AJAX expresspay?action=createOrder criava o pedido diretamente em estado pago (REDSYS_ORDER_STATE_COMPLETED) usando um transaction_id fornecido pelo cliente e sem verificação do Redsys. Agora força pendingState=true, de modo que só pode criar um pedido pendente ou à espera de pagamento; o estado pago é aplicado depois, exclusivamente, pelo IPN verificado por assinatura. Como defesa em profundidade, ExpressCheckoutService::createOrderFromExpressPay rejeita o estado pago quando não há referência de autorização e recai de forma segura em pendente.
[Crítico] O IPN do Inespay (controllers/front/inespayipn.php) criava um pedido PAGO confiando no campo codStatus de uma notificação não autenticada (sem assinatura, sem HMAC, sem confirmação no servidor), o que permitia confirmar um pedido sem nenhum pagamento bancário real. Agora InespayApiService::validateCallback() verifica a assinatura exatamente como especifica a API v2.2 do Inespay: HmacSHA256 sobre o dataReturn codificado em Base64 usando a API KEY da conta, expresso em hexadecimal em minúsculas e depois codificado em Base64, comparado contra signatureDataReturn. Falha de forma fechada: uma notificação sem dataReturn e uma signatureDataReturn válida é rejeitada e o pedido nunca é marcado como pago. O codStatus de confiança (OK / SETTLED) é lido do payload assinado dataReturn, não do corpo POST em bruto.