Módulo de pagamentos recorrentes - assinaturas com Redsys

27/10/2026
v5.13.0

• Todo o texto do módulo agora está traduzido do inglês: notificações do Telegram, motivos de rejeição do Redsys, erros de remessa do Stripe, PayPal e SEPA, o texto do mandato SEPA e o e-mail de cartão expirado e seu assunto. Em uma loja em espanhol, eles aparecem da mesma forma que antes; em uma loja em inglês (ou em outro idioma não traduzido), o espanhol não aparece mais. As notificações do comerciante são exibidas no idioma da loja, enquanto o cliente as vê em seu próprio idioma.
• Os cabeçalhos dos arquivos CSV de previsão e remessa SEPA agora estão em inglês.
• A tela de configurações não trava mais se for aberta sem o controlador do back-office (o que acontecia na análise de complementos do PrestaShop). 8.1.2); em caso de falha, exibe um aviso e o registra no log, em vez de uma página quebrada.
• Os links para alteração de conta PayPal e alteração de cartão Stripe validam a chave e o token antes do uso e redirecionam para o PayPal ou Stripe Checkout somente via HTTPS. Observações técnicas:
• RkrSubsText::t() (classes/RkrSubsText.php) traduz frases inteiras com vsprintf e desfaz o escape HTML de l() para o Telegram. Os dois mapas de código Redsys são combinados em um (RkrSubsRedsysHelper). obterConteúdo() embrulhos renderizarRkrConfiguration() em Tentativa/Recepção (Arremessável) e as formas assumem as línguas de obterLinguagensFormulárioRkr().

27/10/2026
v5.12.2

• Desempenho: O jQuery UI, seu calendário e o arquivo de tradução com TODOS os idiomas (aproximadamente 110 KB) não são mais carregados em todas as páginas de produtos, listagens, página inicial, carrinho e pedidos. O calendário da primeira entrega só aparece em produtos físicos com a opção "Mostrar data da primeira entrega" ativada; agora ele é baixado quando esse campo é encontrado e apenas no idioma da loja.
• Fora com um console.log que permaneceram no console do navegador ao alterar as combinações.

22/10/2026
v5.12.1

• Transferência bancária: O grupo padrão do cliente também é usado para visualizar o método de pagamento. Um cliente criado por meio de importação ou API, sem a linha de grupo correspondente, não verá essa opção, mesmo que o grupo esteja selecionado.

22/10/2026
v5.12.0

• Pedidos aguardando transferência bancária podem ser pagos com cartão (Stripe ou Redsys) ou PayPal: clique no botão "Pagar agora com..." nos detalhes do pedido em Minha Conta e no link presente nos e-mails de transferência e lembrete. O MESMO pedido será pago, pelo valor exato: nenhum novo pedido será criado.
• O pedido só passa para o status "Pagamento aceito" quando o gateway de pagamento o confirma (notificação do Stripe ou Redsys, ou uma captura de tela do PayPal tirada da loja); então o pagamento é registrado com sua referência, a fatura é gerada e os downloads são liberados. Antes disso, não há acesso a nada.
• Se o pedido for de uma assinatura, a assinatura será processada através do sistema de pagamento utilizado, e o cartão ou a conta PayPal serão salvos: as renovações subsequentes serão cobradas automaticamente. Não serão mais enviados lembretes de transferência.
• Um pagamento em andamento bloqueia outro por 30 minutos, e uma notificação repetida do gateway de pagamento não duplica o pagamento. Se um segundo pagamento chegar para um pedido já pago, ele não será aplicado e você será notificado via Telegram para devolvê-lo; se a transferência chegar mais tarde, a tela de Transferências indicará isso.
• O cliente recebe um e-mail com a seguinte mensagem: "Pagamento recebido, você não precisa mais fazer a transferência."
• O PayPal está incluído, mas não foi totalmente testado (assim como o restante do PayPal). Observações técnicas:
• RkrSubsTransferirPagarAgora (classes/portais/transferência), motoristas transferpay e transferênciapagarretorno, prefix P{id_order} na notificação Redsys, metadata.rkr_pay_order no PaymentIntent do Stripe e custom_id = pedido-{id} no PayPal. Novas colunas em rkr_subs_transferência e gancho exibirDetalhesDoPedido (atualizar 5.12.0).

