Advanced Subscriptions for WooCommerce 2.0.x

El desarrollo de esta versión ha costado 4.360 euros. El coste de la primera versión fue de 38.000 euros. El coste acumulado desde la primera versión es de 42.360 euros, pero el coste para ti es solo la licencia desde 80€.

Nueva rama 2.0.x del plugin Advanced Subscriptions for WooCommerce. Es una versión mayor: el plugin deja de depender de la extensión WooCommerce Subscriptions y estrena cobros recurrentes automáticos nativos con Stripe, PayPal Payments y WooPayments, además de Redsys, que sigue viajando dentro del propio plugin.

Versiones de la rama

• 2.0.0

2.0.0

Importante:

• Esta es una versión mayor. Lee las notas de actualización antes de actualizar, especialmente si ahora mismo cobras a través de PayPal Standard.
• Esta versión requiere WordPress 6.5 o superior y WooCommerce 8.0 o superior. El requisito anterior (WordPress 5.1, WooCommerce 5.1) nunca se había llegado a probar de verdad, y al probarlo para esta versión se comprobó que el plugin no podía funcionar ahí. Las cifras nuevas son aquellas sobre las que se ha verificado esta versión.
• PayPal Standard deja de estar soportado. El propio WooCommerce lo desaconseja desde su versión 5.5 y lo bloquea en instalaciones nuevas. Si ahora mismo cobras las suscripciones con PayPal Standard, instala WooCommerce PayPal Payments y migra los métodos de pago de tus clientes antes de actualizar a la 2.0.0.

Nuevo:

• Pagos recurrentes automáticos con Stripe. Las renovaciones se cobran ahora off-session sobre la tarjeta guardada del cliente usando el plugin WooCommerce Stripe Payment Gateway (se requiere la versión 9.8.0 o superior). No hace falta ninguna extensión de pago Subscriptions.
• Pagos recurrentes automáticos con PayPal Payments. Las renovaciones se cobran a través del token de la bóveda (vault) de PayPal usando el plugin WooCommerce PayPal Payments (se requiere la versión 3.0 o superior). No hace falta ninguna extensión de pago Subscriptions.
• Pagos recurrentes automáticos con WooPayments. Las renovaciones se cobran off-session sobre el método de pago guardado del cliente usando el plugin WooPayments (se requiere la versión 7.0 o superior). No hace falta ninguna extensión de pago Subscriptions.
• Guardado fiable del método de pago en el checkout. Cuando un cliente compra una suscripción con Stripe, PayPal Payments o WooPayments, el plugin se asegura de que el método de pago quede guardado para las renovaciones, aunque esas pasarelas normalmente solo lo hagan cuando WooCommerce Subscriptions está activo.
• Gestión de 3D Secure (SCA) en las renovaciones. Cuando el banco pide autenticación adicional en un cobro recurrente, la renovación se marca como fallida con un motivo claro y se puede avisar al cliente para que autorice el siguiente intento.
• Reintento automático de las renovaciones fallidas. Cuando un pago falla (tarjeta rechazada, saldo insuficiente, autenticación requerida, etc.), el programador de reintentos reprograma automáticamente el siguiente intento.
• Detección de acuerdos de PayPal cancelados. Si un cliente cancela su autorización de PayPal fuera de tu tienda, la siguiente renovación lo detecta, la suscripción pasa a «en espera» y el método de pago guardado se marca como no válido para que el cliente pueda volver a autorizarlo.
• Comprobación de seguridad de divisa en las renovaciones. El plugin se niega a cobrar una renovación en una moneda distinta a la del pago original, lo que evita dobles cobros accidentales en la moneda equivocada después de un cambio de divisa de la tienda.
• Cambio de método de pago entre pasarelas. Los clientes pueden cambiar entre Stripe, PayPal Payments y WooPayments desde Mi cuenta, y la siguiente renovación usa automáticamente el método nuevo.
• Nuevo ajuste de administración «Cancel subscription on full refund of a renewal order», en WooCommerce > Ajustes > Advanced Subscriptions > Advanced Settings. Desactivado por defecto. Cuando está desactivado, un reembolso total solo deja una nota en la suscripción; cuando está activado, la suscripción se cancela. Los reembolsos parciales nunca cancelan.
• Los reembolsos del pedido del primer pago (el pedido padre) cancelan siempre la suscripción. Es lo que se espera de forma natural al reembolsar la compra original, y es independiente del nuevo ajuste de administración.
• Notas automáticas en la suscripción cada vez que se reembolsa una renovación (total o parcialmente), para que la cronología de la suscripción quede clara.
• Panel de compatibilidad de pasarelas de pago en la pantalla de ajustes del plugin (WooCommerce > Ajustes > Advanced Subscriptions > General Settings). Muestra de un vistazo si los plugins de pasarela soportados están instalados y activos, y ofrece enlaces de instalación o activación en un clic cuando no lo están.
• Detección de disputas y contracargos en Stripe y PayPal. Cuando un cliente abre una disputa, el pedido relacionado pasa a «en espera» para que puedas reaccionar antes de la siguiente renovación.
• Detección de la eliminación del método de pago en Stripe. Si se borra el token de la tarjeta guardada, todas las suscripciones que lo usan se marcan y pasan a «en espera» para que el cliente pueda guardar un método nuevo.
• Redsys aparece en el panel de compatibilidad de pasarelas como pasarela incluida: viaja dentro de este plugin y nunca necesita una instalación aparte.

