Suscripciones Avanzadas para WooCommerce 2.0.x

O desenvolvemento desta versión custou 4.360 euros. O custo da primeira versión foi de 38.000 euros. O custo acumulado desde a primeira versión é de 42.360 euros, pero o custo para ti é só a licencia desde 80€.

Nova rama 2.0.x do plugin Suscripciones Avanzadas para WooCommerce. É unha versión maior: o plugin deixa de depender da extensión WooCommerce Subscriptions e estrena cobros recorrentes automáticos nativos con Stripe, PayPal Payments e WooPayments, ademais de Redsys, que segue viaxando dentro do propio plugin.

Versiones da rama

• 2.0.0

2.0.0

Importante:

• Esta é unha versión maior. Lee as notas de actualización antes de actualizar, especialmente se agora mesmo cobras a través de PayPal Standard.
• Esta versión require WordPress 6.5 ou superior e WooCommerce 8.0 ou superior. O requisito anterior (WordPress 5.1, WooCommerce 5.1) nunca se probou de verdade, e ao probalo para esta versión comprobouse que o plugin non podía funcionar alí. As cifras novas son aquelas sobre as que se verificou esta versión.
• PayPal Standard deixa de estar soportado. O propio WooCommerce desaconséllao desde a súa versión 5.5 e bloqueao en instalacións novas. Se agora mesmo cobras as subscricións con PayPal Standard, instala WooCommerce PayPal Payments e migra os métodos de pago dos teus clientes antes de actualizar á 2.0.0.

Novo:

• Pagos recorrentes automáticos con Stripe. As renovacións cobranse agora off-session sobre a tarxeta gardada do cliente usando o plugin WooCommerce Stripe Payment Gateway (requírese a versión 9.8.0 ou superior). Non fai falta ningunha extensión de pago Subscriptions.
• Pagos recorrentes automáticos con PayPal Payments. As renovacións cobranse a través do token da bóveda (vault) de PayPal usando o plugin WooCommerce PayPal Payments (requírese a versión 3.0 ou superior). Non fai falta ningunha extensión de pago Subscriptions.
• Pagos recorrentes automáticos con WooPayments. As renovacións cobranse off-session sobre o método de pago gardado do cliente usando o plugin WooPayments (requírese a versión 7.0 ou superior). Non fai falta ningunha extensión de pago Subscriptions.
• Gardado fiable do método de pago no checkout. Cando un cliente compra unha subscrición con Stripe, PayPal Payments ou WooPayments, o plugin asegúrase de que o método de pago quede gardado para as renovacións, aínda que esas pasarelas normalmente só o fagan cando WooCommerce Subscriptions está activo.
• Xestión de 3D Secure (SCA) nas renovacións. Cando o banco pide autenticación adicional nun cobro recorrente, a renovación márcase como fallida cun motivo claro e pódese avisar ao cliente para que autorice o seguinte intento.
• Reintento automático das renovacións fallidas. Cando un pago falla (tarxeta rexeitada, saldo insuficiente, autenticación requirida, etc.), o programador de reintentos reprograma automaticamente o seguinte intento.
• Detección de acordos de PayPal cancelados. Se un cliente cancela a súa autorización de PayPal fóra da túa tenda, a seguinte renovación deteccióna, a subscrición pasa a «en espera» e o método de pago gardado márcase como non válido para que o cliente poida volver a autorizalo.
• Comprobación de seguridade de divisa nas renovacións. O plugin négase a cobrar unha renovación nunha moeda distinta á do pago orixinal, o que evita dobres cobros accidentais na moeda equivocada despois dun cambio de divisa da tenda.
• Cambio de método de pago entre pasarelas. Os clientes poden cambiar entre Stripe, PayPal Payments e WooPayments desde A miña conta, e a seguinte renovación usa automaticamente o método novo.
• Novo axuste de administración «Cancelar subscrición ao reembolso total dunha orde de renovación», en WooCommerce > Axustes > Suscripciones Avanzadas > Axustes Avanzados. Desactivado por defecto. Cando está desactivado, un reembolso total só deixa unha nota na subscrición; cando está activado, a subscrición cancélase. Os reembolsos parciais nunca cancelan.
• Os reembolsos da orde do primeiro pago (a orde pai) cancelan sempre a subscrición. É o que se espera de forma natural ao reembolsar a compra orixinal, e é independente do novo axuste de administración.
• Notas automáticas na subscrición cada vez que se reembolsa unha renovación (total ou parcialmente), para que a cronoloxía da subscrición quede clara.
• Panel de compatibilidade de pasarelas de pago na pantalla de axustes do plugin (WooCommerce > Axustes > Suscripciones Avanzadas > Axustes Xerais). Mostra de un vistazo se os plugins de pasarela soportados están instalados e activos, e ofrece enlaces de instalación ou activación en un clic cando non o están.
• Detección de disputas e contracargos en Stripe e PayPal. Cando un cliente abre unha disputa, a orde relacionada pasa a «en espera» para que poidas reaccionar antes da seguinte renovación.
• Detección da eliminación do método de pago en Stripe. Se se borra o token da tarxeta gardada, todas as subscricións que o usan márcanse e pasan a «en espera» para que o cliente poida gardar un método novo.
• Redsys aparece no panel de compatibilidade de pasarelas como pasarela incluída: viaxa dentro deste plugin e nunca necesita unha instalación aparte.

