Handling subscription based products

Wednesday 11 February 2004 6:16:18 am

Hi,

Since my company is both a web host and an Application Service Provider for web based software, I've come to discover the severe limitations of the ezprice datatype (and the rest of the shop module) for handling subscription based products and services. So, I though I would get a discussion going on this as I'm sure several people would benefit from such functionality.

Here are some ideas as to how subscription based products could be handled:

The following fields should be available when editing a class attribute created upon the ezprice datatype (in addition to the existing ones):

- The possibility to choose whether the product is a "Single purchase" or "Subscription based".
- For what period the product price is defined (1 day/week/month/year) (only applies if the price is "Subscription based").
- Whether the subscription is automatically renewed or not (only applies if the price is "Subscription based")

Next, it should be possible to create available subscription cycles under the "Shop" section of the admin interface. Each subscription cycle should consist of a number and a selection of the available options "days", "weeks", "months" and "years". Examples of subscription cycles would be "3 days" or "4 months" and these would be the available options when registering an order.

When displaying the price of a subscription based product (defined in the template for the view mode of the ezprice datatype), it should be visible for what period the price of the product is defined, for instance "$49 (pr/month)".

When registering an order, if the basket contains subscription based products, the shop/register template should automatically displays a drop down list containing the available subscription cycles. The ezorder table needs to be expanded in order to store the selected subscription cycle.

A new db table should be created to store information about each subscription cycle for an order. At a minimum, this new table would need to contain information about until which date the order has been "paid". (Of course, ezp doesn't know whether a product has been paid or not, so this will in fact be until which date the order has been ordered according to the subscription cycle and the order date, in addition to previous records in the table for the same order.)

A new cron job script would run to see if there are any subscription based orders that expire soon ("soon" would be defined as the amount of days in advance by an INI setting, probably in shop.ini).

For each subscription based order that expires soon

If the product is set to be automatically renewed
Store another subscription cycle for the order
Send info to admin containing information about the subscription renewal

If the product is not set to be automatically renewed
Send an email to the order owner (as fetched by the associated shopaccounthandler) asking them to renew their subscription, including a link to do so.

The page allowing a shopper to renew their subscription would require two new functions "all" and "own" to a new "renewsubscription" view of the shop module. If the user has the required privileges, a basket containing the products to be renewed (the subscription based products) will be displayed, including a button labeled "Renew". When the button is clicked, the same thing happens as when a product is set to be automatically renewed. In addition, an Email is sent to the order owner notifying them that the subscription has been renewed.

Finally, to have the possibility of using a credit card payment gateway upon the renewal of a subscription based order, the trigger "shop | renewsubscription | after" should be defined.

Questions/possible problems:

Another way to go would be to select a different set of available subscription cycles for each product object, and then select the preferred subscription cycle when adding a product to the cart. However, this would result in several subscription cycles for one order, and would make things more complicated, both for the shopper and the admin. Could anyone think of a scenario where product-specific subscription cycles are needed?

As far as I can tell, "ezproduct" would be a more appropriate name for the "ezprice" datatype, especially after adding the above functionality. Regardless, I prefer the "ezproduct" name as it much better describes the purpose of the datatype (and how it is handled in ezp).

Looking forward to hearing your input !

Sincerely,

Eirik Johansen

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Thursday 21 April 2005 1:04:31 am

Hi Bruce,

Just saw your question, about 9 months late. Don't know if you're still interested in the answer, but here goes.

I've created content objects for each product which contains information about when the product expires, what discount it has if any, for what length of time the product should be renewed, and whether or not it should be cancelled when it expires.

This information is all stored in separate attributes built upon default eZP datatypes. I then have a script set up as a cron job which loops through the objects and renews the ones (by incrementing the expiry date) that should be renewed and creates invoices for those.

This kind of works for us, but has of course a very low "recycling factor".

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Tuesday 24 June 2008 2:08:40 pm

Hi Peter,

As far as I know, there have been no improvements to the handling of subscription based products in eZ.

Since it's been 3 years since I last mentioned how we were handling this, I thought I would give anyone interested a little update. Here's the README file from the extension we ended up creating, and which still is in production today:

GENERAL OVERVIEW

The subscription extension creates a flexible framework for handling subscription.

It works by adding an attribute based upon the "Subscription" datatype to the content
class which stores your subscription data. The attribute will store the following data
associated with the subscription:

* Product count
* Product (a select list of all content objects on the site containing a price)
* Subscription cycle (in days, weeks, months or years)
* Subscription renewal date
* Subscription cancellation date (if any)
* Subscription discount (if any)

If you require additional information about a subscription, these can be stored as separate,
"normal" attributes.

Once you have created your subscriptions, the extension comes with several views for
presenting/handling the subscriptions. These views are accessible through the "Subscription"
tab which appears in your admin interface once the extension has been activated.

There is also an event type for creating a new subscription based on an order.

VIEWS

List subscriptions

Lists all subscriptions sorted by subscription renewal date. The view can be configured
display additional information about each subscription, fetched from either other attributes
of the subscription node, or from attributes of parent nodes.

Subscriptions which are due for renewal (a configurable x days until renewal) will appear in
red. When the "Renew" button is pushed, the renewal process is initiated. You can program your
own subscription handler which decides what happens when a subscription is renewed.

Turnover development

A simple, graphical representation of how the subscription revenue is growing, devided by
month.

Turnover detailed

All subscriptions grouped by subscription product and sorted by product generating the
highest recurring revenue.

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/