WooCommerce Redsys Gateway 32.1.x

O desenvolvemento desta versión custou 2.300 euros. O custo acumulado para este ano é de 37.430 euros. O custo acumulado desde a primeira versión é de 236.160 euros, pero o custo para ti é só a licencia de 79€.

Nova rama 32.1.x do plugin Redsys para WooCommerce de WooCommerce.com.

Versiones da rama

• 32.1.0

32.1.0

Novo:

• O informe de estado de WooCommerce (WooCommerce – Estado) lista agora tamén o que está activado na pestana “Ajustes avanzados” de Redsys: notificacións push, facturas secuenciais, códigos QR, tarxetas gardadas, sobreescritura de estados de pedido, regras condicionais, subscricións, conciliación por correo electrónico, os protocolos de comercio axente e a API da app de xestión. As credenciais non se imprimen nunca: de cada unha indícase unicamente se está configurada ou non. Inclúese ao copiar o informe para envialo a soporte, que é xusto o obxectivo: unha petición de soporte chega xa coa configuración dentro.
• Xa podes decidir se aos teus clientes se lles ofrece “Engadir unha tarxeta de crédito para Subscricións” en A miña conta – Métodos de pago. Ata agora esa opción aparecía soa en canto había un plugin de subscricións activo, sen maneira de quitala, e iso non é o que quere toda tenda: nunha tenda onde a tarxeta da subscrición se captura sempre durante a compra, o único que facía era invitar ao cliente a gardar unha tarxeta que nunca se ía cobrar. O novo interruptor está en Redsys – Ajustes avanzados – Tarxetas gardadas, vén activado para que nada cambie nas tendas que xa o ofrecían, e ao desactivalo queda soa a tarxeta de 1-click. Tamén se informa del no informe de estado de WooCommerce.

Seguridade:

• O plugin escribía no seu propio arquivo de rexistro a dirección da páxina de “pedido recibido” de cada compra, en todos os pagos, e esa dirección contén a clave do pedido: o testemuño privado que WooCommerce pon no enlace de pago do comprador e que este plugin esixe antes de mostrar un pedido. Calquera con acceso de lectura ao arquivo de rexistro podía, por tanto, abrir eses pedidos e ver o nome, o correo, o teléfono e as direccións que contiñan. Ocurría estivesen ou non activados o rexistro de depuración na tenda, porque ese punto concreto escribía no log sen comprobar ese axuste. Agora respecta o axuste de depuración como o resto de rexistros que escribe o plugin, e a clave substitúese por “[redacted]” antes de escribir nada, de modo que non queda rexistrada nin co log activado. Esa substitución aplícase despois a todas as liñas de rexistro do plugin, e non só á que se reportou: arredor de noventa liñas máis repartidas polas pasarelas imprimían esas mesmas direccións sempre que o rexistro de depuración estivese activo, incluídas as que volcan o mensaxe completo enviado ao banco. Os arquivos de rexistro xa escritos seguen contiñan esas direccións: se os tes, bórralos.
• A páxina que reenvía ao comprador a Redsys (e a Bizum) aceptaba calquera número de pedido escrito na súa dirección, sen comprobar que quen o pedía fose quen fixo ese pedido. Como os números de pedido son correlativos, alguén podía percorrelos e ler os datos que o plugin envía ao banco dos pedidos doutros clientes: nome, correo, teléfono e as direccións de facturación e envío, xunto co importe e a descrición do comprado. En ningún momento se expuxo un número de tarxeta, un código de seguridade nin unha clave de firma, e por esta vía non se podía pagar nin modificar nada. Esa páxina esixe agora a clave do pedido que WooCommerce inclúe no enlace de pago do propio comprador, de modo que unha petición que non corresponde ao pedido responde cunha páxina “Forbidden” en lugar de atenderse. A mesma comprobación engadiuse á ventá emerxente de pago da páxina de finalizar compra. Reportado polo equipo de seguridade de Tivify (TVUP Streaming Media), que describiu o problema con claridade e nos deu tempo para corrixilo antes de facelo público. Grazas.
• Os tres botóns de preautorización da pantalla de pedido (autorizar, anular e cobrar unha parte) e a busca de clientes de PayGold aceptaban as súas peticións sen un testemuño de seguridade. A comprobación de permisos xa estaba no seu sitio, así que só un xestor de tenda ou un administrador podía usalos e ninguén máis podería terlos executados, pero a un administrador coa sesión xa aberta podía enganar para disparalos desde outra web sen que se decatase. Os catro levan e verifican agora un testemuño de seguridade de WordPress, o que pecha esa vía.
• O Protocolo de Comercio Axente podía acabar activado sen que ninguén o elixira, en tendas que se actualizan automaticamente. Publica direccións coas que poden falar máquinas, así que está pensado para estar desactivado agás que o actives ti, e agora está. Se o tiñas activado, para ti non cambia nada.
• Actualizouse a biblioteca de Google incluída no plugin, o que corrige dous fallos na parte que realiza peticións de rede.