Arreglado:

• Desactivar WooCommerce xa non tumba o sitio enteiro. Ata agora, se WooCommerce deixaba de estar activo por calquera motivo (o apagabas para revisar algo, fallaba unha actualización ou daba un erro propio), este plugin seguía intentando usalo e tiraba todas as páxinas do sitio, incluída a administración de WordPress, sen máis volta atrás que o FTP. Agora o plugin detecta que WooCommerce non está, non fai nada de forma silenciosa e mostra un aviso explicativo na administración. Ao volver a activar WooCommerce todo restáurase sen ningunha acción adicional.
• As renovacións podían programarse no momento equivocado, ou non programarse, en tendas cuxa zona horaria está configurada como desfase UTC en lugar de como cidade. A corrección afecta a como se lee a zona horaria do sitio ao calcular cando vence un pago programado.
• Un pedido cancelado xa non deixa atrás unha subscrición fantasma. Se un pago fallaba e o reintento do cliente xeraba un pedido NOVO en lugar de retomar o primeiro (algo que ocorre cando se perde a sesión ou cambia o carro), a subscrición sen pagar do pedido abandonado quedábase para sempre na conta do cliente. Nunca se cobraba e non se podía activar, pero o cliente vía unha subscrición que xamais pagara. Cancelar ese pedido agora elimínana. As subscricións xa activas non se tocan nunca: cancelar un pedido de renovación deixa a subscrición en marcha, como debe ser.
• Borrar o plugin agora limpa o que é seu. Ata agora, eliminar o plugin deixaba todo detrás: os seus axustes, os seus bloqueos de pago e —o que tiña consecuencias visibles— as súas tarefas programadas, que WordPress seguía intentando executar aínda que non quedase nada instalado que as atendese, fallando e reintentándoas indefinidamente. Ao desinstalar agora elimínanse os axustes propios do plugin e cancelan as súas tarefas programadas. Deliberadamente NON se borran as túas subscricións, os teus pedidos nin ningún dato de clientes: son rexistros de negocio, quedan na base de datos, e ao reinstalar o plugin volven exactamente como estaban.
• Borrar o plugin nun sitio que nunca tivo WooCommerce xa non enche o log de erros. A limpeza buscaba tarefas programadas nunha táboa que WooCommerce nunca creou, o que producía un erro de base de datos por cada grupo de tarefas do plugin. Nunca foi fatal (a limpeza terminaba igualmente e os mensaxes só aparecían coa depuración activada), pero nunha rede multisitio repetíase en cada sitio. A limpeza segue funcionando exactamente igual; só se silencian os mensaxes inútiles, e unicamente nun sitio onde esa táboa falta de verdade.
• Produtos variables cunha mestura de variacións de subscrición e de non subscrición: comprar unha variación que NON é unha subscrición xa non gardará a tarxeta do cliente nin creará unha subscrición. O plugin decidía se unha variación era de subscrición mirando o axuste do produto pai e ignoraba por completo a casilla «Subscription» da propia variación, así que nun produto variable onde só algunhas variacións son subscricións, todas comportábanse como tales. Unha variación sen axuste propio segue herdando o do pai, de modo que un produto que acabas de marcar como subscrición segue funcionando ata que configures as súas variacións.
• Unha subscrición configurada para renovarse manualmente xa non se cobra de forma automática. Entre a renovación programada e a pasarela de pago non había nada que comprobese se o cliente pedira pagar a man, e ao pedido de renovación —que para as renovacións manuais créase deliberadamente sen método de pago— se lle completaba un a partir do pedido orixinal xusto antes do cobro. As renovacións manuais agora detéñense en ambos puntos, e limpan calquera reintento automático pendente sobre elas.
• Fixar a data de inicio dunha subscrición dende a pantalla de administración xa non provoca un erro fatal. A pantalla chamaba a un método de escritura de datas que non existía no obxecto de subscrición, así que en calquera tenda sen a extensión WooCommerce Subscriptions o gardado morría con «Chamada a método indefinido». O fluxo de pedidos con data de inicio fallaba igual por un segundo método inexistente. Ambos están agora implementados sobre o almacenamento de datas propio do plugin; unha subscrición á que nunca se lle escribiu unha data de inicio segue informando da data de creación do seu pedido, exactamente como antes.
• Produtos variables: os axustes de subscrición por variación non aparecían nunca ao marcar unha variación como subscrición. A pantalla de edición de produto solicitaba o script cargador sen minificar independentemente do axuste SCRIPT_DEBUG, así que nas instalacións que só inclúen o recurso minificado devolvía un 404 e o panel de campos —que permanece oculto ata que ese script se executa— non chegaba a aparecer.
• Os correos de notificación de subscrición disparados directamente a través da Scheduler API do plugin agora si se envían. A API aceptaba un tipo de notificación e o pasaba adiante, pero a función que había detrás non declaraba ese parámetro, así que PHP o descartaba e o tipo chegaba baleiro: non se enviaba ningún correo e o evento de notificación non indicaba tipo algún. As notificacións lanzadas polo programador nos seus propios hooks non estaban afectadas.
• Unha data de primeiro pago fixada dende a pantalla de administración da subscrición agora si se cobra. A acción programada creábase co nome de hook de WooCommerce Subscriptions, que este plugin non escoita, de modo que o pago simplemente nunca se executaba en tendas sen esa extensión. A acción programa agora no hook de renovación propio do plugin e no mesmo grupo que o resto de accións de pago, así que cancelar, pausar ou borrar a subscrición elimínana como cabe esperar. O nome de hook antigo segue programándose en paralelo para as tendas que dependían del, e pódese desactivar co filtro aswc_start_date_schedule_legacy_payment_hook.
• Cambiar unha data de primeiro pago xa programada agora move ese pago en lugar de engadir un segundo.
• A integración cos bloques de Carrito e Pago xa non desaparece en sitios que funcionan con SCRIPT_DEBUG activado. Só se distribuía o script minificado, así que a ruta sen minificar que WordPress pide nese modo devolvía un 404 e toda a integración deixaba de cargarse en silencio, levándose por diante o control «Ver Produtos Adxuntos» das caixas de subscrición e os anuncios falados do total recorrente. Agora ambas versións xéranse a partir do mesmo código fonte.
• As táboas de descontos das páxinas de produto xa cargan a súa folla de estilos e o seu script nos temas clásicos. Os recursos resolvían a partir do produto que se estaba renderizando no bucle, que aínda non está dispoñible cando un tema clásico encola os scripts, así que nese temas a táboa aparecía completamente sen estilos e o refresco de descontos dos produtos variables non se executaba. Os temas de bloques non estaban afectados.
• Pasarela Redsys incluída: os pedidos de subscrición detectanse agora correctamente no checkout, de modo que se solicita a Redsys o token de tarxeta recorrente (COF) e as renovacións poden cobrarse automáticamente.
• Pasarela Redsys incluída: a tarxeta de subscrición gardada aparece agora en Mi conta > Métodos de pago (etiquetada como «Subscription»). O filtro de métodos de pago gardados a ocultaba ao executarse fóra do contexto de checkout.
• Pasarela Redsys incluída: gardar o token da subscrición xa non aborta a notificación de pago cando o banco non devolve o número de tarxeta enmascarado (Ds_Card_Number); almacénase un marcador seguro dos últimos catro díxitos para que a tokenización e as renovacións automáticas sigan funcionando.
• Ponte de PayPal: o contedor de servizos do plugin oficial obténse agora a través da acción real de arranque de PPCP (cunha alternativa directa), de modo que os cobros de renovación funcionan. A busca anterior dependía dun filtro que non existe en WooCommerce PayPal Payments.
• Ponte de PayPal: as cargas útiles dos webhooks xa non se procesan cando a verificación de firma de PayPal rexeitou a petición, o que pecha un vector de manipulación non autenticada do estado de pedidos e subscricións.
• Ponte de PayPal: os cobros de renovación seguen exactamente o manexador oficial de renovacións (só vault_id, sen o campo inválido stored_credentials) e o resultado do cobro léese da captura real, non só do estado do pedido de PayPal. As configuracións con intención de autorización infórmanse con clareza en lugar de marcarse como pagadas sen capturar os fondos.
• Ponte de PayPal: os pedidos de renovación almacenan agora as metas oficiais de PayPal e o identificador de transacción, de modo que os reembolsos dende a administración de WooCommerce e as consultas de disputas funcionan sobre as renovacións cobradas polo ponte.
• Ponte de PayPal: a dispoñibilidade do vault léese do sistema de axustes actual (cunha alternativa herdada), os tokens de Venmo e Apple Pay envíanse co seu payment source correcto, e a marca de vault só se inxecta no checkout cando gardar métodos de pago é realmente elegible.
• Ponte de PayPal: as pasarelas de PayPal ocúltanse no checkout para os carritos de subscrición con proba gratuíta (total cero), que PayPal non pode gardar no vault sen un cobro real nesta configuración.
• Ponte de Stripe: as excepcións da API de Stripe durante as renovacións captúranse e regístranse como fallos de pago, e cada cobro de renovación envía unha clave de idempotencia determinista, o que evita cobros duplicados cando unha petición expira e se reintenta.
• Ponte de Stripe: as renovacións correctas almacenan agora o identificador de cargo de Stripe como identificador de transacción do pedido, de modo que os reembolsos e as disputas iniciados dende o panel de Stripe se asocian ao pedido correcto.
• Ponte de Stripe: as renovacións pagadas con tokens de Stripe Link cobráronse co tipo de método de pago correcto, e a comprobación da moeda orixinal lê a moeda almacenada localmente en lugar de chamar á API de Stripe en cada renovación.
• Ponte de Stripe: elimínase o soporte de SEPA. O identificador da pasarela SEPA herdada xa non existe en Stripe 10.x e as súas renovacións nunca podían cobrarse; tarxeta e Link seguen totalmente soportados.
• WooPayments e Stripe: o método de pago gárdase agora de forma fiable no checkout de bloques (Store API). A detección anterior non chegaba a coincidir nunca pola forma en que WooCommerce expón o contexto de pago, e as subscricións quedaban sen token para as renovacións.
• O gardado do método de pago xa non duplica a tarxeta cando o cliente paga cun método de pago xa gardado.
• Cambiar o método de pago dunha subscrición con WooPayments ou Stripe agora tokeniza a tarxeta nova sen cobrar ao cliente. Antes podíase cobrar o importe completo da renovación no momento do cambio.
• O checkout activa e oculta automaticamente a casilla «gardar método de pago» nas pasarelas de tarxeta cando o carrito contén unha subscrición, de modo que as compras con 3D Secure tamén acaban cun token gardado.
• Os hooks de pago das renovacións comprobaban agora que o pedido siga needing pago antes de cobrar (programador, pontes e a acción «retry payment» da administración), o que evita cobros duplicados en pedidos xa pagados ou autorizados.
• Cando un método de pago gardado deixa de ser válido ou se elimina, a subscrición afectada pasa agora a «en espera» cunha nota explicativa, en lugar de fallar en silencio na seguinte renovación.
• As lecturas de metadatos en tendas sen HPOS podían devolver a subscrición equivocada ou corromper os contadores de reintentos por un argumento incorrecto pasado a get_post_meta(); corrixidas todas as chamadas.
• Pasarela Redsys incluída: verifícase a firma da resposta REST de renovación, as comparacións de firma usan hash_equals(), as notificacións rexeitan cando non hai configurada unha clave SHA-256, e corrixiuse un fallo no manexo da clave en modo de probas. Nota: as renovacións cobran intencionadamente o token recorrente (R) máis recente do cliente; cando un cliente actualiza a súa tarxeta, o token novo substitúe ao anterior para todos os seus cobros recorrentes.