Arreglado:

• Desactivar WooCommerce ya no tumba el sitio entero. Hasta ahora, si WooCommerce dejaba de estar activo por cualquier motivo (lo apagabas para revisar algo, fallaba una actualización o daba un error propio), este plugin seguía intentando usarlo y tiraba todas las páginas del sitio, incluida la administración de WordPress, sin más vuelta atrás que el FTP. Ahora el plugin detecta que WooCommerce no está, no hace nada de forma silenciosa y muestra un aviso explicativo en la administración. Al volver a activar WooCommerce todo se restablece sin ninguna acción adicional.
• Las renovaciones podían programarse en el momento equivocado, o no programarse, en tiendas cuya zona horaria está configurada como desfase UTC en lugar de como ciudad. La corrección afecta a cómo se lee la zona horaria del sitio al calcular cuándo vence un pago programado.
• Un pedido cancelado ya no deja detrás una suscripción fantasma. Si un pago fallaba y el reintento del cliente generaba un pedido NUEVO en lugar de retomar el primero (algo que ocurre cuando se pierde la sesión o cambia el carrito), la suscripción sin pagar del pedido abandonado se quedaba para siempre en la cuenta del cliente. Nunca se cobraba y no se podía activar, pero el cliente veía una suscripción que jamás había pagado. Cancelar ese pedido ahora la elimina. Las suscripciones ya activas no se tocan nunca: cancelar un pedido de renovación deja la suscripción en marcha, como debe ser.
• Borrar el plugin ahora limpia lo que es suyo. Hasta ahora, eliminar el plugin lo dejaba todo detrás: sus ajustes, sus bloqueos de pago y —el que tenía consecuencias visibles— sus tareas programadas, que WordPress seguía intentando ejecutar aunque no quedara nada instalado que las atendiera, fallando y reintentándolas indefinidamente. Al desinstalar ahora se eliminan los ajustes propios del plugin y se cancelan sus tareas programadas. Deliberadamente NO se borran tus suscripciones, tus pedidos ni ningún dato de clientes: son registros de negocio, se quedan en la base de datos, y al reinstalar el plugin vuelven exactamente como estaban.
• Borrar el plugin en un sitio que nunca tuvo WooCommerce ya no llena el log de errores. La limpieza buscaba tareas programadas en una tabla que WooCommerce nunca había creado, lo que producía un error de base de datos por cada grupo de tareas del plugin. Nunca fue fatal (la limpieza terminaba igualmente y los mensajes solo aparecían con la depuración activada), pero en una red multisitio se repetía en cada sitio. La limpieza sigue funcionando exactamente igual; solo se silencian los mensajes inútiles, y únicamente en un sitio donde esa tabla falta de verdad.
• Productos variables con una mezcla de variaciones de suscripción y de no suscripción: comprar una variación que NO es una suscripción ya no guarda la tarjeta del cliente ni crea una suscripción. El plugin decidía si una variación era de suscripción mirando el ajuste del producto padre e ignoraba por completo la casilla «Subscription» de la propia variación, así que en un producto variable donde solo algunas variaciones son suscripciones, todas se comportaban como tales. Una variación sin ajuste propio sigue heredando el del padre, de modo que un producto que acabas de marcar como suscripción sigue funcionando hasta que configures sus variaciones.
• Una suscripción configurada para renovarse manualmente ya no se cobra de forma automática. Entre la renovación programada y la pasarela de pago no había nada que comprobara si el cliente había pedido pagar a mano, y al pedido de renovación —que para las renovaciones manuales se crea deliberadamente sin método de pago— se le rellenaba uno a partir del pedido original justo antes del cobro. Las renovaciones manuales ahora se detienen en ambos puntos, y se limpia cualquier reintento automático pendiente sobre ellas.
• Fijar la fecha de inicio de una suscripción desde la pantalla de administración ya no provoca un error fatal. La pantalla llamaba a un método de escritura de fechas que no existía en el objeto de suscripción, así que en cualquier tienda sin la extensión WooCommerce Subscriptions el guardado moría con «Call to undefined method». El flujo de pedidos con fecha de inicio fallaba igual por un segundo método inexistente. Ambos están ahora implementados sobre el almacenamiento de fechas propio del plugin; una suscripción a la que nunca se le escribió una fecha de inicio sigue informando de la fecha de creación de su pedido, exactamente como antes.
• Productos variables: los ajustes de suscripción por variación no aparecían nunca al marcar una variación como suscripción. La pantalla de edición de producto solicitaba el script cargador sin minificar independientemente del ajuste SCRIPT_DEBUG, así que en las instalaciones que solo incluyen el recurso minificado devolvía un 404 y el panel de campos —que permanece oculto hasta que ese script se ejecuta— no llegaba a aparecer.
• Los correos de notificación de suscripción disparados directamente a través de la Scheduler API del plugin ahora sí se envían. La API aceptaba un tipo de notificación y lo pasaba adelante, pero la función que había detrás no declaraba ese parámetro, así que PHP lo descartaba y el tipo llegaba vacío: no se enviaba ningún correo y el evento de notificación no indicaba tipo alguno. Las notificaciones lanzadas por el programador en sus propios hooks no estaban afectadas.
• Una fecha de primer pago fijada desde la pantalla de administración de la suscripción ahora sí se cobra. La acción programada se creaba con el nombre de hook de WooCommerce Subscriptions, que este plugin no escucha, de modo que el pago simplemente nunca se ejecutaba en tiendas sin esa extensión. La acción se programa ahora en el hook de renovación propio del plugin y en el mismo grupo que el resto de acciones de pago, así que cancelar, pausar o borrar la suscripción la elimina como cabe esperar. El nombre de hook antiguo se sigue programando en paralelo para las tiendas que dependían de él, y se puede desactivar con el filtro aswc_start_date_schedule_legacy_payment_hook.
• Cambiar una fecha de primer pago ya programada ahora mueve ese pago en lugar de añadir un segundo.
• La integración con los bloques de Carrito y Pago ya no desaparece en sitios que funcionan con SCRIPT_DEBUG activado. Solo se distribuía el script minificado, así que la ruta sin minificar que WordPress pide en ese modo devolvía un 404 y toda la integración dejaba de cargarse en silencio, llevándose por delante el control «View Attached Products» de las cajas de suscripción y los anuncios hablados del total recurrente. Ahora ambas versiones se generan a partir del mismo código fuente.
• Las tablas de descuentos de las páginas de producto ya cargan su hoja de estilos y su script en los temas clásicos. Los recursos se resolvían a partir del producto que se estaba renderizando en el bucle, que todavía no está disponible cuando un tema clásico encola los scripts, así que en esos temas la tabla aparecía completamente sin estilos y el refresco de descuentos de los productos variables no se ejecutaba. Los temas de bloques no estaban afectados.
• Pasarela Redsys incluida: los pedidos de suscripción se detectan ahora correctamente en el checkout, de modo que se solicita a Redsys el token de tarjeta recurrente (COF) y las renovaciones pueden cobrarse automáticamente.
• Pasarela Redsys incluida: la tarjeta de suscripción guardada aparece ahora en Mi cuenta > Métodos de pago (etiquetada como «Subscription»). El filtro de métodos de pago guardados la ocultaba al ejecutarse fuera del contexto de checkout.
• Pasarela Redsys incluida: guardar el token de la suscripción ya no aborta la notificación de pago cuando el banco no devuelve el número de tarjeta enmascarado (Ds_Card_Number); se almacena un marcador seguro de últimos cuatro dígitos para que la tokenización y las renovaciones automáticas sigan funcionando.
• Puente de PayPal: el contenedor de servicios del plugin oficial se obtiene ahora a través de la acción real de arranque de PPCP (con una alternativa directa), de modo que los cobros de renovación funcionan. La búsqueda anterior dependía de un filtro que no existe en WooCommerce PayPal Payments.
• Puente de PayPal: las cargas útiles de los webhooks ya no se procesan cuando la verificación de firma de PayPal ha rechazado la petición, lo que cierra un vector de manipulación no autenticada del estado de pedidos y suscripciones.
• Puente de PayPal: los cobros de renovación siguen exactamente el manejador oficial de renovaciones (solo vault_id, sin el campo inválido stored_credentials) y el resultado del cobro se lee de la captura real, no solo del estado del pedido de PayPal. Las configuraciones con intención de autorización se informan con claridad en lugar de marcarse como pagadas sin capturar los fondos.
• Puente de PayPal: los pedidos de renovación almacenan ahora las metas oficiales de PayPal y el identificador de transacción, de modo que los reembolsos desde la administración de WooCommerce y las consultas de disputas funcionan sobre las renovaciones cobradas por el puente.
• Puente de PayPal: la disponibilidad del vault se lee del sistema de ajustes actual (con alternativa heredada), los tokens de Venmo y Apple Pay se envían con su payment source correcto, y la marca de vault solo se inyecta en el checkout cuando guardar métodos de pago es realmente elegible.
• Puente de PayPal: las pasarelas de PayPal se ocultan en el checkout para los carritos de suscripción con prueba gratuita (total cero), que PayPal no puede guardar en el vault sin un cobro real en esta configuración.
• Puente de Stripe: las excepciones de la API de Stripe durante las renovaciones se capturan y se registran como fallos de pago, y cada cobro de renovación envía una clave de idempotencia determinista, lo que evita cobros duplicados cuando una petición expira y se reintenta.
• Puente de Stripe: las renovaciones correctas almacenan ahora el identificador de cargo de Stripe como identificador de transacción del pedido, de modo que los reembolsos y las disputas iniciados desde el panel de Stripe se asocian al pedido correcto.
• Puente de Stripe: las renovaciones pagadas con tokens de Stripe Link se cobran con el tipo de método de pago correcto, y la comprobación de la moneda original lee la moneda almacenada localmente en lugar de llamar a la API de Stripe en cada renovación.
• Puente de Stripe: se elimina el soporte de SEPA. El identificador de la pasarela SEPA heredada ya no existe en Stripe 10.x y sus renovaciones nunca podían cobrarse; tarjeta y Link siguen totalmente soportados.
• WooPayments y Stripe: el método de pago se guarda ahora de forma fiable en el checkout de bloques (Store API). La detección anterior no llegaba a coincidir nunca por la forma en que WooCommerce expone el contexto de pago, y las suscripciones se quedaban sin token para las renovaciones.
• El guardado del método de pago ya no duplica la tarjeta cuando el cliente paga con un método de pago ya guardado.
• Cambiar el método de pago de una suscripción con WooPayments o Stripe ahora tokeniza la tarjeta nueva sin cobrar al cliente. Antes se podía cobrar el importe completo de la renovación en el momento del cambio.
• El checkout activa y oculta automáticamente la casilla «guardar método de pago» en las pasarelas de tarjeta cuando el carrito contiene una suscripción, de modo que las compras con 3D Secure también acaban con un token guardado.
• Los hooks de pago de las renovaciones comprueban ahora que el pedido siga necesitando pago antes de cobrar (programador, puentes y la acción «retry payment» de la administración), lo que evita cobros duplicados en pedidos ya pagados o autorizados.
• Cuando un método de pago guardado deja de ser válido o se elimina, la suscripción afectada pasa ahora a «en espera» con una nota explicativa, en lugar de fallar en silencio en la siguiente renovación.
• Las lecturas de metadatos en tiendas sin HPOS podían devolver la suscripción equivocada o corromper los contadores de reintentos por un argumento incorrecto pasado a get_post_meta(); corregidas todas las llamadas.
• Pasarela Redsys incluida: se verifica la firma de la respuesta REST de renovación, las comparaciones de firma usan hash_equals(), las notificaciones se rechazan cuando no hay configurada una clave SHA-256, y se ha corregido un fallo en el manejo de la clave en modo de pruebas. Nota: las renovaciones cobran intencionadamente el token recurrente (R) más reciente del cliente; cuando un cliente actualiza su tarjeta, el token nuevo sustituye al anterior para todos sus cobros recurrentes.

