O desenvolvimento desta versão custou 2.800 euros. O custo acumulado para este ano é de 13.350 euros. O custo acumulado desde a primeira versão é de 212.080 euros, mas o custo para você é apenas a licença de 79€.
Nova versão 31.0.0 do plugin Redsys para WooCommerce de WooCommerce.com.
31.0.0
Novo:
- Nova superfície do protocolo A2A (Agent2Agent). Opcional e desativada por padrão. Publica um Agent Card em /.well-known/agent-card.json e um endpoint JSON-RPC 2.0 em /wp-json/wc-redsys-a2a/v1/rpc com sete skills: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card e recurrent_charge. A autenticação reutiliza o servidor de autorização OAuth 2.1 + PKCE de UCP com scopes a2a:payments:* (e um bearer de sandbox opcional para testes sob WP_DEBUG).
- Stream de Server-Sent Events reanudável em /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream para atualizações de tarefas ao vivo, com reanudações mediante Last-Event-ID e batidas (heartbeats) a cada 15s.
- Notificações push de saída assinadas para uma push_url registrada pelo cliente. Cabeçalho X-A2A-Signature: sha256=<hmac> sobre <timestamp>.<body>, com reintentos a 1m/5m/30m/2h (máximo 4), entregues através do Action Scheduler.
- Nova aba de administração "A2A (Agent2Agent)" dentro de Redsys Avançado -> Agentic Commerce, com Estado / Clientes (criar / revogar / rotacionar bearers de sandbox) / Limites e modos (max_amount, sensitive_threshold e modos de pagamento expostos) / Confirmações (aprovar reembolsos ou cobranças recorrentes detidas em input-required).
- Limites por skill: max_amount é um limite máximo estrito que falha a tarefa com limit_exceeded; sensitive_threshold para a tarefa em input-required até que um administrador a confirme. Ambos sem limite por padrão (opcional).
- Registro de auditoria de apenas anexação (append-only) em wp_redsys_a2a_audit_log. Nunca são armazenados os payloads em bruto: apenas um hash SHA-256 mais um resumo saneado de uma linha que mascara PAN, tokens, segredos e a parte local dos emails.
- Armazenamento auto-reparável. As quatro tabelas A2A são recriadas sob demanda através do ensure_table() de cada loja, de modo que uma tabela excluída nunca provoque um erro fatal.
- Suporte para agentes de compra com IA (ChatGPT, Claude, Gemini, Perplexity e outros). Os agentes de IA agora podem descobrir seus produtos, montar carrinhos, completar pagamentos e receber atualizações de pedidos da sua loja. Suportam tanto o padrão ACP da OpenAI/Stripe quanto o padrão aberto UCP (apoiado pelo Google, Shopify e outros), e cada um pode ser ativado ou desativado de forma independente.
- Nova subseção "Agentic Commerce" dentro das configurações de Redsys Avançado, com interruptores por função (carrinhos, descontos, fulfillment, consentimento do comprador, registro dinâmico de clientes, etc.) e botões de um clique para testar os fluxos de descoberta de agentes, OAuth e webhook.
- Assinatura de webhooks com um botão "Rotacionar chave de assinatura". As chaves rotacionadas continuam válidas por 7 dias para que as integrações existentes continuem funcionando durante a mudança.
- O modal de campos personalizados de Express (Apple Pay / Google Pay) agora também coleta os campos registrados através da API de Blocks em checkouts clássicos, de modo que NIF/DNI e campos similares sempre aparecem independentemente do checkout que você usa.
- Ação em massa opcional "Aprovar pré-autorização" para a lista de pedidos (Redsys Redireção). Desativada por padrão por segurança; ative-a nas configurações da gateway apenas se precisar confirmar pedidos pré-autorizados em massa.
Nota:
- Ativar este suporte NÃO significa que os assistentes de IA vão começar a completar compras na sua loja desde o primeiro dia. O fluxo completo de checkout dirigido por agentes ainda está sendo implantado, especialmente na Europa, onde os requisitos de SCA/3DS, PSD2 e consentimento RGPD fazem com que a maioria dos agentes hoje pare na descoberta de produtos ou no pré-carrinho e devolvam o pagamento final ao cliente. Sua loja está pronta para o dia em que cada agente ative o fluxo completo no seu mercado.
Atualizado:
- O modal de campos personalizados de Express agora pré-carrega sua configuração ao carregar a página e inicia o Apple Pay de forma síncrona ao clicar, corrigindo os casos em que o iOS Safari abortava a folha de pagamento.
- Os campos personalizados de Express na página do produto voltam a usar o modal por padrão. O formulário online introduzido na 30.4.1 agora é opcional através de um filtro.
Corrigido:
- [Crítico] As renovações de subscrições podiam falhar com o erro Redsys SIS0502 ("Id Oper não coincide") em hostings com Redis, Memcached ou outros caches de objetos persistentes. Dois workers de renovação em paralelo podiam enviar duas referências de pedido distintas para Redsys para a mesma subscrição, provocando que a renovação falhasse e fosse reintentada muitas vezes. O bloqueio de pagamento duplicado e a referência de pedido agora são armazenados de forma confiável independentemente do backend de cache. Afeta as gateways de Redireção e InSite de Redsys.
- As renovações de subscrição de InSite não tinham nenhuma proteção de concorrência (o bloqueio era removido em erros, mas nunca era criado). Agora se aplica às renovações de InSite a mesma proteção que usa a gateway de redireção.
- O estado interno em cache usado durante o checkout (dados 3DS, identificador de cartão guardado, cache de assinatura, estado de OAuth, estado temporário de IMAP, etc.) agora é armazenado de forma que funciona corretamente em hostings com caches de objetos persistentes. Antes, em caches que se comportavam mal, esse estado podia desaparecer silenciosamente no meio do checkout e provocar erros SIS0502.
- Os botões Express de Apple Pay e Google Pay (checkout de blocos e página do produto) falhavam no iOS Safari com "Must create a new ApplePaySession from a user gesture handler" quando o modal de campos personalizados de Express estava ativado. O modal já não consome o clique do usuário antes de lançar o Apple Pay.
- O IRPF de Autônomos Premium estava sendo calculado incorretamente no Pagamento Express (Apple Pay / Google Pay) na página do produto quando o cliente escolhia o tipo de usuário no modal de Express, porque o salvamento do modal competia com a primeira chamada do servidor de Apple Pay. O tipo de usuário agora é enviado junto com cada requisição de Express Pay, de modo que os totais são sempre corretos.
- Em páginas de produto com produtos virtuais, a folha de Apple Pay mostrava brevemente o total correto (subtotal + impostos) e depois revertia ao preço do produto sem impostos. O callback de envio agora mantém o último total retornado pelo servidor.
- Ao salvar as configurações de Agentic Commerce, o envio "Salvar alterações" do WooCommerce era descartado silenciosamente devido a formulários HTML aninhados. A página de configurações foi reestruturada e todos os botões de ação única (testar descoberta, testar OAuth, ações de webhook, etc.) agora funcionam corretamente junto ao botão principal de Salvar.
- Os botões Express de Apple Pay e Google Pay na página do produto atribuíram a zona de envio incorreta quando a região do cliente estava restrita por província. Apple/Google Pay enviam o nome localizado do estado (por exemplo, "Barcelona") em administrativeArea, mas as zonas de envio do WooCommerce coincidem por código de estado (por exemplo, "B"); a zona país-por-estado não coincidiu e o carrinho caiu em uma zona mais cara (por exemplo, "Resto da Europa"). Os nomes de estado agora são normalizados para códigos de estado do WooCommerce antes da busca de zona de envio e da criação do pedido.
- O checkout de InSite com Blocos podia criar pedidos duplicados quando Redsys emitia o mesmo postMessage de token de pagamento mais de uma vez (ou quando o salvamento era executado de forma concorrente). Agora uma proteção evita a criação de pedidos duplicados/concorrentes e se reinicia se o formulário de pagamento for atualizado após um erro.
- O registro de depuração REST de InSite fazia referência ao objeto errado para ler o flag de depuração, portanto o payload "REST trataPeticion" podia ser registrado (ou ignorado) independentemente do ajuste de depuração da gateway. Agora usa o próprio flag de depuração da gateway.
31.0.1
Atualizado:
- A contagem regressiva do modal de Bizum na página de pagamento mostrava 7 minutos. Agora mostra corretamente 5 minutos, e o controle de tempo do lado do servidor que redireciona ao checkout foi ajustado em consequência (60 iterações * 5 segundos = 5 minutos).
Corrigido:
- Bizum na página de pagamento (Bizum InSite) não enviava a descrição para Redsys. A cobrança real a partir do modal é realizada através da API REST (trataPeticionREST), e essa requisição não incluía o parâmetro DS_MERCHANT_PRODUCTDESCRIPTION, portanto a "Descrição de Redsys" configurada (por exemplo, "Order ID") chegava vazia ao painel de Redsys. A descrição agora é calculada a partir do ajuste selecionado e enviada na requisição REST.
31.0.2
Atualizado:
- O filtro redsys_modify_data_to_send agora recebe 'context' => 'add_payment_method' e 'user_id' no array de dados para o fluxo de "Adicionar método de pagamento", de modo que os snippets personalizados e as regras condicionais podem direcionar a tokenização para o terminal correto (terminal + SHA256) sem depender de um pedido que não existe neste fluxo.
- Atualizadas todas as traduções.
Corrigido:
- Adicionar um cartão a partir da Minha conta ("Adicionar método de pagamento") em lojas multidivisa podia ser rejeitado por Redsys com um erro de moeda. A requisição era enviada com a moeda da sessão do cliente (por exemplo, ARS, 32), mas com o terminal por padrão, que está configurado para outra moeda (por exemplo, EUR, 978). A tokenização de cartão é uma operação de valor zero sem um pedido por trás, então se nenhum filtro ou regra condicional direcionar a requisição para outro terminal, agora é enviada a moeda base da loja, que sempre coincide com a configuração do terminal por padrão.
- Adicionar um cartão a partir da Minha conta (ou através do link do email de perfil) registrava sempre o cartão em Redsys como one-click (DS_MERCHANT_COF_TYPE 'C'), mesmo quando o cliente selecionava a opção de subscrições. O tipo de token era lido da chave interna errada, portanto nunca era enviado 'R'. O token era salvo corretamente como R no WooCommerce, mas o acordo COF era criado como C em Redsys, o que podia fazer com que alguns emissores rejeitassem posteriormente as renovações de subscrição (MIT) feitas com esses tokens. Os cartões adicionados com a opção de subscrições agora enviam corretamente DS_MERCHANT_COF_TYPE 'R'. Os tokens criados enquanto o erro estava presente não podem ser reclasificados; se uma renovação for rejeitada, peça ao cliente que adicione o cartão novamente.
- Os pagamentos feitos com um cartão salvo (token R) e as renovações de subscrição não respeitavam os ajustes de pré-autorização. Com "Pré-autorização de todos os pedidos" ativado (ou um produto marcado para pré-autorização), a cobrança era executada como uma venda normal (tipo 0), mas o pedido era marcado igualmente como "Pré-autorizado", de modo que confirmar a pré-autorização mais tarde falhava em Redsys com SIS0059 ("Não existe operação sobre a qual realizar a confirmação"). Ambos os fluxos agora enviam uma pré-autorização real de tipo 1 que pode ser confirmada depois, e um pedido só é marcado como "Pré-autorizado" quando uma pré-autorização real foi executada. Isso também habilita as renovações de subscrição pré-autorizadas (por exemplo, produtos vendidos a peso, onde cada renovação é ajustada antes da cobrança final).
Segurança:
- A chave secreta SHA-256 do comércio já não é escrita em texto plano nos registros de depuração do WooCommerce. Todas as entradas de depuração agora mascaram a chave, mostrando apenas seus últimos 4 caracteres, através do novo helper WCRed()->mask_secret(). Aplicado em todas as gateways (Redireção, InSite, Bizum, Google Pay, Apple Pay, PayGold, Domiciliação bancária e as classes de suporte de Blocks).
- As assinaturas das notificações (IPN) de Redsys agora são verificadas com hash_equals() (comparação em tempo constante) em todos os manipuladores de notificação, unificando-os com a verificação que já usavam InSite e o cliente REST. Endurecimento contra ataques de temporização (timing attacks).
- O manipulador AJAX de exclusão de um único token na tela de gestão de tokens agora requer a capacidade manage_woocommerce além do nonce, igualando-o ao manipulador de exclusão em massa.