22/10/2026
v5.11.0

• Novo método de pagamento: transferência bancária, para compras individuais e assinaturas, somente para os grupos de clientes que você escolher. Você configura o titular da conta, IBAN, BIC, banco, referência de pagamento (incluindo o número do pedido) e instruções.
• O pedido permanece "Aguardando Transferência", que NÃO é um status de pago: não há downloads, fatura ou qualquer pagamento pendente (incluindo a assinatura de presente) até que você o marque como pago em Assinaturas > Transferências. Ao marcá-lo como pago, o status muda para "Pagamento Aceito" e o cliente recebe os links para download.
• As renovações são feitas da mesma forma, sem pagamento, e o cliente recebe um e-mail com os detalhes da transferência.
• Transferências não pagas: lembretes ao cliente (padrão de 3 e 7 dias), notificação via Telegram e, após o prazo (14 dias por padrão), a assinatura é pausada, assim como ocorre com pagamentos não efetuados. Marcar a assinatura como paga a reativa automaticamente. Observações técnicas:
• Passarela transferir (identificador) rkrtransferpayment) em classes/portais/transferência, quadro rkr_subs_transferência, status do próprio pedido (pago=0, registrável=0, sem e-mail) e tela AdminRkrSubsTransferências. Está instalado e desligado (atualização) 5.11.0).

22/10/2026
v5.10.1

