Assinaturas Avançadas para WooCommerce 2.0.x

O desenvolvimento desta versão custou 4.360 euros. O custo da primeira versão foi de 38.000 euros. O custo acumulado desde a primeira versão é de 42.360 euros, mas o custo para você é apenas a licença a partir de 80€.

Nova ramificação 2.0.x do plugin Assinaturas Avançadas para WooCommerce. É uma versão maior: o plugin deixa de depender da extensão WooCommerce Subscriptions e estreia cobranças recorrentes automáticas nativas com Stripe, PayPal Payments e WooPayments, além de Redsys, que continua integrado ao próprio plugin.

Versões da ramificação

• 2.0.0

2.0.0

Importante:

• Esta é uma versão maior. Leia as notas de atualização antes de atualizar, especialmente se agora mesmo você cobra através do PayPal Standard.
• Esta versão requer WordPress 6.5 ou superior e WooCommerce 8.0 ou superior. O requisito anterior (WordPress 5.1, WooCommerce 5.1) nunca foi realmente testado, e ao testá-lo para esta versão foi verificado que o plugin não poderia funcionar lá. Os novos números são aqueles sobre os quais esta versão foi verificada.
• PayPal Standard deixa de ser suportado. O próprio WooCommerce desaconselha desde sua versão 5.5 e o bloqueia em novas instalações. Se agora mesmo você cobra as assinaturas com PayPal Standard, instale WooCommerce PayPal Payments e migre os métodos de pagamento de seus clientes antes de atualizar para a 2.0.0.

Novo:

• Pagamentos recorrentes automáticos com Stripe. As renovações agora são cobradas off-session sobre o cartão salvo do cliente usando o plugin WooCommerce Stripe Payment Gateway (é necessária a versão 9.8.0 ou superior). Não é necessária nenhuma extensão de pagamento Subscriptions.
• Pagamentos recorrentes automáticos com PayPal Payments. As renovações são cobradas através do token do cofre (vault) do PayPal usando o plugin WooCommerce PayPal Payments (é necessária a versão 3.0 ou superior). Não é necessária nenhuma extensão de pagamento Subscriptions.
• Pagamentos recorrentes automáticos com WooPayments. As renovações são cobradas off-session sobre o método de pagamento salvo do cliente usando o plugin WooPayments (é necessária a versão 7.0 ou superior). Não é necessária nenhuma extensão de pagamento Subscriptions.
• Armazenamento confiável do método de pagamento no checkout. Quando um cliente compra uma assinatura com Stripe, PayPal Payments ou WooPayments, o plugin garante que o método de pagamento fique salvo para as renovações, embora essas passarelas normalmente só o façam quando WooCommerce Subscriptions está ativo.
• Gestão de 3D Secure (SCA) nas renovações. Quando o banco solicita autenticação adicional em uma cobrança recorrente, a renovação é marcada como falhada com um motivo claro e pode-se avisar o cliente para que autorize a próxima tentativa.
• Tentativa automática de renovações falhadas. Quando um pagamento falha (cartão rejeitado, saldo insuficiente, autenticação requerida, etc.), o programador de tentativas reprograma automaticamente a próxima tentativa.
• Detecção de acordos de PayPal cancelados. Se um cliente cancela sua autorização de PayPal fora da sua loja, a próxima renovação o detecta, a assinatura passa para "em espera" e o método de pagamento salvo é marcado como inválido para que o cliente possa autorizar novamente.
• Verificação de segurança de moeda nas renovações. O plugin se recusa a cobrar uma renovação em uma moeda diferente da do pagamento original, evitando cobranças acidentais em moeda errada após uma mudança de moeda da loja.
• Mudança de método de pagamento entre passarelas. Os clientes podem mudar entre Stripe, PayPal Payments e WooPayments a partir da Minha conta, e a próxima renovação usa automaticamente o novo método.
• Novo ajuste de administração "Cancelar assinatura em reembolso total de um pedido de renovação", em WooCommerce > Ajustes > Assinaturas Avançadas > Configurações Avançadas. Desativado por padrão. Quando está desativado, um reembolso total apenas deixa uma nota na assinatura; quando está ativado, a assinatura é cancelada. Reembolsos parciais nunca cancelam.
• Os reembolsos do pedido do primeiro pagamento (o pedido pai) sempre cancelam a assinatura. É o que se espera naturalmente ao reembolsar a compra original, e é independente do novo ajuste de administração.
• Notas automáticas na assinatura sempre que uma renovação é reembolsada (total ou parcialmente), para que a cronologia da assinatura fique clara.
• Painel de compatibilidade de passarelas de pagamento na tela de ajustes do plugin (WooCommerce > Ajustes > Assinaturas Avançadas > Configurações Gerais). Mostra de relance se os plugins de passarela suportados estão instalados e ativos, e oferece links de instalação ou ativação com um clique quando não estão.
• Detecção de disputas e contracargos no Stripe e PayPal. Quando um cliente abre uma disputa, o pedido relacionado passa para "em espera" para que você possa reagir antes da próxima renovação.
• Detecção da remoção do método de pagamento no Stripe. Se o token do cartão salvo for excluído, todas as assinaturas que o utilizam são marcadas e passam para "em espera" para que o cliente possa salvar um novo método.
• Redsys aparece no painel de compatibilidade de passarelas como uma passarela incluída: viaja dentro deste plugin e nunca precisa de uma instalação separada.

