Full-Subscription Cancellation Process
- Panagiotis Papanastasiou
This page provides an analysis of the full subscription cancellation process. It includes an explanation of the full cancellation flow and outlines three different scenarios that illustrate both successful and unsuccessful cancellations. These scenarios detail user interactions and the expected system notifications throughout the process.
Following the 3.28.174 release, we implemented an updated cancellation process for full subscription cancellations that is more reliable and transparent than the existing one. This updated flow prioritizes vendor provisioning, providing more accurate status updates and minimizing potential billing discrepancies since it keeps users informed if there is an issue during the cancellation, whether it occurs on our platform or the vendor's platform. As a result, users will know with certainty if the cancellation has been successful on both platforms or not and how to resolve the problem (if an error occurs) and successfully cancel their subscription.
Full Cancellation Flow
With the full subscription cancellation process, our system now prioritizes cancellations on the vendor’s platform before implementing them on our platform. This change leads to a more reliable and transparent cancellation experience, ensuring that the actual statuses are clearly displayed on both our platform and the vendor's platform.
Applicability of the Full Subscription Cancellation Process
This section of the page explains where the full subscription cancellation process is applied. Specifically:
The full subscription cancellation process applies to full cancellations for all Service Managers and their respective subscriptions (paid and trial) and bundles requiring provisioning. Specifically, this covers:
“Immediate” or “past-dated” full cancellations of subscriptions (and bundles) that are initiated within the BSS portal.
“Immediate” full cancellations of subscriptions (and bundles) that are initiated within the Storefront portal.
Full cancellation requests of subscriptions (and bundles) with an immediate or past effective date that are initiated within the Storefront and are accepted within the BSS portal.
Crucially, all existing checks and validations performed before the cancellation process remain unchanged.
Cancellation Scenarios and Handling
This section describes the different scenarios that can occur during the full subscription cancellation process and how they are handled in both the BSS portal and the Storefront portal.
1. Successful Cancellation on the Vendor Platform and Our Platform
Let’s assume that a Storefront or BSS user initiates a full subscription cancellation based on the following specifications and the cancellation is successful:
| Descriptions | BSS Portal Example | Storefront Portal Example |
|---|---|---|---|
Initial Subscription-State: |
|  |
|
Cancellation Type: | Only for “Immediate” (BSS & Storefront) | ||
Process: | User triggers cancellation → Provisioning status updates to "In Progress" → During this phase, no provisioning or billing actions can be performed. This applies both to BSS and Storefront → Cancellation on the vendor platform is successful → BSS subscription status updates to "canceled" → Provisioning status updates to "Synchronized". |
| |
System Notifications: | During the actual cancellation process, the user who initiated the cancellation views a cyclical loader until the cancellation is completed on all platforms, while another user who views the same subscription will witness an informative ribbon stating that a provisioning action for this subscription is ongoing. |
|
|
Final Subscription-State: |
| ||
Cancellation Pop-Up Window: (Pop-ups are used to confirm actions and display success/failure messages.) | Informs the user of the successful cancellation. | ||
System Email Notifications: | After a subscription cancellation is successfully completed, a system email notification, "Subscription Cancellation Request Completed," is dispatched. | The email is dispatched when a BSS user accepts a cancellation request that has been initiated from the Storefront and has been completed successfully. | The same email is dispatched when a Storefront user has initiated and successfully completed a cancellation for a subscription that is automatic and does not require the approval of a BSS user. |
History Record: | A History record is added: "Status is set to {canceled} with effective date {effective date}". | N/A | |
Notes: |
| ||
2. Failure of Cancellation on the Vendor Platform
Let’s assume that a Storefront or BSS user initiates a full subscription cancellation based on the following specifications, and the cancellation experiences a failure at the platform of the vendor or during the communications between the two systems (i.e., timeout):
| Descriptions | BSS Portal Example | Storefront Portal Example |
|---|---|---|---|
Initial Subscription-State: |
|
| |
Cancellation Type: | Only for “Immediate” (BSS & Storefront) | ||
Process: | User triggers cancellation → Provisioning status updates to "In Progress" → During this phase, no provisioning or billing actions can be performed. This applies both to BSS and Storefront → Cancellation on vendor fails (due to client, server, or process errors) → BSS subscription status returns to its prior status before the cancellation. → Provisioning status returns to its prior status before the cancellation. → User is informed with a Vendor type error explaining the issue. → The subscription History record logs the Vendor error about the failed cancellation process. |
| |
System Notifications: | During the actual cancellation process, the user who initiated the cancellation views a cyclical loader until the cancellation is completed on all platforms, while another user who views the same subscription will witness an informative ribbon stating that a provisioning action for this subscription is ongoing. Moreover, in the event of an error, the users will be informed accordingly via respective pop-up messages (BSS & Storefront) and/or via the subscription's History records (BSS), for the Vendor error message. |
|
|
Final Subscription-State: |
| ||
Cancellation Pop-Up Window: (Pop-ups are used to confirm actions and display success/failure messages.) | It informs the user of the unsuccessful cancellation with an error message displaying the vendor-provided error description. The user can either retry and/or contact the vendor to complete the cancellation. |
| |
System Email Notifications: | Currently, no notification email is available to inform users about a failed subscription cancellation. The information is only available via the cancellation pop-up windows (BSS & Storefront) and the subscription History records (BSS). | N/A | N/A |
History Record: | A History record is added: “Subscription failed to cancel due to Provisioning Error. Please try to cancel the subscription again.” This means that the error was from the Vendor platform, and you have the option to retry canceling the subscription. Otherwise, you can also contact the vendor to try to complete the cancellation. | N/A | |
Notes: |
| ||
3. Successful Cancellation on the Vendor Platform with a Failure on Our Platform
Let’s assume that a Storefront or BSS user initiates a full subscription cancellation based on the following specifications, and the cancellation is successfully completed on the vendor platform but experiences a failure at our platform:
| Descriptions | BSS Portal Example | Storefront Portal Example |
|---|---|---|---|
Initial Subscription-State: |
|
| |
Cancellation Type: | Only for “Immediate” (BSS & Storefront) | ||
Process: | User triggers cancellation → Provisioning status updates to "In Progress" → During this phase, no provisioning or billing actions can be performed. This applies both to BSS and Storefront → Cancellation on vendor succeeds → Failure on our platform occurs → BSS subscription status returns to its prior status before the cancellation. → Provisioning status returns to its prior status before the cancellation. → User is informed with a Platform type error explaining the issue. → The subscription History record logs the Platform error about the failed cancellation process. |
| |
System Notifications: | During the actual cancellation process, the user who initiated the cancellation views a cyclical loader until the cancellation is completed on all platforms, while another user who views the same subscription will witness an informative ribbon stating that a provisioning action for this subscription is ongoing. Moreover, in the event of an error, the users will be informed accordingly via respective pop-up messages (BSS & Storefront) and/or via the subscription's History records (BSS), with our Platform error message. |
|
|
Final Subscription-State: |
| ||
Cancellation Pop-Up Window: (Pop-ups are used to confirm actions and display success/failure messages.) | It informs the user of the unsuccessful cancellation with an error message displaying our platform-provided error description. The user must contact our support team to complete the cancellation. |
| |
System Email Notifications: | Currently, no notification email is available to inform users about a failed subscription cancellation. The information is only available via the cancellation pop-up windows (BSS & Storefront) and the subscription History records (BSS). | N/A | N/A |
History Record: | A History record is added: “The subscription cancellation process has encountered an error on our Platform. Please contact your administrator”. This means that the error was from our platform, and you must contact our support team to complete the cancellation. |
| N/A |
Notes: |
| ||
Distinguishing Vendor from Platform Cancellation Errors in the Subscription “History” Log
As discussed in all the scenarios analyzed above, all cancellation actions—whether successful or unsuccessful—are recorded as informative entries in the subscription view pages under the History log section in the BSS portal. Since BSS users may be unsure about the sources of cancellation error messages, whether they originate from the Vendor or our Platform, the History log serves as the safest and most straightforward method for identifying the source of each cancellation error.
Vendor Related Errors -> Have inside the recorded log line the error message: “Subscription failed to cancel due to Provisioning Error. Please try to cancel the subscription again.“. Here, the user can either retry to cancel the subscription and/or contact the vendor.
Platform Related Errors -> Have inside the recorded log line the error message: “The subscription cancellation process has encountered an error on our Platform. Please contact your administrator“. Here, the user must contact our support team to complete the cancellation.
Distinguishing Canceled Subscriptions Between the Previous and the Current Cancellation Processes
Prior to the 3.28.174 release, all that failed-to-provision, canceled subscriptions (canceled through the previous process) had a combination of a "Canceled" Subscription Status and a "Failed" Synchronization Status on our platform. Following the 3.28.174 release, canceled subscriptions (those partially canceled or those canceled at the End of the Billing Period, via the previous process) will continue to retain this combination of statuses. However, subscriptions successfully canceled through the current process will have a "Canceled" Subscription Status and a "Synchronized" Synchronization Status.
Table of Contents
- 1 Full Cancellation Flow
- 2 Applicability of the Full Subscription Cancellation Process
- 3 Cancellation Scenarios and Handling
- 4 Distinguishing Vendor from Platform Cancellation Errors in the Subscription “History” Log
- 5 Distinguishing Canceled Subscriptions Between the Previous and the Current Cancellation Processes