• Atualização de uma versão anterior para 5.8.0 falhou ("Atualizado de 5.5.2 para 5.7.0, 4 atualizações restantes») e o PrestaShop desativou o módulo: a atualização do 5.8.0 Eu estava tentando completar uma tabela que cria o 5.10.0 e ainda não existia. Agora, ele ignora as tabelas que ainda não existem. Do 5.8.0 Ou mais tarde isso não aconteceu.

22/10/2026
v5.10.0

• Alterar o plano de uma assinatura existente: outros módulos podem transferi-lo para outro produto ou combinação com outros. RkrProductSubscriptionGlobal::swapProduct(). A próxima renovação será cobrada pelo novo preço do plano, na mesma data e usando o mesmo método de pagamento. No sistema de faturamento do Stripe, o preço é alterado no Stripe sem rateio (se o Stripe falhar, nada muda). Cada alteração é refletida na seção "Alterações do Plano" da assinatura no painel administrativo. Observações técnicas:
• Nova tabela rkr_subscription_swap (atualizar 5.10.0) e gancho actionRkrSubscriptionProductSwapped com id_assinatura, , antes, , depois e observação.

22/10/2026
v5.9.4

• Abrir manualmente (ou usar um mecanismo de busca como o Bingbot) o endereço das chamadas internas do módulo, sem parâmetros ou com uma ação inexistente, resultou em um erro do PrestaShop ("Missing").$template'parâmetro') que estava chegando ao log de erros. Agora ele responde "400 solicitação inválida" em JSON e pede aos mecanismos de busca para não indexá-lo (X-Robots-Tag: noindexO mesmo se aplica a todos os controladores de módulo que não possuem sua própria página (retornos de gateway, webhooks, cron).

21/10/2026
v5.9.3

• Chave do produto PrestaShop Addons (chave_do_módulo) para o produto 99324. Sem alterações de funcionamento.

21/10/2026
v5.9.2

• Redsys, SEPA e PayPal eram exibidos em inglês nas lojas em espanhol, francês, italiano, alemão e português (opções de pagamento, configurações, "Meus cartões de assinatura", página de pagamento e confirmação): 175 textos foram traduzidos. Por outro lado, algumas telas do Redsys e o painel do Telegram eram exibidos em espanhol nas lojas em inglês; agora estão em inglês.
• A previsão de cobrança mostra a frequência, o método de pagamento e o status de cada cobrança ("Sem autorização", "Sem cartão", "Expira"...) no idioma do funcionário (anteriormente, sempre em espanhol).
• No PrestaShop 9, o cabeçalho da tabela de previsão de coleções estava desalinhado em várias linhas.
• O link "Documentação" na configuração abre o novo manual (em espanhol ou inglês, dependendo do idioma do funcionário); antes, ele levava ao manual antigo, que não existe mais.
• Os botões "Testar PayPal" e "Testar SEPA" exibem corretamente o nome do gateway de pagamento. Observações técnicas:
• Novas fontes no catálogo de traduções: rkrsubsredsysgateway, , rkrsubssepagateway, , rkrsubscriptionforecast e os modelos redsys_*. 18 strings alteram seu texto base de espanhol para inglês (o espanhol permanece em traduções/es.php).
• Testado novamente após atualizar a demonstração a partir do 5.5.1O assistente de upload e migração transfere mandatos, remessas e cobranças SEPA, além de planos e assinaturas do Stripe, tudo isso a partir dos módulos individuais.
• Validador de complementos (envio 3780450): apenas o falso positivo "Uso obrigatório de PaymentOption".

21/10/2026
v5.9.1

• Pronto para complementos do PrestaShop: a biblioteca Stripe agora vem do Composer, na pasta fornecedor/ do módulo, e o código passa nas regras de estilo do PrestaShop e na análise estática (PHPStan).
• Requer PHP 8.0 ou superior. No PrestaShop 8, a personalização do carrinho requer um módulo PHP 8 para ser compatível com o PrestaShop 9. No PHP 7, o módulo não está instalado e uma loja que já o possui não copiará essa personalização ao atualizar.
• O Redsys sempre assina com o próprio código do módulo, exatamente o mesmo byte a byte da biblioteca oficial. apiRedsys.php. Se uma loja deixou esse arquivo na pasta, ele não é mais usado e as assinaturas não mudam.
• Pequenas correções encontradas durante a análise: as notificações de pagamento via webhook do Stripe exibiam um identificador vazio no log, os valores dos planos do Stripe criados manualmente eram enviados em centavos inteiros e o código obsoleto foi removido dos períodos de teste do Stripe e das regras do carrinho no cron job. Observações técnicas:
• stripe/stripe-php 15.0.0 por Compositor (composer.json e composer.lock no diretório raiz, carregue automaticamente sem preceder o do PrestaShop). A atualização exclui a cópia anterior de classes/gateways/stripe/fornecedor.
• PHP CS Fixer com regras do PrestaShop em todo o módulo. Assinaturas divididas em várias linhas são combinadas em uma só: a vírgula após o último parâmetro não compila em PHP. 7.4.
• Validador de complementos (envio 3780321): 0 em todas as seções, exceto em "Uso obrigatório de PaymentOption", um falso positivo que aparece em todas as seções. Módulo de Pagamento (também no oficial) ps_retirada na loja; ver addons.md).
• Testado em 9.0.0 (instalação limpa a partir de ZIP, telas em modo de depuração), 9.2 (atualização de 5.9.0, (pedidos com SEPA e Stripe, cron, back-office) e 8.2.8 (Instalação do zero, substituições PS 8 e pedidos por) validarPedido).

21/10/2026
v5.9.0

[destacado]