Corrigido:

• Desativar WooCommerce não derruba mais o site inteiro. Até agora, se WooCommerce deixasse de estar ativo por qualquer motivo (você o desligava para revisar algo, falhava uma atualização ou dava um erro próprio), este plugin continuava tentando usá-lo e derrubava todas as páginas do site, incluindo a administração do WordPress, sem outra volta a não ser o FTP. Agora o plugin detecta que WooCommerce não está, não faz nada de forma silenciosa e mostra um aviso explicativo na administração. Ao reativar o WooCommerce, tudo é restaurado sem nenhuma ação adicional.
• As renovações podiam ser programadas no momento errado, ou não programadas, em lojas cuja zona horária está configurada como desfasagem UTC em vez de como cidade. A correção afeta como a zona horária do site é lida ao calcular quando vence um pagamento programado.
• Um pedido cancelado não deixa mais uma assinatura fantasma. Se um pagamento falhava e a tentativa do cliente gerava um NOVO pedido em vez de retomar o primeiro (algo que ocorre quando se perde a sessão ou muda o carrinho), a assinatura não paga do pedido abandonado ficava para sempre na conta do cliente. Nunca era cobrada e não podia ser ativada, mas o cliente via uma assinatura que nunca havia pago. Cancelar esse pedido agora a elimina. As assinaturas já ativas nunca são tocadas: cancelar um pedido de renovação deixa a assinatura em andamento, como deve ser.
• Excluir o plugin agora limpa o que é seu. Até agora, remover o plugin deixava tudo para trás: suas configurações, seus bloqueios de pagamento e —o que tinha consequências visíveis— suas tarefas programadas, que o WordPress continuava tentando executar mesmo que não houvesse nada instalado que as atendesse, falhando e reintentando indefinidamente. Ao desinstalar agora, as configurações próprias do plugin são removidas e suas tarefas programadas são canceladas. Deliberadamente NÃO são excluídas suas assinaturas, seus pedidos ou quaisquer dados de clientes: são registros de negócios, permanecem no banco de dados, e ao reinstalar o plugin voltam exatamente como estavam.
• Excluir o plugin em um site que nunca teve WooCommerce não preenche mais o log de erros. A limpeza buscava tarefas programadas em uma tabela que o WooCommerce nunca havia criado, o que produzia um erro de banco de dados para cada grupo de tarefas do plugin. Nunca foi fatal (a limpeza terminava igualmente e as mensagens só apareciam com a depuração ativada), mas em uma rede multisitio se repetia em cada site. A limpeza continua funcionando exatamente igual; apenas as mensagens inúteis são silenciadas, e unicamente em um site onde essa tabela realmente falta.
• Produtos variáveis com uma mistura de variações de assinatura e de não assinatura: comprar uma variação que NÃO é uma assinatura não salva mais o cartão do cliente nem cria uma assinatura. O plugin decidia se uma variação era de assinatura olhando a configuração do produto pai e ignorava completamente a caixa "Assinatura" da própria variação, assim que em um produto variável onde apenas algumas variações são assinaturas, todas se comportavam como tais. Uma variação sem configuração própria continua herdando a do pai, de modo que um produto que você acabou de marcar como assinatura continua funcionando até que você configure suas variações.
• Uma assinatura configurada para renovar manualmente já não é cobrada automaticamente. Entre a renovação programada e o gateway de pagamento não havia nada que verificasse se o cliente tinha solicitado pagar manualmente, e ao pedido de renovação —que para as renovações manuais é criado deliberadamente sem método de pagamento— era preenchido um a partir do pedido original pouco antes da cobrança. As renovações manuais agora são interrompidas em ambos os pontos, e qualquer tentativa automática pendente sobre elas é limpa.
• Definir a data de início de uma assinatura a partir da tela de administração já não provoca um erro fatal. A tela chamava um método de escrita de datas que não existia no objeto de assinatura, então em qualquer loja sem a extensão WooCommerce Subscriptions o salvamento falhava com "Chamada a método indefinido". O fluxo de pedidos com data de início falhava igualmente por um segundo método inexistente. Ambos estão agora implementados sobre o armazenamento de datas próprio do plugin; uma assinatura à qual nunca foi escrita uma data de início continua a informar a data de criação do seu pedido, exatamente como antes.
• Produtos variáveis: as configurações de assinatura por variação nunca apareciam ao marcar uma variação como assinatura. A tela de edição de produto solicitava o script carregador sem minificar independentemente da configuração SCRIPT_DEBUG, então nas instalações que apenas incluem o recurso minificado retornava um 404 e o painel de campos —que permanece oculto até que esse script seja executado— não chegava a aparecer.
• Os e-mails de notificação de assinatura disparados diretamente através da API Scheduler do plugin agora são enviados. A API aceitava um tipo de notificação e o passava adiante, mas a função que havia por trás não declarava esse parâmetro, então o PHP o descartava e o tipo chegava vazio: nenhum e-mail era enviado e o evento de notificação não indicava tipo algum. As notificações lançadas pelo programador em seus próprios hooks não estavam afetadas.
• Uma data de primeiro pagamento definida a partir da tela de administração da assinatura agora é cobrada. A ação programada era criada com o nome de hook do WooCommerce Subscriptions, que este plugin não escuta, de modo que o pagamento simplesmente nunca era executado em lojas sem essa extensão. A ação agora é programada no hook de renovação próprio do plugin e no mesmo grupo que o resto das ações de pagamento, então cancelar, pausar ou excluir a assinatura a remove como se espera. O nome de hook antigo continua a ser programado em paralelo para as lojas que dependiam dele, e pode ser desativado com o filtro aswc_start_date_schedule_legacy_payment_hook.
• Alterar uma data de primeiro pagamento já programada agora move esse pagamento em vez de adicionar um segundo.
• A integração com os blocos de Carrinho e Pagamento já não desaparece em sites que funcionam com SCRIPT_DEBUG ativado. Apenas o script minificado era distribuído, então o caminho sem minificar que o WordPress pede nesse modo retornava um 404 e toda a integração deixava de carregar silenciosamente, levando consigo o controle "Ver Produtos Anexados" das caixas de assinatura e os anúncios falados do total recorrente. Agora ambas as versões são geradas a partir do mesmo código fonte.
• As tabelas de descontos das páginas de produto agora carregam sua folha de estilos e seu script nos temas clássicos. Os recursos eram resolvidos a partir do produto que estava sendo renderizado no loop, que ainda não estava disponível quando um tema clássico enfileirava os scripts, então nesses temas a tabela aparecia completamente sem estilos e a atualização de descontos dos produtos variáveis não era executada. Os temas de blocos não estavam afetados.
• Gateway Redsys incluído: os pedidos de assinatura agora são detectados corretamente no checkout, de modo que se solicita a Redsys o token de cartão recorrente (COF) e as renovações podem ser cobradas automaticamente.
• Gateway Redsys incluído: o cartão de assinatura guardado aparece agora em Minha conta > Métodos de pagamento (etiquetado como "Assinatura"). O filtro de métodos de pagamento guardados a ocultava ao ser executada fora do contexto de checkout.
• Gateway Redsys incluído: guardar o token da assinatura já não aborta a notificação de pagamento quando o banco não retorna o número do cartão mascarado (Ds_Card_Number); um marcador seguro dos últimos quatro dígitos é armazenado para que a tokenização e as renovações automáticas continuem funcionando.
• Ponte de PayPal: o contêiner de serviços do plugin oficial é obtido agora através da ação real de arranque de PPCP (com uma alternativa direta), de modo que os cobranças de renovação funcionam. A busca anterior dependia de um filtro que não existe no WooCommerce PayPal Payments.
• Ponte de PayPal: as cargas úteis dos webhooks já não são processadas quando a verificação de assinatura do PayPal rejeitou a solicitação, o que fecha um vetor de manipulação não autenticada do estado de pedidos e assinaturas.
• Ponte de PayPal: as cobranças de renovação seguem exatamente o manipulador oficial de renovações (apenas vault_id, sem o campo inválido stored_credentials) e o resultado da cobrança é lido da captura real, não apenas do estado do pedido do PayPal. As configurações com intenção de autorização são informadas com clareza em vez de serem marcadas como pagas sem capturar os fundos.
• Ponte de PayPal: os pedidos de renovação agora armazenam as metas oficiais do PayPal e o identificador de transação, de modo que os reembolsos a partir da administração do WooCommerce e as consultas de disputas funcionam sobre as renovações cobradas pela ponte.
• Ponte de PayPal: a disponibilidade do vault é lida do sistema de ajustes atual (com alternativa herdada), os tokens de Venmo e Apple Pay são enviados com sua payment source correta, e a marca de vault só é injetada no checkout quando guardar métodos de pagamento é realmente elegível.
• Ponte de PayPal: as gateways de PayPal são ocultadas no checkout para os carrinhos de assinatura com teste gratuito (total zero), que o PayPal não pode guardar no vault sem uma cobrança real nesta configuração.
• Ponte de Stripe: as exceções da API de Stripe durante as renovações são capturadas e registradas como falhas de pagamento, e cada cobrança de renovação envia uma chave de idempotência determinística, o que evita cobranças duplicadas quando uma solicitação expira e é reintenta.
• Ponte de Stripe: as renovações corretas agora armazenam o identificador de carga do Stripe como identificador de transação do pedido, de modo que os reembolsos e as disputas iniciadas a partir do painel do Stripe são associadas ao pedido correto.
• Ponte de Stripe: as renovações pagas com tokens de Stripe Link são cobradas com o tipo de método de pagamento correto, e a verificação da moeda original lê a moeda armazenada localmente em vez de chamar a API de Stripe em cada renovação.
• Ponte de Stripe: o suporte a SEPA é removido. O identificador da gateway SEPA herdada já não existe no Stripe 10.x e suas renovações nunca podiam ser cobradas; cartão e Link continuam totalmente suportados.
• WooPayments e Stripe: o método de pagamento agora é guardado de forma confiável no checkout de blocos (Store API). A detecção anterior nunca chegava a coincidir pela forma como o WooCommerce expõe o contexto de pagamento, e as assinaturas ficavam sem token para as renovações.
• O salvamento do método de pagamento já não duplica o cartão quando o cliente paga com um método de pagamento já guardado.
• Alterar o método de pagamento de uma assinatura com WooPayments ou Stripe agora tokeniza o novo cartão sem cobrar ao cliente. Antes, podia-se cobrar o valor total da renovação no momento da mudança.
• O checkout ativa e oculta automaticamente a caixa "guardar método de pagamento" nas gateways de cartão quando o carrinho contém uma assinatura, de modo que as compras com 3D Secure também terminam com um token guardado.
• Os hooks de pagamento das renovações agora verificam se o pedido ainda precisa de pagamento antes de cobrar (programador, pontes e a ação "retry payment" da administração), o que evita cobranças duplicadas em pedidos já pagos ou autorizados.
• Quando um método de pagamento guardado deixa de ser válido ou é removido, a assinatura afetada agora passa a "em espera" com uma nota explicativa, em vez de falhar silenciosamente na próxima renovação.
• As leituras de metadados em lojas sem HPOS podiam retornar a assinatura errada ou corromper os contadores de reintentos por um argumento incorreto passado para get_post_meta(); todas as chamadas corrigidas.
• Gateway Redsys incluído: a assinatura da resposta REST de renovação é verificada, as comparações de assinatura usam hash_equals(), as notificações são rejeitadas quando não há uma chave SHA-256 configurada, e foi corrigido um erro no manuseio da chave em modo de testes. Nota: as renovações cobram intencionalmente o token recorrente (R) mais recente do cliente; quando um cliente atualiza seu cartão, o novo token substitui o anterior para todas as suas cobranças recorrentes.