Actualizado:

• Quando falla a renovación dunha subscrición, a nota que se engade ao pedido di agora exactamente que paso fallou e con que código de comercio e terminal se fixo o intento. Ata agora os seis fallos posibles escribían a mesma nota, pouco informativa, o que facía case imposible diagnosticar unha renovación fallida sen acceso á tenda, especialmente en tendas onde non se está escribindo o log de depuración.
• Quando Apple Pay non consegue validar a tenda con Apple, o rexistro recolle agora a explicación da propia Apple e se os arquivos do certificado se poden ler. Apple responde cun xenérico “Expectation Failed” e pon o motivo real no corpo da súa resposta, que non se estaba rexistrando nunca, así que eses fallos eran un beirado sen saída.
• O plugin distribuído xa non contén os scripts de desenvolvemento e compilación do proxecto, a configuración do seu entorno de probas local, os seus directorios de editor e de hooks de git, o seu README para desenvolvedores nin un documento interno de revisión de seguridade. Nada diso chegaba a cargarse cando o plugin se executa, pero tampouco pinta nada no servidor dunha tenda. O que contén o paquete compróbase agora automaticamente, antes de cada publicación, contra unha lista do que o plugin realmente distribúe, de modo que algo que se engada ao proxecto no futuro non poida viaxar dentro do zip sen que ninguén se decate.
• A tarefa de conciliación por correo electrónico existe agora só mentres esa función está activada, e só unha vez. Antes creábase en todas as tendas e despertábase cada cinco minutos sen facer nada.
• Todas as traduccións volven estar completas. Sesenta e nove textos engadidos por versións recentes seguían aparecendo en inglés: etiquetas de axustes, o informe de estado e algúns mensaxes que pode ver un comprador. Español, catalán, euskera, galego, francés e portugués volven estar ao cen por cen.
• O testemuño que protexe o enlace de “engadir unha tarxeta” compárase agora en tempo constante, como o resto de segredos que compara este plugin. Cronometrar esa comparación a través de internet non é un ataque practicable, así que non había nada explotable; o defecto era a inconsistencia, porque esta era a única comparación que se quedou atrás cando se migraron as demais durante o traballo de sinaturas.

Arreglado:

• Con InSite, pagar cunha tarxeta que o comprador tiña gardada podía cobrar o diñeiro e a pesar diso mostrar o pedido como fallido. Cando o banco aproba un pago así sen pedirlle ao comprador que confirme coa app do seu banco, que é o que ocorre cunha tarxeta gardada, o plugin buscaba o resultado no sitio equivocado, non atopaba nada e trataba ese “nada” como un rexeitamento. O cargo xa se fixera, así que compradores aos que se lles dicía que o pago fallara pagaban unha segunda vez e cobraban dúas veces. O resultado léese agora da propia resposta asinada do banco, a mesma que xa usa o resto do pago. Afectaba por igual ao checkout clásico e ao de bloques, e tamén ás renovacións de subscricións. Reportado por dúas tendas con poucos días de diferenza, unha delas rastreándoo ata a liña exacta. Grazas.
• Na pasarela de tarxeta, un pago feito cunha tarxeta gardada dábase por completado só co número de autorización, sen comprobar a resposta real do banco que vai ao seu lado. Un pago rexeitado que a pesar diso levase algo nese campo marcaba por tanto o pedido como pagado, e a tenda enviaba a mercadoría sen ter cobrado. Agora exíxese que ambos coincidan antes de completar un pedido. Se a resposta do banco falta por completo, o pago non se completa, porque non queda nada que diga que foi aprobado; unha tenda cuxa banco omita realmente ese campo pode restaurar a propósito o comportamento anterior co filtro redsys_allow_payment_without_ds_response, que está documentado e que non se pode usar para aceptar un pago que o banco rexeitou.
• En tendas que usan certos plugins de finalizar compra, Fluid Checkout entre eles, todos os pagos eran rexeitados por Redsys co erro SIS0574. O banco esixe unha breve descrición do navegador do comprador con cada pago (o seu idioma, o tamaño da súa pantalla e similares), que o plugin recolle mediante campos ocultos que engade ao checkout. Eses campos engadíanse no momento en que se construía a pasarela de tarxeta, o que en esas tendas ocorre despois de que outro plugin xa pedira a WooCommerce a lista definitiva de campos do checkout, e WooCommerce constrúe esa lista unha soa vez e nunca máis. Os campos, por tanto, non se creaban, non se completaban e non se enviaban, e o banco rexeitaba o pago. Agora engádense en canto carga o plugin, antes de que ninguén poida pedir a lista, o que afecta a todas as pasarelas que os necesitan, a de tarxeta, Bizum e as wallets, e non só a InSite. En InSite a descrición do navegador viaxa ademais agora co resto dos datos do pago en lugar de depender só do pedido, de modo que sobrevive a un checkout que se reconstrúe a si mesmo. Reportado por un integrador que xa traía o diagnóstico demostrado. Grazas.
• Se un pago se cancelaba ou era rexeitado, o comprador volvía á tenda pero o pedido quedaba pendente e o carrito non se restauraba. A dirección que o plugin lle daba ao banco para devolver ao comprador estaba escrita na forma que se usa para os enlaces dentro dunha páxina web, non na que se usa para unha dirección real, así que a tenda recibía o retorno sen a referencia do pedido, sen o seu número e sen o seu testemuño de seguridade, e non tiña nada que cancelar. Afectaba a Bizum, Google Pay, Apple Pay, domiciliación bancaria, transferencia, InSite e á pasarela de tarxeta sempre que o axuste de “volver a” este posto en cancelar o pedido. En MasterPass esa mesma dirección enviábase directamente vacía, por un erro de escritura dun só carácter repetido en tres liñas. Todo pasa agora por unha única peza de código compartido, de modo que unha pasarela que se engada no futuro non poida volver a equivocarse.
• Na modalidade de pago en ventá emerxente (modal), cancelar un pago non facía nada e o comprador quedaba no carrito co pedido pendente. A dirección á que o plugin enviaba ao navegador escribíase na páxina dunha forma que o navegador interpreta como un enlace dentro dun documento e non como unha dirección web, así que todo o que ía despois do primeiro parámetro descartábase: a referencia do pedido, o seu número e o seu testemuño de seguridade desaparecían, e WooCommerce non tiña nada que cancelar. O mesmo defecto afectaba á dirección á que se devolve ao comprador despois de pagar, onde perdía en silencio un parámetro de seguimento. Os dous están corrixidos, na pasarela de tarxeta e na de InSite, e o comportamento corrixido verifícase nun navegador real.
• O checkout podía morrer cun erro crítico, en lugar de enviar ao comprador ao banco, cun cliente rexistrado cuxa ficha de cliente non se modificara nunca desde que se creou. O plugin constrúe un conxunto de datos de seguridade para o banco en cada pago, e un dos campos é a data na que se modificou por última vez a conta do cliente, que WooCommerce deixa baleira nunha conta que non se tocou nunca, normalmente unha creada por unha importación, unha migración ou automaticamente por outro plugin. O plugin leía esa data baleira como se fose unha data real e a páxina de pago detíñase aí. Agora recorre á data de creación da conta, que é o que significa “nunca modificada”, e a mesma protección engadiuse ao código equivalente que usan as subscricións, onde esa mesma data baleira se estaba reportando en silencio ao banco como “modificada hoxe”, que é información incorrecta para os seus controis de fraude.
• Redsys e as demais pasarelas podían desaparecer do checkout para todo o mundo, incluídos os compradores normais, en tendas onde a lista de “mostrar só a estes usuarios” do modo de probas non se completara nunca. O plugin leía ese axuste baleiro como “mostralo a un usuario cuxo id é nada”, que non coincide con ninguén, así que o método de pago quedaba oculto para todos os visitantes. Só afectaba a
  • tiendas cuxos axustes tiveran sido escritos por algo distinto da pantalla de axustes, unha importación, unha migración ou a propia API de xestión do plugin, porque gardar esa pantalla a man almacena un valor baleiro distinto que nunca o provocaba. Corrixido nas nove pasarelas que compartían o mesmo código.
  • As subscricións pagadas con Apple Pay ou Google Pay por un cliente sen conta non obtían nunca do banco o permiso de pago recorrente, así que a primeira renovación fallaba cunha nota dicindo que non había tarxeta. Ocurría en tendas onde a opción xeral de “permitir aos clientes crear unha conta durante o pago” está desactivada, algo habitual en tendas que admiten a compra como convidado: os camiños de pago das wallets non vían a sobrescritura que fai desa opción o propio WooCommerce Subscriptions, así que non se creaba ningunha conta e, sen conta, o permiso do banco non se podía gardar. Corrixido nos catro sitios que o xestionan (Apple Pay e Google Pay, tanto no checkout clásico como no de bloques).
  • O script de pago do checkout de bloques estaba compilado contra unha versión de React que o propio WordPress non acepta. Unha dependencia só de desenvolvemento arrastraba un React máis novo á compilación, e WordPress rexeita os elementos producidos por el, así que o método de pago podía non chegar a aparecer no checkout de bloques. A compilación fixa agora a versión que usa WordPress e o script volveuse a xerar.
  • O carro e o checkout podían volverse notablemente lentos, tamén para visitantes non identificados, en tendas con tarxetas gardadas ou subscricións. O axudante interno WCRed() do plugin construía unha copia nova do seu obxecto global cada vez que se chamaba, e ese obxecto regista tres hooks de WordPress no momento de construírse. WordPress non substitúe eses hooks, os engade, así que nunha tenda onde o axudante se chama unha vez por cada tarxeta gardada ou subscrición as mesmas tres comprobacións acababan rexistradas centos de veces e volvían a executarse, todas, cada vez que WooCommerce montaba a lista de pasarelas de pago dispoñibles. Numa tenda que reportou o problema isto chegaba a uns 438 rexistros duplicados por carga de páxina e a cerca de 1,7 segundos de traballo de PHP na páxina do carro, dos cales só 56 milisegundos eran consultas á base de datos. O axudante constrúe agora ese obxecto unha soa vez e reutilízase, de modo que os hooks rexístranse exactamente unha vez por petición. O comportamento do plugin non cambia en nada: o obxecto non garda datos propios de cada petición. O mesmo tratamento dun obxecto por petición aplicouse ao axudante WCPSD2(), que tiña a forma idéntica.
  • Nunha pequena parte das tendas, a clave de sinatura de mensaxes de Comercio Agéntico (UCP) gardábase dunha forma que non podía usarse nunca, así que toda comprobación de sinatura contra ela fallaba e o documento de clave publicado non seguía o estándar. Cando o plugin creaba esa clave, unha das súas dúas coordenadas volvía de vez en cando de OpenSSL un byte máis curta do que esixe o estándar, arredor de 1 tenda de cada 135, e o plugin a gardaba tal cal en lugar de completala. Desde ese momento a tenda non podía verificar as súas propias sinaturas, nin podía facelo ningún axente externo, ata que se rotaba a clave. A clave gárdase agora completada ata a lonxitude esixida, e unha clave xa gardada na forma curta repara automaticamente a primeira vez que se lee, así que ningún comerciante ten que rotar nada.
  • En tendas con PHP 8.0 ou anterior, activar a conciliación por correo electrónico rompía a páxina cun erro do servidor en lugar de simplemente non funcionar. O plugin comprobábao agora antes e deixa unha nota clara no seu rexistro. A función en si segue necesitando PHP 8.1.
  • As tarefas en segundo plano acumulábanse en decenas de copias de si mesmas na lista de accións programadas de WooCommerce. Corrixido en todos os sitios onde o plugin programa algo, e as copias que xa estaban alí limpanse automaticamente.
  • Unha notificación á app móbil podía perderse sen dar ningún erro se se enviaba no momento equivocado.
  • Aparecían avisos de PHP no rexistro do servidor en cada visita á páxina de “pagar pedido”, procedentes das pasarelas de Apple Pay e Google Pay. Para os compradores non había nada roto, pero o log de depuración desas pasarelas non estaba rexistrando nada dese paso, así que quen intentase diagnosticar un problema alí estaba mirando un fallo e non un silencio. Reportado por un comerciante, e atopado en tres pasarelas en lugar da que se reportou. Grazas.
  • Activar o log de depuración para investigar un problema de pago con tarxeta producía avisos en lugar da información para a que se activara.
  • O botón “Conectar con Google” dos axustes de conciliación por correo electrónico non se mostraba nunca. Conceder o acceso xa era posible completando os datos de Google e pulsando “Gardar cambios”, así que isto restaura un atallo, non desbloquea a función.
  • O plugin enviaba á tenda un correo dicindo “Redsys non está enviando campos de tokenización” despois de pagos nos que Redsys enviara todos e cada un deles. A comprobación que hai detrás dese aviso probaba unha variable que non existe en ningunha parte do plugin, e unha proba sobre algo que non existe sempre é certa, así que o aviso saía en cada pago que gardaba unha tarxeta. Os comerciantes levábanllo ao seu banco, que respondía con razón que o terminal estaba ben. O aviso informa agora só de ausencias reais, e indica no rexistro que campo faltaba, a data de caducidade, a marca da tarxeta ou o número, en lugar de dicir unicamente que faltaba algo. Tamén tivo que deixar de ler a marca despois de que o plugin a convertese nun nome para mostrar, porque esa conversión responde “Descoñecido” cando non hai marca, o que tería convertido o aviso nun que non podería aparecer nunca. Ese mesmo bloque escribía “unknown” como número de tarxeta no log de depuración en cada pago, por un nome de variable cunha letra de máis; agora escribe o número enmascarado real.
  • Buscar na pantalla de tokens de Redsys (WooCommerce – Redsys tokens) por correo electrónico ou por nome de usuario non atopaba ningunha tarxeta gardada a partir da vixésimo quinta. A pantalla pedía á base de datos unha páxina de tokens e buscaba despois dentro de esa páxina, e como os pedía sen ningún orden concreto, esa páxina eran sempre os veinticinco tokens máis antigos da tenda, así que as tarxetas gardadas recentemente, que son as únicas que alguén busca, resultaban inalcanzables. A búsqueda faise agora na base de datos, sobre todos os tokens, e o listado chega de máis novo a máis antigo. O contador que hai encima da táboa e a lista de debaixo xa non poden discrepar, ordenar por nome de usuario ou por correo ordena agora toda a táboa en lugar da páxina visible, e a pantalla xa non carga en memoria todos os tokens da tenda só para contalos, cousa que en tendas con miles de tarxetas gardadas facía en cada carga de páxina.