This guide provides an overview of the decisions made to implement multiple subscription handling. It is intended to provide a non-technical overview. For a technical document on how mulitple subscriptions are implemented, refer to the Developer Guide to Multiple Subscriptions.
Before continuing with this guide, it will be helpful to understand the difference between a subscription product and a subscription and the subscription renewal process.
The reasons store managers requested it be possible for customers to purchase different subscription products were:
- to prevent making customers repeat the entire checkout process for each subscription product they wished to purchase;
- to reduce payment gateway fees by processing the sign-up and renewal of multiple products in the one transaction (most payment gateways charge a flat per transaction fee); and
- to consolidate renewals and reduce the number of renewal orders created to avoid having to process multiple orders for the one shipment to a customer.
Designing a system for purchasing products with thousands of possible combinations of billing schedule creates a number of challenges.
The key challenges in designing a system to handle multiple subscriptions were:
- account for shipping calculations, which can be charged per order, per item, per shipping class and any combination of the above.
- present all relevant information about the billing agreements being made between the customer and the store, including recurring taxes and shipping amounts, while avoiding presenting so much information on the checkout page that the customer feels overwhelmed or confused and abandons the checkout.
- create a system that is straight forward for store managers to understand and does not create excessive overhead for managing subscriptions and renewal orders.
After examining a number of alternatives, the method chosen to make it possible to purchase different subscription products was to group each subscription product with an equivalent billing schedule into the one subscription.
For example, if a customer purchases 2 x monthly subscriptions and 3 x yearly subscriptions in the one transaction, only 2 x subscriptions would be created – one with two line items for the monthly subscription products and one with three line items for the annual subscription products.
This allows recurring shipping costs to be accurately calculated and displayed during sign-up, while also consolidating renewal orders and reducing payment gateway fees for subscription products purchased in the same transaction.
WooCommerce Subscriptions will create the minimum number of subscriptions possible. To do this, it will group subscriptions based on each product’s:
- billing interval and period, to make sure the billing schedule for all products is honoured.
- subscription length, to make sure the end date can be set correct for each subscription product.
- first renewal date, to account for products with a free trial or synchronised renewal date.
For example, all of the following subscription products would be grouped together:
- $10 every 2nd month
- $25 every 2nd month with 2 months free trial (because the first renewal date after the free trial is equivalent to the first renewal date of the product without a free trial)
- $30 every 2nd month synchronised to today’s date
On the other hand, none of the following subscription products would be grouped together:
- $10 per month
- $10 per month for 12 months
- $10 per month synchronised to tomorrow’s date
- $10 per month with 2 weeks free trial
The lifecycle for a subscription product is: Product > Cart > Checkout > Order > Subscription.
To support the purchase of multiple subscription products in the one transaction, the cart therefore needs to be able to contain multiple subscription products.
As the products will be grouped into subscriptions after checkout, the products are also grouped in the cart based on billing schedule. This also allows for the recurring totals to be displayed based on the grouped billing schedules, reducing the number of rows that need to be displayed to the customer to accurately present the recurring tax, shipping and total.
Subscriptions v1.5 displayed the recurring totals alongside the order totals on the cart and order review pages. However, by supporting multiple subscriptions in the one transaction, different billing schedules need to be displayed to the customer to fully communicate the commitment of the subscription.
A new Recurring Totals section was added below the existing order totals section to display this information. Each groups of subscription products will have a row in the Recurring Totals section for:
As mentioned above, after purchasing multiple subscription products in the same transaction, the products with the same billing schedule will be grouped together as line items on the one subscription object (as opposed to each subscription having only one product/line item associated with it).
For example, the three screenshots below show:
- an order used to purchase 4 subscription products – it has 4 line items; and
- two subscriptions created to store data for the 4 subscription products – each has 2 line items.
No design is perfect, and as such, this implementation did introduce some new issues. These issues and the solutions are:
- a customer could no longer cancel subscriptions to an individual item. This was resolved by adding a remove item button on the View Subscription page to allow the customer to remove individual items.
- switching was previously done per subscription, which would not work with a subscription that has multiple line items. As a result, this process has been updated to be per item, instead of per subscription.
- subscription products purchased separately are not grouped together, which results in extra renewal orders and gateway fees. This issue has not been addressed with v2.0 and instead, may be address in a later version or as a separate extension in the form of a Add to Subscription button. This can replace or be displayed alongside the Add to Cart button, allowing customers to add new products to an existing subscription, rather than creating a new subscription, while still requiring them to review and agree to the shipping costs of that subscription.
Before deciding on Grouping Subscription products, alternative implements were explored, including an implementation which created a separate subscription for each subscription product purchased in the transaction.
For example, if a customer was to purchase 2 x monthly subscriptions and 3 x yearly subscriptions in the one transaction, 5 x subscriptions would be created with each including a single line item for that product.
This system would be most similar to the existing design, but it did not take full advantage of the flexibility of the changes being introduced in v2.0. It applied the constraints of the previous designs to the new architecture.
Furthermore, to achieve the goal of consolidating renewal orders and reducing payment gateway fees, this system would need a batch processing system to group each subscription’s renewals into the one order.
Batch processing created a major issue: shipping could not accurately be calculated and agreed to on checkout at the time of sign-up. Because some shipping methods charge per order, and subscriptions were batched into renewal orders, any time a customer purchased new subscriptions or cancelled existing subscriptions, the shipping amount would be different at renewal to the time of sign-up. This issue was found unavoidable and would ultimately introduce an unfixable bug. As a result, create a single subscription and batch processing all renewals was not chosen as the final implementation.
A few options were explored for how to display recurring totals for multiple subscriptions, including:
- do not display the totals;
- continue to display recurring totals inside of the order totals section;
- add a new Recurring Totals section below the existing order totals section to display recurring subtotal, shipping, taxes and total.
- display a complete order table for each subscription below the Sign Up Now/Place Order button.
The first of these is not legal in many countries so was not seriously considered. The second would make the order totals section very crowded, while the fourth included a lot of duplicated information.
As a result, the Recurring Totals section was chosen as it was the most concise method that still provided accurate information for each recurring amount.