Auto-switch subscriber to different Plan/Group on renewal (HikaSubscription

-- HikaShop version -- : 6.5.2
-- Joomla version -- : 6.1.3
-- PHP version -- : 8.4.25

Hello,

We use HikaShop (latest version, 6.5.2) + HikaSerial/HikaSubscription (latest version, 6.1.1) for a magazine subscription business, and we have a workflow question about automating something we currently do manually.

Our setup:
- Product A ("New customer"): sold to first-time subscribers. It creates a subscription (Plan A) and, via the Group Subscriber action, puts the customer in Group A. Group A gives access to 1 year of magazine issues (current year only).
- Product B ("Renewal"): when an existing customer renews, we currently manually move them to a different subscription setup: we assign Product B, which is meant to link them to Group B instead. Group B gives access to 2 years of issues (current year + previous year).

Right now, every time a Product A customer renews, a staff member manually switches them over to the Group B / Plan B setup so they get 2-year access. We would like this to happen automatically, without manual intervention, the first time (or every time) a Product A subscription is renewed.

Questions:
1. Is there a native way, using the Plan relation types (Creation / Creation then Renewal / Renewal or Creation / Renewal) and the Group Subscriber plugin, to have a renewal product point to a different Plan/Group than the one used at initial creation? From the documentation, it looks like a subscription stays tied to the Plan it was created with, so a "Renewal" product would only extend that same Plan rather than switch it.
2. If this isn't natively supported, is there a documented plugin trigger/hook we could use to build a small custom plugin that detects "this order is a renewal of an existing subscription" and then automatically changes the customer's group / re-associates the subscription with a different Plan? We noticed hooks like getSubscriptionsRenewals in the changelog — would that (or another trigger) be the right place to act on this?

We have a local test environment (WAMP server) where we can safely try out any suggested configuration or custom plugin before applying it to our live site.

Any guidance on the best approach (native configuration vs. custom plugin, and which hook to use) would be very helpful.

Thank you!

Hello,

Thank you for your feedback!

1. Since you want to move to a different "plan", we can't call it "renewal" but it's more an "upgrade" (migration from a plan to another).
The "upgrade" can also extend the subscription with a specified duration. There are few different ways to extend the duration (set-up via the config)
The "upgrade mode" can be "use max between upgrade and end date" or "extend end date".

2. If you want to implement your own custom rules, you'll find a lot of various triggers in HikaSubscription:
www.hikashop.com/support/documentation/1...#subscription_plugin
The "onBeforeSubscriptionUpdate" allows you to interact with the subscription before its modification in the database ; but if you want to perform "group modification" it would require some code (some could be available via the HikaSubscription core).

Regards,

Hi Jerome,

Thank you very much, this is very helpful, the "upgrade" concept sounds like exactly what we need.

A few follow-up questions before we test it on our staging environment (WAMP):

1. Can the customer perform the "upgrade" themselves from the front-end (e.g. from their "My subscriptions" page), or does it always require an admin/staff action from the backend? We'd like our customers to be able to self-serve if possible.
2. When the upgrade happens (whether triggered by the customer or by staff), does the Group Subscriber action of the new plan (Plan Β) get applied automatically, will the customer automatically be added to Group B and removed from Group A, the same way it works for a normal plan activation?
3. To clarify our use case: the subscription duration should stay exactly 1 year at each renewal (just like a normal yearly renewal), the only difference with Plan B is that it gives access to 2 years' worth of magazine issues (current + previous year), not a 2-year subscription duration. So after the first upgrade, we'd expect this to keep working the same way every year (Plan B renewing itself for 1 year at a time, keeping the 2-year content access). Given that, which upgrade mode would you recommend, and once a subscription has been upgraded to Plan B, do subsequent renewals stay on Plan B automatically, or would we need to configure a separate "renewal" product specifically for Plan B as well?
4. Is it possible to hide the "upgrade" product from customers entirely and only trigger it ourselves from the backend (e.g. from the Subscription listing), in case we prefer to keep this as a manual-but-simplified step rather than fully self-service?

Thanks again for your help, this has clarified things a lot.

Best regards

Hello,

1. The upgrade can be done by the customer via its subscription listing.

2. Since the plan change, the previous plan group will be removed while the new plan group will be applied.

3. Yes you need renewal for all your plans. The "upgrade" allow to move from one plan to another.

4. The upgrade product should be hidden by default.
Like the renewals. it's not product that customer can by like that: it requires to be link with an active subscription.
HikaSerial doesn't add the interface in the product page ; we started to implement it but the feature was not very "useful" for customers.

Regards,

Hi,

Thank you very much for your help; I really appreciate it!