Active Subscription Check
Last updated
Last updated
DISCLAIMER
Product Information contained within this document, including technical information and functional specifications, is subject to change without notice. Naviga reserves the right to make any changes to the information in this document at any time without notice. Naviga makes no warranty, representation, or guarantee regarding the suitability of its products and services for any particular purpose.
The Active Subscription Check is an internal validity check that can be performed in the backend to make new starts conflicts-free. This feature ensures that a new subscription can be created only if certain specific criteria are met. With this check, Subscribe will allow new subscriptions only if there are no conflicting subscriptions are found. The main advantage of this feature is that this check ensures users will not create duplicate subscriptions for the same product and address.
This feature has undergone refactoring in version 3.17.0.
This feature exists in Subscribe both in 2.X and 3.X versions, the flow is almost the same with little difference. Active subscription check was introduced in 3.X version starting from Release 3.10 via SubscriptionAPI. In Release 3.13 the check was refactored to increase productivity.
Starting from Release 3.14.2 onwards the Active subscription check was switched to consume PurchaseAPI, the check is performed during the async part of the flow as a part of the AddSubscription call. Please find more info about PurchaseAPI and its flows here.
This document describes the Active check flow for 3.X version starting from Release 3.14.2 onwards
For Active check via SubscribeAPI the minimum Subscribe version required is 3.13.0. The check covers only Print/Hybrid/Digital subscriptions.
For Active check via PurchaseAPI the minimum Subscribe version required is 3.14.2. The check covers all types of subscriptions including ZIP-only.
Please see the Active subscription flowchart and its description below:
Step 1. User enters first name, last name, and address information on Subscription Panel/One CSR Portal.
Step 2. The lookup is made in the Subscribe database for a subscription with all fields matching the entered information. Based on the offer setup in Solicitor Concierge the following info is checked:
for a ZIP-only offer:
Zipcode
Last name
Phone
Product (ProductType should be DIGITAL)
for NOT a ZIP-only offer:
Address (Billing or Delivery, Zipcode included)
if both delivery and billing address are required then the active sub-check is performed for the delivery address only.
If the offer setting only requires a billing address, then the active sub-check is performed for the billing address only.
Last name
Phone
Product
Outcome
If NO exact match is found then the check is PASSED and a new subscription is allowed to be created.
If an exact match is found and the start type is not 'restart', then that subscription will be evaluated based on the three Solicitor flags. If the 3 flags are turned off, the new start flow continues despite the exact match existing. If at least one of the flags is enabled and matches the found subscription, then the check is FAILED and a new start is rejected.
The information about Solicitor flags can be found below:
No existing subscription at address: If turned off this check is skipped, and the user can purchase a subscription though there’s an active subscription found.
No existing subscription stopped last X days: If this flag is turned on Subscribe checks if there’s a recently stopped subscription within the last “X” days, where X (default value is 30) is configurable in the Subscribe database. If the flag is turned off, then this check is skipped and lets the user purchase a new subscription though they have a stopped subscription in the last few days.
No outstanding balance: If this flag is turned on Subscribe checks if there’s a recently stopped subscription with an outstanding balance > 0. If the flag is turned off, then this check is skipped and lets the user purchase a subscription though they owe a balance.
At Step 1 the Deliverable check can be also performed to see if the Product can be delivered to the address - this is part of another flow.