Advanced Subscriptions for WooCommerce 2.0.x

The development of this version cost 4,360 euros. The cost of the first version was 38,000 euros. The total cost since the first version is 42,360 euros, but the cost for you is only the license from €80.

New 2.0.x branch of the plugin Advanced Subscriptions for WooCommerce. It is a major version: the plugin no longer depends on the WooCommerce Subscriptions extension and introduces native automatic recurring charges with Stripe, PayPal Payments, and WooPayments, in addition to Redsys, which continues to travel within the plugin itself.

Branch versions

• 2.0.0

2.0.0

Important:

• This is a major version. Read the update notes before updating, especially if you are currently charging through PayPal Standard.
• This version requires WordPress 6.5 or higher and WooCommerce 8.0 or higher. The previous requirement (WordPress 5.1, WooCommerce 5.1) had never been truly tested, and upon testing it for this version, it was found that the plugin could not function there. The new figures are those on which this version has been verified.
• PayPal Standard is no longer supported. WooCommerce itself has discouraged it since version 5.5 and blocks it in new installations. If you are currently charging subscriptions with PayPal Standard, install WooCommerce PayPal Payments and migrate your customers' payment methods before updating to 2.0.0.

New:

• Automatic recurring payments with Stripe. Renewals are now charged off-session on the customer's saved card using the WooCommerce Stripe Payment Gateway plugin (version 9.8.0 or higher is required). No Subscriptions payment extension is needed.
• Automatic recurring payments with PayPal Payments. Renewals are charged via the vault token (vault) from PayPal using the WooCommerce PayPal Payments plugin (version 3.0 or higher is required). No Subscriptions payment extension is needed.
• Automatic recurring payments with WooPayments. Renewals are charged off-session on the customer's saved payment method using the WooPayments plugin (version 7.0 or higher is required). No Subscriptions payment extension is needed.
• Reliable saving of the payment method at checkout. When a customer purchases a subscription with Stripe, PayPal Payments, or WooPayments, the plugin ensures that the payment method is saved for renewals, even though those gateways typically only do so when WooCommerce Subscriptions is active.
• 3D Secure (SCA) management on renewals. When the bank requests additional authentication on a recurring charge, the renewal is marked as failed with a clear reason, and the customer can be notified to authorize the next attempt.
• Automatic retry of failed renewals. When a payment fails (card declined, insufficient balance, authentication required, etc.), the retry scheduler automatically reschedules the next attempt.
• Detection of canceled PayPal agreements. If a customer cancels their PayPal authorization outside your store, the next renewal detects it, the subscription goes to 'pending', and the saved payment method is marked as invalid so the customer can reauthorize it.
• Currency security check on renewals. The plugin refuses to charge a renewal in a currency different from that of the original payment, preventing accidental double charges in the wrong currency after a store currency change.
• Changing payment methods between gateways. Customers can switch between Stripe, PayPal Payments, and WooPayments from My Account, and the next renewal automatically uses the new method.
• New admin setting 'Cancel subscription on full refund of a renewal order', in WooCommerce > Settings > Advanced Subscriptions > Advanced Settings. Disabled by default. When disabled, a full refund only leaves a note on the subscription; when enabled, the subscription is canceled. Partial refunds never cancel.
• Refunds of the first payment order (the parent order) always cancel the subscription. This is what is naturally expected when refunding the original purchase, and it is independent of the new admin setting.
• Automatic notes on the subscription every time a renewal is refunded (in full or partially), to keep the subscription timeline clear.
• Payment gateway compatibility panel on the plugin settings screen (WooCommerce > Settings > Advanced Subscriptions > General Settings). Shows at a glance if supported gateway plugins are installed and active, and offers one-click installation or activation links when they are not.
• Detection of disputes and chargebacks in Stripe and PayPal. When a customer opens a dispute, the related order goes to 'pending' so you can react before the next renewal.
• Detection of payment method removal in Stripe. If the token for the saved card is deleted, all subscriptions using it are marked and go to 'pending' so the customer can save a new method.
• Redsys appears in the gateway compatibility panel as an included gateway: it travels within this plugin and never needs a separate installation.

Fixed:

• Deactivating WooCommerce no longer crashes the entire site. Until now, if WooCommerce was deactivated for any reason (you turned it off to check something, an update failed, or it had its own error), this plugin continued trying to use it and crashed all the site's pages, including WordPress admin, with no way back except FTP. Now the plugin detects that WooCommerce is not there, does nothing silently, and shows an explanatory notice in admin. When WooCommerce is reactivated, everything resets without any additional action.
• Renewals could be scheduled at the wrong time, or not scheduled at all, in stores whose timezone is set as UTC offset instead of as a city. The fix affects how the site's timezone is read when calculating when a scheduled payment is due.
• A canceled order no longer leaves behind a ghost subscription. If a payment failed and the customer's retry generated a NEW order instead of resuming the first one (something that happens when the session is lost or the cart changes), the unpaid subscription from the abandoned order would remain forever in the customer's account. It was never charged and could not be activated, but the customer saw a subscription they had never paid for. Canceling that order now removes it. Active subscriptions are never touched: canceling a renewal order leaves the subscription running, as it should.
• Deleting the plugin now cleans up what is its own. Until now, removing the plugin left everything behind: its settings, its payment locks, and —the one with visible consequences— its scheduled tasks, which WordPress continued trying to execute even though nothing was installed to handle them, failing and retrying indefinitely. Now, uninstalling removes the plugin's own settings and cancels its scheduled tasks. Deliberately, your subscriptions, orders, and any customer data are NOT deleted: they are business records, remain in the database, and when the plugin is reinstalled, they return exactly as they were.
• Deleting the plugin on a site that never had WooCommerce no longer fills the error log. The cleanup was looking for scheduled tasks in a table that WooCommerce had never created, which produced a database error for each group of tasks from the plugin. It was never fatal (the cleanup finished anyway and the messages only appeared with debugging enabled), but in a multisite network, it repeated on every site. The cleanup continues to work exactly the same; only the useless messages are silenced, and only on a site where that table is truly missing.
• Variable products with a mix of subscription and non-subscription variations: purchasing a variation that is NOT a subscription no longer saves the customer's card or creates a subscription. The plugin decided if a variation was a subscription by looking at the parent product's setting and completely ignored the 'Subscription' checkbox of the variation itself, so in a variable product where only some variations are subscriptions, all behaved as such. A variation without its own setting still inherits that of the parent, so a product you just marked as a subscription continues to function until you configure its variations.
• A subscription set to renew manually is no longer charged automatically. Between the scheduled renewal and the payment gateway, there was nothing to check if the customer had requested to pay manually, and the renewal order—which for manual renewals is deliberately created without a payment method—was filled with one from the original order just before the charge. Manual renewals now stop at both points, and any pending automatic retry on them is cleared.
• Setting a start date for a subscription from the admin screen no longer causes a fatal error. The screen called a date writing method that did not exist in the subscription object, so in any store without the WooCommerce Subscriptions extension, saving would fail with "Call to undefined method". The order flow with start date also failed due to a second non-existent method. Both are now implemented on the plugin's own date storage; a subscription that never had a start date written still reports the creation date of its order, exactly as before.
• Variable products: subscription settings by variation never appeared when marking a variation as a subscription. The product edit screen requested the unminified loader script regardless of the setting SCRIPT_DEBUG, so in installations that only include the minified resource it returned a 404 and the field panel—which remains hidden until that script runs—did not appear.
• Subscription notification emails triggered directly through the plugin's Scheduler API are now sent. The API accepted a notification type and passed it along, but the function behind it did not declare that parameter, so PHP discarded it and the type arrived empty: no email was sent and the notification event did not indicate any type. Notifications triggered by the scheduler on their own hooks were not affected.
• A first payment date set from the subscription admin screen is now charged. The scheduled action was created with the WooCommerce Subscriptions hook name, which this plugin does not listen to, so the payment simply never executed in stores without that extension. The action is now scheduled on the plugin's own renewal hook and in the same group as the rest of the payment actions, so canceling, pausing, or deleting the subscription removes it as expected. The old hook name is still scheduled in parallel for stores that depended on it, and can be disabled with the filter aswc_start_date_schedule_legacy_payment_hook.
• Changing a previously scheduled first payment date now moves that payment instead of adding a second.
• The integration with the Cart and Checkout blocks no longer disappears on sites running with SCRIPT_DEBUG enabled. Only the minified script was distributed, so the unminified path that WordPress requests in that mode returned a 404 and the entire integration stopped loading silently, taking down the "View Attached Products" control of the subscription boxes and the spoken announcements of the recurring total. Now both versions are generated from the same source code.
• The discount tables on product pages now load their stylesheet and script in classic themes. The resources were resolved from the product being rendered in the loop, which is still not available when a classic theme enqueues the scripts, so in those themes the table appeared completely without styles and the refresh of variable product discounts did not execute. Block themes were not affected.
• Redsys gateway included: subscription orders are now correctly detected at checkout, so the recurring card token (COF) is requested from Redsys and renewals can be charged automatically.
• Redsys gateway included: the saved subscription card now appears in My Account > Payment Methods (labeled as "Subscription"). The saved payment methods filter hid it when executed outside the checkout context.
• Redsys gateway included: saving the subscription token no longer aborts the payment notification when the bank does not return the masked card number (Ds_Card_Number); a secure marker of the last four digits is stored so that tokenization and automatic renewals continue to function.
• PayPal bridge: the official plugin's service container is now obtained through the actual PPCP boot action (with a direct alternative), so renewal charges work. The previous search depended on a filter that does not exist in WooCommerce PayPal Payments.
• PayPal bridge: webhook payloads are no longer processed when PayPal's signature verification has rejected the request, closing a vector for unauthenticated manipulation of order and subscription states.
• PayPal bridge: renewal charges now exactly follow the official renewal handler (only vault_id, without the invalid field stored_credentials) and the charge result is read from the actual capture, not just from PayPal's order status. Configurations with authorization intent are reported clearly instead of being marked as paid without capturing funds.
• PayPal bridge: renewal orders now store PayPal's official metas and transaction ID, so refunds from WooCommerce admin and dispute queries work on renewals charged by the bridge.
• PayPal bridge: the availability of the vault is read from the current settings system (with inherited alternative), Venmo and Apple Pay tokens are sent with their payment source correct, and the vault mark is only injected at checkout when saving payment methods is truly eligible. PayPal bridge: PayPal gateways are hidden at checkout for subscription carts with free trial (total zero), which PayPal cannot save in the
• vault without an actual charge in this configuration. Stripe bridge: Stripe API exceptions during renewals are captured and logged as payment failures, and each renewal charge sends a deterministic idempotency key, preventing duplicate charges when a request expires and is retried.
• Stripe bridge: correct renewals now store the Stripe charge ID as the order's transaction ID, so refunds and disputes initiated from the Stripe panel are associated with the correct order.
• Stripe bridge: renewals paid with Stripe Link tokens are charged with the correct payment method type, and the original currency check reads the locally stored currency instead of calling the Stripe API on each renewal.
• Stripe bridge: SEPA support is removed. The identifier for the inherited SEPA gateway no longer exists in Stripe 10.x and its renewals could never be charged; card and Link remain fully supported.
• WooPayments and Stripe: the payment method is now reliably saved at the block checkout (Store API). The previous detection never matched due to how WooCommerce exposes the payment context, and subscriptions were left without a token for renewals.
• Saving the payment method no longer duplicates the card when the customer pays with an already saved payment method.
• Changing the payment method of a subscription with WooPayments or Stripe now tokenizes the new card without charging the customer. Previously, the full renewal amount could be charged at the time of change.
• The checkout automatically activates and hides the "save payment method" checkbox on card gateways when the cart contains a subscription, so purchases with 3D Secure also end up with a saved token.
• The payment hooks for renewals now check that the order still needs payment before charging (scheduler, bridges, and the "retry payment" action from admin), preventing duplicate charges on already paid or authorized orders.
• When a saved payment method becomes invalid or is removed, the affected subscription now goes to "pending" with an explanatory note, instead of failing silently on the next renewal.
• Metadata readings in stores without HPOS could return the wrong subscription or corrupt retry counters due to an incorrect argument passed to
• ; all calls corrected. get_post_meta()Redsys gateway included: the signature of the renewal REST response is verified, signature comparisons use
• , notifications are rejected when no SHA-256 key is set, and a bug in handling the key in test mode has been fixed. Note: renewals intentionally charge the customer's most recent recurring token (R); when a customer updates their card, the new token replaces the previous one for all their recurring charges. hash_equals()Security:

The multiproduct subscription box now decides its own price on the server. The "add to subscription" request carried the total of the box, and that figure was stored as the cart line price, so a manipulated request could buy a box for any amount. The price is now derived from the product prices of the store itself (or from the fixed price set in the box) and the figure of the request is ignored.

• 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.
• The multiproduct subscription box now only accepts products that it actually offers. Both the request to add and the request to edit accepted any product ID and returned its name, price, and image without checking either the box configuration or whether the product is publicly visible, which revealed prices of draft, private, and password-protected products to unidentified visitors. Selections are now validated against the list of products or categories of the box itself and against the visibility of the product.
• Saving a product variation now requires the "edit products" capability by itself, in addition to its nonce. It was not exploitable before, because WooCommerce only reaches that handler after its own capability checks; it is defense in depth in the writing function.

Updated:

• When the site's timezone cannot be read, the plugin now logs it in its own log. It has always proceeded instead of failing, falling back to the site's UTC offset and, if that fails, to UTC itself. Doing so silently meant that a renewal charged at an unexpected time had nothing to explain it. The alternative behavior does not change; it is now logged, and only when it actually occurs.
• Internal cleanup: the plugin no longer mixes its data with that of the WooCommerce Subscriptions extension, preventing conflicts when both plugins coexist on the same site.
• Updated developer documentation. The hooks reference now covers all the new actions and filters introduced by the payment bridges (see docs/hooks-reference.md).
• Included Redsys gateway: the logging migrates from the obsolete API WC_Logger::add() to the modern logger, and the module identifier in the logs now reflects this plugin (Advanced_Subscriptions_Redsys) instead of the standalone Redsys Light gateway.

Compatibility:

• Tested up to WordPress 7.1 and WooCommerce 11.1.0.
• Requires WooCommerce Stripe Payment Gateway 9.8.0 or higher for the Stripe bridge.
• Requires WooCommerce PayPal Payments 3.0 or higher for the PayPal bridge.
• Requires WooPayments 7.0 or higher for the WooPayments bridge.
• Fully compatible with WooCommerce high-performance order storage (HPOS).
• The plugin no longer depends on the WooCommerce Subscriptions extension. It operates independently.