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 habilidades: 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 através de 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 paradas em input-required).
- Limites por habilidade: 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. São suportados 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 começarão 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 em descobrir 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 padrão. O formulário online introduzido em 30.4.1 agora é opcional através de um filtro.
Corrigido:
- [Crítico] As renovações de assinaturas 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 assinatura, fazendo com 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 da Redsys.
- As renovações de assinatura 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 salvo, cache de assinatura, estado de OAuth, estado temporário de IMAP, etc.) agora é armazenado de forma que funcione 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 era 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íam 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 coincidia e o carrinho caía 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 a 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 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, de modo que o payload "REST trataPeticion" podia ser registrado (ou ignorado) independentemente da configuração 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 para o 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 a Redsys. A cobrança real a partir do modal é realizada através da API REST (trataPeticionREST), e essa solicitação não incluía o parâmetro DS_MERCHANT_PRODUCTDESCRIPTION, fazendo com que a "Descrição da Redsys" configurada (por exemplo, "ID do Pedido") chegasse vazia ao painel da Redsys. A descrição agora é calculada a partir da configuração selecionada e enviada na solicitação REST.
31.0.2
Segurança:
- A chave secreta SHA-256 do comércio não é mais escrita em texto plano nos registros de depuração do WooCommerce. Todas as entradas de depuração agora mascaram a chave, mostrando apenas os últimos 4 caracteres, através do novo helper WCRed()->mask_secret(). Aplicado em todos os 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) da Redsys agora são verificadas com hash_equals() (comparação em tempo constante) em todos os manipuladores de notificações, unificando-as 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 gerenciamento de tokens agora requer a capacidade manage_woocommerce além do nonce, igualando-o ao manipulador de exclusão em massa.
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 possam 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 multimoeda poderia ser rejeitado pela Redsys com um erro de moeda. A solicitação era enviada com a moeda da sessão do cliente (por exemplo, ARS, 32) mas com o terminal 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 solicitação para outro terminal, agora é enviada a moeda base da loja, sempre coincidindo com a configuração do terminal padrão.
- Adicionar um cartão a partir da Minha Conta (ou através do link de email do perfil) sempre registrava o cartão na Redsys como one-click (DS_MERCHANT_COF_TYPE 'C'), mesmo quando o cliente selecionava a opção de assinaturas. O tipo de token era lido da chave interna errada, então nunca era enviado 'R'. O token era salvo corretamente como R no WooCommerce, mas o acordo COF era criado como C na Redsys, o que poderia fazer com que alguns emissores rejeitassem renovações de assinatura posteriores (MIT) feitas com esses tokens. Os cartões adicionados com a opção de assinaturas 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 realizados com um cartão salvo (token R) e as renovações de assinatura não respeitavam as configurações 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 igualmente marcado como "Pré-autorizado", de modo que confirmar a pré-autorização mais tarde falhava na 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 renovações de assinatura pré-autorizadas (por exemplo, bens vendidos a peso, onde cada renovação é ajustada antes da cobrança final).
31.0.3
Novo:
- Seção "Apps e Plugins" dentro da Redsys Avançado -> Ajustes Avançados da Redsys. Uma página de aterrissagem somente leitura que mostra o app nativo de gerenciamento para macOS (com download, requisitos e plataformas "em breve") e lista o restante dos plugins gratuitos e premium, sites e portais, skills de Claude e perfis de desenvolvedor de José Conti, cada um agrupado por tipo com um link. Cada lista é filtrável (redsys_apps_plugins_mac_app, redsys_apps_plugins_free, redsys_apps_plugins_premium, redsys_apps_plugins_webs, redsys_apps_plugins_skills, redsys_apps_plugins_profiles).
Segurança:
- Removido um bypass de verificação de assinatura de notificação que poderia permitir que uma solicitação anônima marcasse um pedido como pago quando o segredo SHA-256 era deixado vazio ou mal configurado. O listener de IPN da Redsys (endpoint público wc-api) tinha um fallback herdado que, quando não havia segredo configurado, aceitava uma notificação apenas porque o Ds_MerchantCode enviado coincidia com o FUC do comércio, um valor público e não secreto que um atacante pode fornecer. Essa aceitação baseada apenas no código do comércio foi removida de todos os gateways (Redireção, Bizum, Bizum InSite, Google Pay checkout e redireção, Apple Pay, PayGold, Domiciliação Bancária, MasterPass e Transferência Bancária): quando não há segredo para verificar o HMAC, a solicitação agora falha de forma segura (rejeição HTTP) em vez de ser confiável. Além disso, a rotina de verificação compartilhada (WooRedsysAPI::verify_signature_notif) agora retorna false sempre que a chave do comércio ou a assinatura recebida estão vazias, de modo que nem check_ipn_request_is_valid() nem successful_request() possam completar um pagamento com um HMAC de chave vazia calculável pelo atacante. InSite já exigia uma assinatura válida (sem fallback por código de comércio) e Inespay não é afetado (relaciona os pedidos pelo seu próprio id de payin). As lojas reais não são afetadas, porque ter um segredo configurado é obrigatório para poder cobrar.
Corrigido:
- As notificações de Bizum eram rejeitadas com um erro de verificação de assinatura, deixando o pedido sem pagamento, embora o pagamento tivesse sido autorizado na Redsys. A chave do comércio e o número do pedido estavam corretos (a assinatura da solicitação coincidiu perfeitamente), mas a assinatura da notificação é um HMAC calculado sobre a string Ds_MerchantParameters exatamente como é recebida, e as notificações de Bizum chegam com o preenchimento (padding) final "=" de base64 removido, enquanto a Redsys assina sobre o valor com o padding canônico, então o HMAC calculado localmente nunca coincidiu. A rotina de notificação compartilhada (create_merchant_signature_notif em WooRedsysAPI) agora re-preenche o payload para um múltiplo de quatro antes de hashear, e a verificação (verify_signature_notif) agora compara ambas as assinaturas ignorando o padding final "=" (que não aporta entropia, então a comparação continua sendo em tempo constante). Os payloads de cartão já são canônicos e permanecem intactos, de modo que o restante dos gateways continua funcionando sem alterações. Essa rotina é compartilhada por todos os manipuladores de notificação (Redireção, Bizum, InSite, PayGold, Google Pay, Apple Pay, Domiciliação Bancária, Transferência Bancária e os clientes REST/A2A).
- As notificações de cartão e wallet podiam ser rejeitadas com um "signature mismatch", de modo que o cliente que voltava à página de agradecimento (e o IPN servidor a servidor) não conseguia marcar o pedido como pago até que uma nova tentativa posterior de IPN tivesse sucesso por acaso; os reembolsos e os links de PayGold pagos mais tarde podiam ficar sem confirmação. Há dois problemas de padding envolvidos: além do padding do payload de Bizum anterior, a Redsys entrega a assinatura da notificação (Ds_Signature) em base64 URL-safe com o "=" final removido, enquanto a assinatura calculada localmente o mantém, então uma comparação estrita também falha para os pagamentos de cartão normais. A comparação tolerante ao padding vive em verify_signature_notif(), mas a maioria dos manipuladores continuava comparando a assinatura em linha com um hash_equals()/!== estrito que reintroduzia a sensibilidade. Agora todos os manipuladores delegam em verify_signature_notif(), de modo que a correção chega a todos: Redireção de cartão (ambos validadores de IPN e as verificações de resposta REST-SOAP de captura/reembolso), Bizum, Bizum InSite, InSite (IPN, successful_request e os dois validadores de resposta REST), PayGold, Google Pay (checkout e redireção), Apple Pay, Domiciliação Bancária, Transferência Bancária, MasterPass e o cliente REST de InSite. Regressão introduzida quando foram unificadas as verificações de assinatura por gateway em verify_signature_notif() com uma comparação estrita e sensível ao padding.
- As notificações de Bizum em lojas multimoeda / de dupla terminal (as que direcionam cada pedido para um terminal distinto através do filtro bizum_modify_data_to_send ou uma regra condicional) agora resolvem a chave de assinatura real por pedido antes de verificar a assinatura (a chave das configurações ajustada pelo cliente, o transient guardado quando o formulário de pagamento foi gerado, ou o meta de pedido _redsys_secretsha256), e uma notificação não verificável é rejeitada com HTTP 400.
- Os pagamentos com cartão do InSite que exigiam um desafio 3DS mostravam uma tela de verificação em branco no Safari (iPhone/Mac), de modo que o cliente não conseguia inserir o código SMS/PIN e o pagamento falhava (o mesmo fluxo funcionava no Chrome). O desafio em si já era uma navegação de página completa e de nível superior, mas antes dele o plugin redirecionava o navegador para a URL do Método 3DS do emissor (threeDSMethodURL) para capturar a impressão do navegador, e a Prevenção de Rastreamento Inteligente (ITP) do Safari bloqueia os cookies de terceiros que esse passo necessita, deixando uma página ACS em branco (sintoma: a URL do ACS chega com ";jsessionidpa=" porque os cookies não fluem). O passo do Método 3DS no navegador é opcional, então o plugin não redireciona mais o navegador para threeDSMethodURL: sempre envia threeDSCompInd = 'N' e continua diretamente para a autenticação. Aplicado a todos os fluxos do InSite – cartão novo e cartão salvo (one-click/token), tanto no checkout de blocos como clássico (shortcode) – e aos fluxos REST/token do gateway de Redireção (pay_with_token_c, receipt_page e successful_request), já que a mesma tela em branco poderia aparecer ao cobrar um token de cartão salvo.
- Quando um pagamento com cartão do InSite falhava porque faltava um campo obrigatório do checkout ou seus dados não coincidiam (por exemplo, um sobrenome vazio produzia um "signature mismatch"), a mensagem de erro culpava o cartão ("…volte a inserir os dados do seu cartão"), fazendo com que os clientes pensassem que seu cartão havia sido rejeitado e abandonassem o pedido. A mensagem agora é neutra e aponta primeiro para os campos do checkout: pede ao cliente que verifique se todos os campos do checkout (nome, sobrenomes, endereço, etc.) e os dados do cartão estão preenchidos corretamente antes de tentar novamente. Aplicado aos checkouts clássico e de blocos (Blocks).
- Os reembolsos e pagamentos diferidos de pedidos com IDs de pedido grandes (o "bug dos mil milhões" já corrigido para o checkout instantâneo) eram registrados contra o pedido errado, ou não eram registrados de forma alguma. A notificação (IPN) da Redsys recupera o ID do pedido do WooCommerce a partir do número do pedido através de clean_order_number(), que primeiro busca um transient salvo quando o número do pedido foi gerado e, na falta disso, recorria a uma heurística substr/ltrim que descarta os dígitos de ordem alta dos IDs com 10 ou mais dígitos. Esse transient tem um TTL de 1h, então o fallback era ativado sempre que a notificação chegava mais de uma hora depois de gerado o número do pedido: cada reembolso (processado dias ou semanas depois) e os links de pagamento do PayGold (pagos pelo cliente mais tarde), entre outros. Três mudanças o tornam robusto para todos os métodos de pagamento: (1) a rotina de reembolso compartilhada (ask_for_refund) agora volta a salvar o mapeamento número do pedido -> ID real do pedido no momento do reembolso com um TTL de 24h; (2) clean_order_number(), quando o transient já não existe, agora busca o pedido de forma inversa pelo meta persistido do número do pedido (_payment_order_number_redsys / _redsys_transaction_id2) antes de usar nunca a heurística com perda; e (3) PayGold agora persiste o número do pedido no meta quando cria o link, de modo que um link pago muito depois ainda se resolve para o pedido exato. Aplica-se a todos os gateways (Redireção, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold e Domiciliação Bancária). O Inespay não é afetado (relaciona os pedidos pelo seu próprio id de payin).
- Os pagamentos com cartão do InSite no checkout de blocos (Blocks) falhavam na PRIMEIRA vez com "msg18" (o cliente via "verifique se os campos do checkout/cartão estão preenchidos") e só funcionavam na segunda tentativa. O SDK do InSite da Redsys requer que a página envie uma mensagem "domain" para o iframe do cartão para que a Redsys possa validar o comércio; o SDK faz isso através de um onload="setMerchantDomain(0)" em linha no iframe. O script de blocos sobrescrevia esse manipulador com seu próprio iframe.onload (usado para dimensionar o iframe) logo após a primeira renderização, então o domínio do comércio nunca era enviado e a Redsys rejeitava a tokenização com msg18 ("validação incorreta por parte do comércio"). No refresco automático do formulário, a sobrescrita não era executada, então a segunda tentativa funcionava. O plugin agora chama setMerchantDomain explicitamente após construir o formulário (como faz a própria integração do botão de pagamento do SDK) e não sobrescreve mais o onload do iframe, de modo que a primeira tentativa funciona.
- Checkout de blocos do InSite: o manuseio do postMessage da Redsys foi tornado mais robusto e diagnósticos de extremo a extremo foram adicionados. O manipulador agora aceita mensagens de qualquer subdomínio da Redsys (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es) em vez de exigir uma correspondência exata de host/porta (a Redsys publica a partir de mais de um host), elimina qualquer listener deixado por uma renderização anterior para que um único token não possa disparar múltiplos envios, e limpa os campos de token/erro após lê-los para que um re-disparo obsoleto não possa reenviá-los. Quando o registro de depuração do InSite está ativado, todo o passo de tokenização do lado do cliente (número do pedido, postMessage da Redsys, token/código de erro, salvo e place-order) se reflete no log "insite" do WooCommerce, de modo que as falhas da primeira tentativa que nunca chegam ao PHP possam ser diagnosticadas.
- Os pagamentos com cartão do InSite no checkout de blocos (Blocks) eram rejeitados pela Redsys com SIS0574 ("operação de autenticação EMV3DS rejeitada, browserUserAgent não indicado"): a impressão 3DS do navegador (user agent, tamanho de tela, idioma, profundidade de cor, fuso horário) nunca chegava ao pedido, porque o hook que normalmente a copia para o pedido (woocommerce_checkout_create_order) não é executado no checkout da Store API (Blocks). O formulário do InSite de Blocks agora coleta a impressão e a envia junto com o token de operação, e é escrita no pedido real (junto ao token) antes que process_payment seja executado, de modo que a autenticação EMV3DS tenha os dados que precisa.
- Os pagamentos com cartão do InSite no checkout de blocos (Blocks) eram rejeitados com um "código de erro sem token" (mostrado ao cliente como "verifique se os campos do checkout/cartão estão preenchidos"), de modo que o cartão nem sequer podia ser tokenizado após algumas tentativas. Como o pedido ainda não existe no checkout de Blocks (id do pedido 0), o número do pedido da Redsys preparado era gerado a partir do id 0, o que produzia um valor quase constante – apenas ~999 números possíveis, todos terminados em nove zeros – e a Redsys rejeita um número de pedido reutilizado ("pedido repetido", SIS0051). Quando o id do pedido rascunho ainda não está disponível, o formulário do InSite de Blocks agora usa o mesmo número de pedido temporário que o checkout shortcode do InSite (create_checkout_insite_number: sempre começa por 1, globalmente único através de um contador incremental compartilhado), de modo que nunca colide; quando o id do pedido rascunho está disponível, o número da Redsys é construído a partir dele. O número é re-vinculado ao id real do pedido quando o pedido é realizado.
- Os pagamentos com cartão do InSite no checkout de blocos (Blocks) falhavam: o cliente via uma mensagem enganosa "verifique se os campos do checkout/cartão estão preenchidos" e o pedido nunca era pago (o console do navegador mostrava um 404 na solicitação save_order_data). A causa é que o WooCommerce atual já não cria o pedido até que o cliente pressione "Realizar o pedido" – durante a introdução do cartão, o store do checkout de Blocks retorna id do pedido 0 – então o token de operação do InSite (idOper) e o número do pedido da Redsys preparado não podiam ser persistidos: o fluxo anterior os enviava para uma rota REST (save_order_data) que tentava anexá-los ao pedido 0 e retornava "Pedido inválido" (404), e o número do pedido gerado era mapeado para o pedido 0 (de modo que nem mesmo uma notificação posterior podia encontrar o pedido). Agora, quando o cartão é tokenizado, o token e o número do pedido preparado são salvos na sessão do WooCommerce através de admin-ajax (a sessão do WC não está disponível em rotas REST personalizadas, razão pela qual a abordagem REST anterior não podia usá-la), e são transferidos para o pedido real enquanto o WooCommerce o cria a partir da solicitação do checkout (woocommerce_store_api_checkout_update_order_from_request), antes que process_payment seja executado, de modo que process_payment_block() encontra _insite_token e _payment_order_number_redsys como no checkout clássico. O transient do número do pedido também é re-mapeado ao id real do pedido para que a notificação (IPN) resolva o pedido. Os dados da impressão do navegador (3DS) já usavam essa mesma rota de sessão. O checkout clássico/shortcode não é afetado.
Desenvolvimento:
- Removida a saída de depuração barulhenta console.log dos scripts de frontend de produção (minificados): Apple Pay, Google Pay, capture-order-id e os modais de express-checkout. O script de Apple Pay Express em particular registrava em cada mudança do DOM (vigia todo o documento em busca de seu botão), o que inundava o console do navegador no checkout de Blocks. Os arquivos minificados agora removem console.log/console.warn/console.info/console.debug mantendo console.error; as fontes sem minificar permanecem inalteradas para desenvolvimento.
31.0.4
Corrigido:
- As renovações de assinatura (com qualquer plugin de assinaturas) agora respeitam o tipo de número de pedido da Redsys configurado e já não falham na nova tentativa com "número de pedido repetido" (SIS0051). Dois problemas foram corrigidos.
- O primeiro: a cobrança de renovação gerava o número de pedido da Redsys ignorando a configuração "Tipo de número de pedido" (redsysordertype/subfix); sempre recorria ao esquema aleatório padrão em vez do tipo configurado para o gateway, ao contrário do pagamento inicial do checkout. Agora, o gateway é passado para que as renovações respeitem o mesmo tipo de número de pedido que o checkout.
- O segundo: o número de pedido era mantido durante toda a vida do pedido, de modo que quando uma cobrança de renovação era rejeitada e o plugin de assinaturas tentava novamente sobre o mesmo pedido de renovação, exatamente o mesmo DS_MERCHANT_ORDER era reenviado e a Redsys bloqueava a nova tentativa legítima como duplicada. Agora, a distinção entre "fluxo" e "nova tentativa" é explícita: um único fluxo de pagamento (seu par iniciaPeticion/trataPeticion, os processos concorrentes de renovação e qualquer reexecução através do Action Scheduler de um processo que morreu no meio da cobrança) mantém o mesmo número de pedido para não cruzar Id Opers (SIS0502) e ser idempotente frente a cobranças duplicadas; mas uma vez que a Redsys confirma uma rejeição (uma resposta assinada sem código de autorização, ou seja, sem movimento de dinheiro), o número é liberado para que a próxima nova tentativa gere um novo e único respeitando o tipo configurado. O reinício ocorre SOMENTE diante de uma rejeição confirmada, nunca diante de erros de transporte ou de tempo de espera onde o resultado é desconhecido, de modo que uma reexecução por resposta perdida nunca pode duplicar a cobrança.
- Aplica-se aos gateways de Redireção e InSite e a todos os plugins de assinaturas que os utilizam (WooCommerce Subscriptions, Subscriptions for WooCommerce, YITH, WebToffee, SUMO, Advanced Subscriptions; Google Pay e Apple Pay delegam no gateway de Redireção).
- Como rede de segurança, quando não há um tipo de número de pedido válido configurado (vazio ou um valor herdado ou não reconhecido), o gerador recorre SEMPRE ao esquema padrão "3 dígitos aleatórios + zeros + id do pedido", o único que nunca colide nas novas tentativas. Nota: o tipo "número de pedido simples" não tem componente aleatório, portanto é incompatível por design com as novas tentativas de assinaturas e não deve ser usado quando há assinaturas ativas.