Segurança:

• A caixa de assinatura multiproduto agora decide seu próprio preço no servidor. A solicitação de "adicionar à assinatura" levava o total da caixa, e esse valor era armazenado como preço de linha do carrinho, então uma solicitação manipulada poderia comprar uma caixa por qualquer valor. O preço agora é derivado dos preços de produto da própria loja (ou do preço fixo configurado na caixa) e o valor da solicitação é ignorado.
• A caixa de subscrição multiproduto agora aceita apenas os produtos que realmente oferece. Tanto o pedido de adicionar como o de editar aceitavam qualquer ID de produto e devolviam o seu nome, preço e imagem sem verificar nem a configuração da caixa nem se o produto é visível publicamente, o que revelava preços de produtos em rascunho, privados e protegidos por palavra-passe a visitantes não identificados. As seleções agora são validadas contra a lista de produtos ou categorias da própria caixa e contra a visibilidade do produto.
• Salvar uma variação de produto agora exige a capacidade «edit products» por si só, além do seu nonce. Não era explorável antes, porque o WooCommerce só chega a esse manipulador após a sua própria verificação de capacidades; é defesa em profundidade na função que escreve.

Atualizado:

• Quando não é possível ler o fuso horário do site, o plugin agora o menciona no seu próprio log. Sempre seguiu em frente em vez de falhar, recorrendo ao desfasamento UTC do site e, na sua falta, ao próprio UTC. Fazer isso em silêncio significava que uma renovação cobrada a uma hora inesperada não tinha nada que a explicasse. O comportamento alternativo não muda; agora fica registado, e apenas quando realmente acontece.
• Limpeza interna: o plugin já não mistura os seus dados com os da extensão WooCommerce Subscriptions, evitando conflitos quando ambos os plugins coexistem no mesmo site.
• Documentação para desenvolvedores atualizada. A referência de hooks cobre agora todas as ações e filtros novos que introduzem as pontes de pagamento (ver docs/hooks-reference.md).
• Passarela Redsys incluída: o registo migra da API obsoleta WC_Logger::add() para o logger moderno, e o identificador de módulo nos logs agora reflete este plugin (Advanced_Subscriptions_Redsys) em vez do gateway independente Redsys Light.

Compatibilidade:

• Testado até WordPress 7.1 e WooCommerce 11.1.0.
• Requer WooCommerce Stripe Payment Gateway 9.8.0 ou superior para a ponte de Stripe.
• Requer WooCommerce PayPal Payments 3.0 ou superior para a ponte de PayPal.
• Requer WooPayments 7.0 ou superior para a ponte de WooPayments.
• Totalmente compatível com o armazenamento de pedidos de alto desempenho do WooCommerce (HPOS).
• O plugin já não depende da extensão WooCommerce Subscriptions. Funciona de forma autónoma.