Active Subscription Check

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.

Introduction

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.

Prior 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

Pre-requisites

• 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.

Active subscription check flow

Please see the Active subscription flowchart and its description below:

Active subscription check flow

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

  • Email

  • 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.

From 3.17.0

The Active subscription check is performed via Purchase API and is applicable for Digital, Print, and Hybrid subscriptions.

The three main factors of Active Subscription check are SolCon flags, Address requirements, and Search Criteria (SolCon Additional flags).

1. SolCon Flags

The Active subscription check primarily depends on the three SolCon flags under Subscription Validation, which can be turned ON or OFF while creating an offer group (Offer Groups > Additional Options > Subscription Validation> as displayed below. If any of these flags are turned ON, the Active subscription check will take place.

SolCon Flags that determine the Active sub check

• No Existing Subscription: If this flag is turned off, this check is skipped, allowing the user to purchase a subscription even if another active subscription is found. Note: Starting from version 2025.1, the definition of an 'Existing Subscription' has been expanded to include not only currently active subscriptions but also those with 'Future' and 'In-Grace' statuses. This enhancement prevents end users from creating duplicate subscriptions when a 'Future' or 'In-Grace' subscription already exists.

• Subscription Stopped Recently: If this flag is turned on, it checks whether there exists a recently stopped subscription within the last “X” days, where X (default value is 30) is configurable in the Subscribe database using the MG2 Control Api key Restart.MaxStoppedDays. If the flag is turned off, this check is skipped and the user can purchase a new subscription even if there exists a recently stopped subscription.

• No Outstanding Balance: If this flag is turned on, the Subscribe checks there exists a stopped subscription with an outstanding balance > 0. If the flag is turned off, this check is skipped and the user can purchase a subscription even if they owe a balance to the publisher.

2. Address Requirements

The Address Requirements section defines whether a subscription should be Address-only or Zip-only.

Address Requirements section

• If the subscription is address-only, then at least one of the address options (Billing Address, Delivery Address, or both) must be selected for the offer setup.

• If the subscription is ZIP-only, the Billing Address and Delivery Address checkboxes can be kept unchecked.

3. Search Criteria

If any of the SolCon flags are turned ON (one, or two in any combinations, or all three), a new Search Criteria is displayed where the additional flags for the Active subscription check can be set.

New Search Criteria section for setting additional flags for Active subscription check

• If any address options are selected in the Address Requirements section (the subscription is address-only), then the Address option under the Search Criteria will be enabled (auto-selected), and the Postal/Zip Code option will be disabled for the user.

  • For an address-only subscription, selecting additional flags (Email, Phone, and Last Name) is optional.

• If no address options are selected under the Address Requirements section (the subscription is Zip-only), the Postal/Zip Code option under the Search Criteria will be enabled (auto-selected) and the Address option will be disabled for the user.

  • For a ZIP-only subscription, selecting at least one additional flag (Email, Phone, or Last Name) is mandatory.

Note: If any of the search criteria fields (Email, Phone, or Last Name) are selected for an offer, ensure that the respective component is included in your CMS Presentation. For example, if the search option "Phone" is selected in the SolCon offer, the Phone field must be present in your CMS Presentation.

The Workflow of Active Subscription Check

Context:

A user attempts to purchase a subscription from a subscription offer displayed on the Subscription Panel or the SubCon Admin.

Prerequisites:

• At least one of the SolCon flags (No existing subscription, Subscription stopped recently, No outstanding balance) must be turned ON in the SolCon offer presented in the Panel or SubCon.

Step 1. The user enters first name, last name, and address information on the Subscription Panel or SubCon Admin.

Step 2. A lookup is performed in the Subscribe database for a subscription with fields matching the entered information. The fields that are checked depend on the flag configuration set in the SolCon during the creation of the offer.

For a ZIP-only flow:

The system will check for matching Zip Code and the SolCon additional flag(s) whichever is configured in the SolCon offer (it could be just one flag, a combination of two flags, or all three flags).

• Zip Code

• Last Name

• Phone

• Email

For an Address-only offer:

The system will check for matching addresses (Billing or Delivery) and the SolCon additional flag(s) if they are configured in the SolCon offer. SolCon additional flags are optional here. If it is configured in the offer, it could be just one flag, a combination of two flags, or all three flags).

• If both Delivery and Billing addresses are selected in the offer setup, 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.

Outcome

If any of the three SolCon flags is configured for a new start:

• The Active Subscription check will be performed.

• While checking, 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, then the check is FAILED and new start is rejected.

If no SolCon flags is configured for a new start:

• The Active Subscription check will not be performed.

• The new start flow will continue even if an exact match of the new subscription details already exists.