Seguridade:

• A caixa de subscrición multiproducto decide agora o seu propio prezo no servidor. A petición de «engadir á subscrición» levaba o total da caixa, e esa cifra almacenábase como prezo de liña do carrito, así que unha petición manipulada podía comprar unha caixa por calquera importe. O prezo dérivase agora dos prezos de produto da propia tenda (ou do prezo fixo configurado na caixa) e a cifra da petición ignórase.
• A caixa de subscrición multiproduto só acepta agora os produtos que realmente ofrece. Tanto a petición de engadir como a de editar aceptaban calquera ID de produto e devolvían o seu nome, prezo e imaxe sen comprobar nin a configuración da caixa nin se o produto é visible publicamente, o que revelaba prezos de produtos en borrador, privados e protexidos por contrasinal a visitantes sen identificar. As seleccións validan agora contra a lista de produtos ou categorías da propia caixa e contra a visibilidade do produto.
• Gardar unha variación de produto esixe agora a capacidade «edit products» por si mesma, ademais do seu nonce. Non era explotable antes, porque WooCommerce só chega a ese manexador despois da súa propia comprobación de capacidades; é defensa en profundidade na función que escribe.

Actualizado:

• Cando non se pode ler a zona horaria do sitio, o plugin déixao dito agora no seu propio log. Sempre seguiu adiante en lugar de fallar, recorrendo ao desfase UTC do sitio e, no seu defecto, ao propio UTC. Facelo en silencio significaba que unha renovación cobrada a unha hora inesperada non tiña nada que a explicase. O comportamento alternativo non cambia; agora queda rexistrado, e só cando ocorre de verdade.
• Limpeza interna: o plugin xa non mestura os seus datos cos da extensión WooCommerce Subscriptions, o que evita conflitos cando ambos plugins conviven no mesmo sitio.
• Documentación para desenvolvedores actualizada. A referencia de hooks cobre agora todas as accións e filtros novos que introducen os pontes de pago (ver docs/hooks-reference.md).
• Pasarela Redsys incluída: o rexistro migra da API obsoleta WC_Logger::add() ao logger moderno, e o identificador de módulo nos logs reflicte agora este plugin (Advanced_Subscriptions_Redsys) en lugar do gateway independente Redsys Light.

Compatibilidade:

• Probado ata WordPress 7.1 e WooCommerce 11.1.0.
• Require WooCommerce Stripe Payment Gateway 9.8.0 ou superior para o ponte de Stripe.
• Require WooCommerce PayPal Payments 3.0 ou superior para o ponte de PayPal.
• Require WooPayments 7.0 ou superior para o ponte de WooPayments.
• Totalmente compatible co almacenamento de pedidos de alto rendemento de WooCommerce (HPOS).
• O plugin xa non depende da extensión WooCommerce Subscriptions. Funciona de forma autónoma.