• O PayPal foi incluído como uma quarta opção de pagamento., Além do Redsys, Stripe e débito direto SEPA, o cliente paga via PayPal. Se o carrinho incluir uma assinatura, o PayPal salva a conta do cliente para renovações, que o módulo cobra automaticamente em cada data de renovação, sem que o cliente precise retornar. Funciona da mesma forma que com o Redsys: data e valor de renovação editáveis, opção de pausa, tentativas de pagamento com falha usando o endereço de e-mail do cliente e um link para alterar a conta do PayPal, além de previsão de pagamento. O período de teste gratuito apenas autoriza a conta; nenhuma cobrança é aplicada. A ativação é feita em Configurações → Pagamento com credenciais do aplicativo PayPal (sandbox ou produção). O botão "Experimentar PayPal" verifica as credenciais e se o aplicativo tem o recurso de salvamento de conta (Cofre) ativado; caso contrário, as renovações não serão processadas.
• Se o cliente pagar via PayPal e não retornar à loja, a tarefa agendada (cron job) coleta o pagamento e cria o pedido; um pagamento que o PayPal deixa pendente permanece com o status "Aguardando pagamento do PayPal" até ser concluído.
• Remova todos os resquícios do módulo original: licença de terceiros e política de personalização, manual desatualizado e código que se comunicava com outros módulos de pagamento de terceiros (carteira digital, WePay, Adyen e outro módulo do PayPal) que uma loja que utiliza este módulo não usa mais. A licença agora é AFL 3.0 para os módulos de Rekire.
• Manual próprio em espanhol e inglês (README_ES.md, , README_EN.md e seus PDFs em documentos/), que substitui o antigo: passarelas, coleções fracassadas, cron e o dia a dia.
• Nos detalhes de uma assinatura Stripe com pagamentos, o modo de depuração do PrestaShop retornou um erro 500. Observações técnicas:
• Cabeceiras com @copyright Nos arquivos que não o continham, os valores previstos e os montantes de renovação escaparam nos modelos e fora do retornar; Lacunas no gateway. O que o validador de complementos (biblioteca Stripe) continua sinalizando. fornecedor/, O estilo do PHPStan e do PHP CS Fixer já estava presente. 5.7.0 e é tratado separadamente.
• O PayPal foi testado no ambiente de testes (sandbox) até o ponto de redirecionamento do comprador (chaves, Vault, pedidos, finalização da compra). A aprovação do comprador, o pedido resultante e as renovações com a conta salva não foram totalmente testados: foi realizado um pedido de teste no ambiente de testes antes de migrar para uma conta real.
• As chaves primárias das tabelas de assinatura ainda são chamadas de id_semana_* (id_wk_subscription_products, , _assinantes, , _produtos_para_assinantes, , _pedidos, , _agendar, , _temp_cart, , _cacheRenomeá-los requer um ALTERAR TABELA Com assinaturas ativas e cerca de 300 referências, uma atualização superficial deixaria a loja sem condições de receber pagamentos, e o lucro seria meramente simbólico. Não haverá alterações.
• RkrProductSubscriptionGlobal::isWkPayPalRecurringEnabled() e isWkAuthorizeNetEnabled() Eles permanecem, sempre em falso, porque as substituições de Controlador de Pedidos São os modelos já instalados nas lojas. Não há mais necessidade de novas configurações.
• A aba do contêiner do menu vai de Módulo AdminWkSubs para AdminRkrSubsMódulo; A atualização também renomeia suas permissões (função_de_autorização), portanto, os perfis dos funcionários o retêm. Atualizações mais antigas (5.4.6, , 5.4.35Eles continuam se referindo à turma antiga porque estão à frente da mudança.
• A atualização exclui os arquivos deixados por versões anteriores (o upload de um arquivo ZIP por cima deles não exclui nada) e remove o gancho antigo. actionWkSubscriptionCancelar.

17/10/2026
v5.8.0

[destacado]

• Pagamentos falhados: o módulo tenta novamente e notifica o cliente. Quando um pagamento de renovação falha, o sistema tenta novamente de acordo com um cronograma configurável (por padrão, 1, 3 e 7 dias depois), em vez de usar todas as tentativas em três execuções cron consecutivas. Após cada tentativa falha, o cliente recebe um e-mail com a data da próxima tentativa e um link seguro para adicionar outro cartão, gratuitamente, nessa página (Redsys ou a página do Stripe). Se todas as tentativas forem esgotadas, a assinatura é pausada (ou cancelada, ou mantida como está: isso pode ser selecionado em Configurações → Pagamento → "Pagamentos Falhos") e, assim que o cliente adicionar um novo cartão, a assinatura é retomada e o saldo devedor é cobrado.
• Faturamento do Stripe: O Stripe gerencia as novas tentativas; o módulo notifica o cliente com o link de pagamento e reflete a decisão do Stripe (cancelar ou deixar como não pago). O webhook registrado é atualizado automaticamente com novos eventos.
• SEPA: Na seção "Pagamentos SEPA", há um botão "Devolvido" com o motivo da devolução informado pelo banco. O pagamento devolvido é reenviado no próximo lote, exceto quando não puder ser processado corretamente (conta incorreta ou encerrada, sem autorização, devedor falecido), e o cliente recebe uma notificação.
• O painel de detalhes de cada assinatura exibe as tentativas de pagamento falhas, a próxima tentativa, um link para o cliente e os botões "Tentar novamente" e "Limpar tentativas". A previsão de faturamento mostra as tentativas de reenvio até a data atual.
• A Redsys cobrou o primeiro pagamento no cartão, mesmo que o cliente o tivesse alterado. (por exemplo, a partir do aviso de validade) ou a loja o teria removido. Agora envie o cartão ativo.
• A tarefa cron parava sem aviso prévio em lojas com alguns módulos. que contabilizam os produtos no carrinho ao criá-lo: a renovação foi dada por "carrinho vazio" e a compra terminou sem que o pedido fosse criado.
• A página seguinte, após a troca do cartão, exibe o design da loja.

16/10/2026
v5.7.1

Atualização de versão 5.7.1.

16/10/2026
v5.7.0

• O módulo inclui Redsys, Stripe e débito direto SEPA. Não é mais necessário instalar um módulo de pagamento separado para receber pagamentos de assinaturas: em Configurações → Pagamento, há um bloco para cada gateway de pagamento com seu botão de ativação/desativação, configurações e um botão "Testar" que verifica as chaves com o banco ou o Stripe. O Redsys salva os dados do cartão para a primeira compra e processa as renovações sem a presença do cliente; o Stripe oferece suporte à página de pagamento do Stripe ou ao formulário dentro da loja e renova as assinaturas usando o Stripe Billing ou via cron com os dados do cartão salvos; o SEPA coleta o mandato no pedido, envia a pré-notificação e gera a solicitação de pagamento (pain.008) para o banco a partir do back office.
• Assistente de imigração. Uma loja que já utiliza os módulos independentes (rkrredsyspayment, rkrstripepayment, rkrsepapayment) pode trazê-los para cá com um único botão: o sistema copia cartões, mandatos, pagamentos, assinaturas e configurações do Stripe, reutiliza os status dos pedidos, move o webhook do Stripe e desativa o módulo independente sem excluir nada. Essa ação pode ser desfeita com outro botão. Até que a migração seja concluída, tudo permanece igual.
• As renovações SEPA estão "Aguardando remessa". até que o banco efetue o pagamento. Anteriormente, o status que o cron publicava sobrescrevia o status do pagamento, e os valores apareciam como pagos.
• Reinstalar por cima dos dados de uma versão anterior. Agora não deixa mais colunas sem criar (antes exibia "Coluna desconhecida" ao salvar um produto).
• A desinstalação também preserva os cartões salvos, os mandatos e as assinaturas do Stripe, assim como os assinantes já haviam sido preservados.
• Pronto para Addon: Sem chamadas de núcleo obsoletas ou HTML dentro do PHP, sem avisos no modo de depuração do PrestaShop 9 e com o mesmo nome e descrição em config.xml. Testado no PrestaShop 8.2, 9.0, 9.1 e 9.2.

16/10/2026
v5.6.1

Atualização de versão 5.6.1.

16/10/2026
v5.6.0

Atualização de versão 5.6.0.

16/10/2026
v5.5.5

• O preço de renovação mostrado no cartão não era o preço efetivamente cobrado. Um produto com "Preço de Renovação" (por exemplo, um módulo com um ano de suporte incluído e, em seguida, uma taxa anual mais baixa) costumava exibir "Preço por período: € 12,09" e "Este valor será cobrado a cada período", embora um valor diferente seja cobrado a partir da segunda renovação. Agora, o bloco exibe ambos: "Primeiro ano: €12,09" e "A partir do segundo ano: € 3,03/ano", com a etiqueta fiscal correspondente e um aviso de que o preço da renovação será cobrado após o primeiro pagamento. As etiquetas mudam frequentemente quando outro plano é selecionado ("Primeiro mês", "A partir do segundo mês").
• O carrinho de compras, a página de confirmação e o e-mail de cadastro também indicam isso. A linha do carrinho de compras exibe "Assinatura, renova-se anualmente por € 3,03". A confirmação do pedido não se refere mais ao primeiro pagamento como "Valor por renovação", e o e-mail de assinatura adiciona "Cada renovação: ..." abaixo do total. O cálculo é feito como um pagamento automático: primeiro, o valor definido manualmente para aquela assinatura e, se não houver um valor definido, o preço de renovação do produto.
• O raio de "Assinatura" e "Compra única" está alinhado com seu rótulo., E em dispositivos móveis, ele não fica mais apenas em uma linha acima do texto.
• O texto no bloco, no carrinho de compras e nas mensagens de confirmação foi traduzido para francês, italiano, alemão e português, embora o texto original fosse inglês. A frase "renovação anual" no carrinho de compras também estava em espanhol.

16/10/2026
v5.5.4

• Com o recurso de envio aprimorado do PrestaShop ativado, o pedido misto não foi criado. O PrestaShop 9.1 e 9.2 incluem a opção beta "improved_shipment" (múltiplos envios por pedido, desativada por padrão). Com essa opção ativada e vendas mistas (padrão e assinatura) habilitadas, o cliente pagava, mas o pedido não era criado: o módulo continuava enviando os produtos para o PrestaShop no formato anterior. Agora, ele cria um pedido para a assinatura e outro para os produtos padrão, cada um com seu próprio envio, e os custos de envio são cobrados apenas para o pedido da assinatura, como quando a opção está desativada; o total dos pedidos corresponde ao valor pago e o e-mail de confirmação lista os produtos em cada pedido. Com a opção desativada, e em 1.7.8, Nas versões 8 e 9.0, nada muda.
• Ao atualizar, o módulo copia seu override/classes/PaymentModule.php na loja.

15/10/2026
v5.5.3

• Pronto para PrestaShop 9.2. O módulo substitui a validação de pedidos do PrestaShop, e a versão 9.2 a alterou de três maneiras que o módulo agora também faz: ele compara com segurança a chave de segurança do carrinho (hash_igualAnexe a fatura ao e-mail de confirmação de acordo com a opção de status que solicita o envio da fatura em formato PDF e, caso o pedido esteja sendo enviado em várias remessas, especifique no e-mail qual transportadora está responsável por cada produto. 1.7.8, Nas versões 8, 9.0 e 9.1, a fatura e a transportadora permanecem como em suas respectivas versões do PrestaShop.
• Pedidos feitos por meio de outros módulos de pagamento perderam sua referência. Quando a venda mista (normal e por assinatura) está desativada, o módulo passa a validação para o PrestaShop sem a referência do pedido que alguns módulos de pagamento enviam, e o PrestaShop gera outra.
• O e-mail de confirmação pode cancelar o pedido no momento da finalização da compra. Se o pedido fosse validado diretamente na página de pedidos, o preço de cada linha do e-mail chegava ao módulo como uma lista e não como um objeto; com a depuração ativada, o aviso do PHP interrompia o pedido após sua criação e sem enviar o e-mail.
• Ao atualizar, o módulo copia seu override/classes/PaymentModule.php na loja.

07/10/2026
v5.5.2

• A lista de produtos verificava o cartão para ver se o produto possuía uma assinatura. Em uma categoria de 36 produtos, houve 180 consultas quase idênticas (do módulo de pagamentos, a substituição de Link e os próprios hooks), sem que nenhuma assinatura seja exibida. Agora, o módulo lê os IDs de assinatura da loja de uma só vez e responde à solicitação a partir da memória, e o bloco de preço aparece instantaneamente para produtos sem assinatura, sem carregar o produto ou traduzir nove strings. A memória é liberada ao criar, modificar ou excluir uma assinatura e é separada por loja, de modo que o comprador vê a mesma coisa de antes, com menos consultas.

29/09/2026
v5.5.1

• O preço do token não se alterou ao escolher outra frequência. O módulo solicitou via AJAX e escreveu em .preço-atual do tema, que não está disponível em muitas lojas: o próprio módulo oculta o preço do tema em produtos "somente por assinatura", e em https://rekire.com/pt/module/rkrtotaltranslator/urlstranslation substitui-o rkrdualprice. A resposta chegava, mas não havia onde anotá-la, então o cliente via o preço do catálogo independentemente da escolha. Agora, o bloco de assinatura é exibido. "Preço para cada período" O preço é calculado instantaneamente com base na opção escolhida. O preço de cada opção é calculado automaticamente no servidor usando o mesmo sistema que processa os pagamentos do carrinho, portanto, o que você vê é o que você paga — sem requisições ao servidor e sem dependência do tema. Com a opção "Compra Única", o item da compra fica oculto porque o preço normal do produto é utilizado.