Seguridad:

• La caja de suscripción multiproducto decide ahora su propio precio en el servidor. La petición de «añadir a la suscripción» llevaba el total de la caja, y esa cifra se almacenaba como precio de línea del carrito, así que una petición manipulada podía comprar una caja por cualquier importe. El precio se deriva ahora de los precios de producto de la propia tienda (o del precio fijo configurado en la caja) y la cifra de la petición se ignora.
• La caja de suscripción multiproducto solo acepta ahora los productos que realmente ofrece. Tanto la petición de añadir como la de editar aceptaban cualquier ID de producto y devolvían su nombre, precio e imagen sin comprobar ni la configuración de la caja ni si el producto es visible públicamente, lo que revelaba precios de productos en borrador, privados y protegidos por contraseña a visitantes sin identificar. Las selecciones se validan ahora contra la lista de productos o categorías de la propia caja y contra la visibilidad del producto.
• Guardar una variación de producto exige ahora la capacidad «edit products» por sí misma, además de su nonce. No era explotable antes, porque WooCommerce solo llega a ese manejador después de su propia comprobación de capacidades; es defensa en profundidad en la función que escribe.

Actualizado:

• Cuando no se puede leer la zona horaria del sitio, el plugin lo deja dicho ahora en su propio log. Siempre ha seguido adelante en lugar de fallar, recurriendo al desfase UTC del sitio y, en su defecto, al propio UTC. Hacerlo en silencio significaba que una renovación cobrada a una hora inesperada no tenía nada que la explicase. El comportamiento alternativo no cambia; ahora queda registrado, y solo cuando ocurre de verdad.
• Limpieza interna: el plugin ya no mezcla sus datos con los de la extensión WooCommerce Subscriptions, lo que evita conflictos cuando ambos plugins conviven en el mismo sitio.
• Documentación para desarrolladores actualizada. La referencia de hooks cubre ahora todas las acciones y filtros nuevos que introducen los puentes de pago (ver docs/hooks-reference.md).
• Pasarela Redsys incluida: el registro migra de la API obsoleta WC_Logger::add() al logger moderno, y el identificador de módulo en los logs refleja ahora este plugin (Advanced_Subscriptions_Redsys) en lugar del gateway independiente Redsys Light.

Compatibilidad:

• Probado hasta WordPress 7.1 y WooCommerce 11.1.0.
• Requiere WooCommerce Stripe Payment Gateway 9.8.0 o superior para el puente de Stripe.
• Requiere WooCommerce PayPal Payments 3.0 o superior para el puente de PayPal.
• Requiere WooPayments 7.0 o superior para el puente de WooPayments.
• Totalmente compatible con el almacenamiento de pedidos de alto rendimiento de WooCommerce (HPOS).
• El plugin ya no depende de la extensión WooCommerce Subscriptions. Funciona de forma autónoma.