Módulo Order Guard - impede pedidos duplicados e extratos de pagamento ou faturas duplicados.

01/11/2026
v1.4.1

• A opção "Criar pedido" não altera mais o idioma da tela. Criar uma ordem de pagamento sem um pedido fazia com que o usuário saísse do painel administrativo no idioma do cliente (e com o carrinho e a moeda em contexto) até a próxima página. Agora tudo voltou a ser como era antes.
• Ajustes no validador de complementos do PrestaShop: o armazenamento de pagamentos sem ordem é passado do módulo e do controlador em vez de ser lido do contexto global, e o estilo de dois comentários foi ajustado aos padrões do PrestaShop.

01/11/2026
v1.4.0

Pagamentos da Redsys que nunca foram processados. O banco cobra, a Redsys notifica, e o pedido não é criado: a notificação chegou, mas validarPedido() A entrega falhou, foi interrompida por falta de tempo ou simplesmente nunca chegou. O cliente já pagou, mas a loja não tem conhecimento disso.

• Registro de cada notificação do Redsys que entra na loja, capturada no dispatcher antes do carregamento do controlador do módulo de pagamento (se o controlador falhar, a entrada já terá sido feita). Isso se aplica a qualquer módulo que receba Ds_Parâmetros do Comerciante: o oficial, RKR Redsys, o Redsys integrado do RKR Subscriptions ou um de terceiros. Apenas o necessário para a correspondência com um pedido é salvo (número da transação, carrinho, valor, moeda, resposta, tipo, autorização); nunca o cartão nem os parâmetros em si.
• Assinatura verificada (HMAC_SHA256_V1 e HMAC_SHA512_V2) em relação a todas as chaves Redsys na configuração. Assinaturas que não correspondem não são contabilizadas; sem uma chave para verificar, são contabilizadas, mas marcadas como "assinatura não verificada".
• Revisão No cron (e com o botão "Verificar agora"): após alguns minutos (15 por padrão, configurável), ele busca o pedido de cada pagamento autorizado — pelo número da operação nas coleções, pelo carrinho ou, em "criar o pedido antes de pagar", pelo ID — e anota. pagamento_sem_pedido qualquer pedido_pago_não_atualizado (O pedido existe, mas ainda não está com status de pago.) Notifique por e-mail e pelo RKR Sentinel e adicione um alerta ao banner vermelho no painel administrativo. Se o pedido aparecer posteriormente, o alerta será fechado automaticamente.
• Importando o arquivo CSV de operações do portal Redsys (Canais), pelos quais a loja nunca recebeu. Colunas reconhecidas pelo cabeçalho, em espanhol ou inglês; separador ;, , , ou tabulação; UTF-8 ou Latin-1; valores "1.234,56" ou "1234,56". Somente cobranças autorizadas: recusadas, reembolsos e cancelamentos não serão processados.
• Tela "Pagamentos Redsys sem Pedido" (Pedidos): botão Criar pedido (Em "Pagamento aceito", com o número da transação no pagamento e o funcionário na mensagem do pedido) somente se o carrinho for conhecido, o carrinho ainda não tiver nenhum pedido, a moeda for a do carrinho e o valor cobrado for o total de hoje; o módulo de pagamento é escolhido entre os ativos. Ele usa o mesmo bloqueio da notificação, portanto, não entra em conflito com uma nova tentativa do Redsys. Botão Exclua para itens devolvidos ou resolvidos manualmente, e as notificações mais recentes observadas para verificar se o registro está funcionando.
• Se outro módulo falhar depois para criar o pedido (um gancho no e-mail de confirmação que espera o formato do preço do front-end, visto com idxrrecargoeO pedido é então criado e o erro é reportado. Sem o formato de preço no contexto, ele é inserido antes da criação.
• Ajuste o tempo de espera e a disponibilidade nas configurações. As notificações que já contêm seu pedido são excluídas após 180 dias.
• A funcionalidade de consulta de transações do serviço web Redsys não está disponível: o banco precisa ativá-la separadamente e não há como testá-la.

12/10/2026
v1.3.2

• A chave do produto PrestaShop Addons (chave_do_módulo), para vendê-lo lá. Nada mais muda.

12/10/2026
v1.3.1

• Apenas para validadores de complementos do PrestaShop: a descrição do módulo deve estar em uma única linha. Se estiver dividida em várias linhas, o validador não a lerá e suspenderá a seção "Requisitos" com um erro.$this"A descrição não é válida." O texto é o mesmo e a loja não percebe nada.

12/10/2026
v1.3.0

Monitoramento de pagamentos desviados. Isso se origina de um caso real: um invasor com acesso FTP inseriu um pagamento com cartão de crédito de seu próprio gateway de pagamento no módulo Redsys e, durante meses, pedidos foram criados em nome da Redsys, com tudo em ordem no back office — incluindo a própria tabela do módulo — e o dinheiro em sua conta. Nada de novo é alterado em um pedido ou pagamento: o sistema apenas registra e gera alertas.

• Novo critério pagamento_incompatívelO número da operação não é o que o gateway teria registrado para esse pedido. Validadores de gateway (classes/RkrOrderGuardGateway*.php, (uma lacuna por gateway). O Redsys é verificado por assinaturaO Ds_Order propriamente dito começa com o número do carrinho, com zeros até 8 dígitos, e termina em mmss (ou é o ID do pedido de 12 dígitos com "criar pedido antes de pagar"); é aceitável se for um carrinho ou pedido diferente do mesmo cliente, e formatos vazios ou desatualizados não são considerados. PayPal, PayPlug e Stripe, por exemplo. forma. É analisado açãoValidarPedido E é registrado uma vez por pedido, não uma vez para cada mudança de status.
• Validado em comparação com a cópia da caixa armazenada. (Mais de cem mil pedidos, analisados em menos de um segundo): exatamente os pedidos desviados aparecem, nenhum anterior ao primeiro dia do ataque, e nenhum falso positivo entre as dezenas de milhares de pedidos do PayPal e PayPlug. Contas legítimas da Redsys com valores na casa dos 12 dígitos apresentam o mesmo problema. mmss válido; 12 dígitos aleatórios tornam isso impossível duas em cada três vezes.
• Descrição dos arquivos do módulo de pagamento (arquivos_de_pagamento): trecho do hash sha256 de cada arquivo de código nos módulos de pagamento instalados — ativos ou não: o atacante desativou o PayPlug para ocultá-lo —, deste módulo e dos arquivos individuais no diretório raiz. Ele notifica você se um arquivo for alterado, aparecer ou desaparecer. Uma atualização para PrestaShop Não te avisaO carregamento da versão no banco de dados recriará automaticamente a impressão digital. A versão do arquivo é inválida: o invasor usou uma versão mais antiga do módulo.
• Nova tela: Pedidos → Monitoramento de pagamentos. Alertas abertos (marcados como revisados), arquivos por módulo com "Aceitar arquivos atuais" e revisão do histórico Número da operação, somente leitura.
• Avisos onde eles são vistosFaixa vermelha em toda a área administrativa enquanto qualquer coisa permanecer aberta, e um aviso no formulário de pedido, que é onde o remetente está localizado. Além do correio e do RKR Sentinel.
• Cron com seu próprio token (/module/rkrorderguard/cron): verifica os arquivos e pedidos dos últimos sete dias, caso algum tenha sido criado sem passar pelo hook. Sem o cron, o back office realiza a verificação de arquivos no máximo uma vez por intervalo.
• O que não fazerConsulte a transação com a Redsys. O módulo Redsys não inclui nenhuma consulta e é um serviço separado que cada banco ativa para cada comerciante. A confirmação é feita manualmente no painel de controle.
• Coexistência com o RKR Order Guard Free, que compartilha a tabela de incidentes e fecha os itens em aberto em um pedido que considera limpo: um pagamento desviado permanece em aberto até que um funcionário o marque como revisado, independentemente de quem o feche.
• O PrestaShop 9.1 não funciona. exibirAdminAfterHeader Nas páginas do controlador clássico: a banda também é colocada a partir de exibirCabeçalhoDoBackOffice, Sem duplicação.
• Corrigido um erro fatal latente no PrestaShop 9. na reparação de duplicados: devolução do estoque chamado para StockAvailable::dependsOnStock(), que o 9 já não possui. Ele só chegou lá porque o cancelamento não trouxe o estoque de volta por si só.
• Análise de complementos: todo o HTML vai para modelos Smarty (visualizações/modelos/admin/) e os scripts para visualizações/js/; nada de Contexto::, , Tab::getIdFromClassName() nenhum Módulo::isInstalado()/isHabilitado() (obsoleto); .htaccess na raiz; l() Sem o suporte do Symfony, o que deixou "Tradução não encontrada" com "Não" e "Total"; a descrição de config.xml O mesmo que PHP; PHP CS Fixer e PHPStan (nível 5) limpos.

30/09/2026
v1.2.0

A decisão tem uma variante que o 1.1.0 Não percebi: quando o módulo de pagamento cria o pedido APÓS o pagamento, o que é duplicado não é a fatura, mas sim o pedido. ordem. Cada um dos dois permanece internamente consistente — suas faturas com seus itens de linha e seu faturamento estão equilibrados — portanto, nenhum dos três critérios anteriores indicou isso. Em relação a uma loja real com 143.649 pedidos: 29 carrinhos com dois pedidos e, dos 54 mais recentes, a detecção do 1.1.0 teria marcado zero.

• Novo critério ordem duplicadaExiste outro pedido ATIVO do mesmo carrinho com uma referência diferente. A referência é o que o diferencia de uma divisão por pacote, que o PrestaShop faz intencionalmente e na qual todos os pedidos compartilham uma referência — portanto, um índice único. orders.id_cart Essa não é a solução. Confira. açãoValidarPedido, que é quando você sabe que um pedido acaba de ser criado, e em cada revisão subsequente.
• Nova tela: Pedidos → Pedidos duplicados. Verificar e consertar os que já estão na loja, o que até agora tinha que ser feito manualmente, um por um. Ele não parece RKROG_SINCEEssa data é para monitoramento ao vivo, e é exatamente por isso que estamos aqui, para ver o que foi mostrado acima.
• O que importa naquela tela é a classificação., e folhas order_payment.transaction_id, que faz parte do núcleo e não depende do gateway: PARA um pagamento e dois pedidos — o excedente é cancelado, não há dinheiro extra —, B duas cobranças separadas — o dinheiro precisa ser devolvido e isso é decidido por uma pessoa — e C indeterminado, que é apenas listado. Apenas o caso A é abordado.
• E o que não faz, o que é igualmente importante.Se o excedente tiver uma fatura numerada, a fatura não é alterada (isso requer uma correção); se um pacote já foi enviado, nada é alterado, o gateway nunca é acionado nem uma devolução é emitida, e nada é executado em lotes sem marcação e confirmação.
• A simulação equivale exatamente à execução. Toda a decisão reside em analisar(), que não escreve; aplicar() Ele apenas executa o que já foi decidido. O relatório se encaixa por construção (grupos = reparados + ignorados + nada) e a tela avisa se alguma vez não estiver alinhada.
• O estoque é medido, não estimado. O núcleo é devolvido após o cancelamento, mas somente se o estado anterior tiver sido considerado e o produto não for gerenciado por meio de gerenciamento avançado. As medições são feitas antes e depois, e apenas o que não foi devolvido é substituído: injetá-lo por precaução resultaria em sua devolução dupla, o que é pior do que não devolvê-lo de forma alguma.
• A referência do gateway torna-se a PRIMEIRA chave de bloqueio. Em um servidor que suporta apenas um OBTER_BLOQUEIO Apenas a primeira sessão é realizada e, com o carrinho de compras aberto, as duas chamadas ao gateway bloquearam nomes diferentes: exclusão mútua zero, e o módulo estava instalado, ativo e sem fazer nada. A referência ao gateway é a única que chega por ambos os caminhos — a notificação servidor-para-servidor geralmente chega sem nenhum parâmetro da nossa parte.
• Registro opcional de fechaduras apreendidas (RKROG_TRACE, (desligado de fábrica). Sem isso, descobrir o que foi mencionado acima levaria uma tarde inteira: não havia como ver qual tecla havia bloqueado uma solicitação.