3.17.0

This page has high-level Release notes for the major 3.17.0 Release

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.

IMPORTANT!!

• If you are upgrading to Subscribe version 3.17.x and utilizing the Subscribe /Authenticate, /DigitalAccess or other endpoints in the Billing, Users, and Entitlements micro APIs, then there are breaking changes. For the full list of changes, please review the API Migration Document.

• Clients are also requested to validate their OI & Discover loads to avoid any issues following schema changes in the database.

With the 3.17.0 version, Subscribe has been integrated with Naviga Pay, making it easier to add additional payment gateways in the future. In addition, when payment is made with a credit card, the surcharge amounts can now be included. The Active Subscription Check approach has now been enhanced by including more parameters under a new section, Search Criteria. For Matrix clients, Country-Only Starts are now supported, and it is also possible to Restart a subscription at a future date.

This release also comprises a variety of enhancements to the SubCon Site (Self-service), One-CSR Portal, Solicitor Concierge (SolCon), CMS Content, and Subscription Panel modules and introduces a set of new APIs.

Additionally, this release also contains important bug fixes in various modules of the application.

The release notes for the internal stakeholders can be found in Confluence (access required).

This release has an issue with the Tax amount in the Subscription Panel when a user switches from one payment method to the other, such as from Credit Card to Bank Draft. The fix is part of 3.17.0.3.

Note added on 13 Sep 2024.

Release Prerequisites

Integrations	Minimum Version
ENGAGE	2.8.7
NCS Circ	2020-5.0
Subscribe Extracts	Version 7
Sync Jobs	3.17.0
Matrix Circ	38.00.034.ITSP9
Circ Pro	2023-2.0
DSI (Saxo Circ)	NOT SUPPORTED
Naviga Pay	2.2

This version does not support the DSI (Saxo) Circ System.

Key Features

1. Naviga Pay Integration

From this release, Subscribe has integrated with NavigaPay. NavigaPay is a payments orchestration software which provides a unified software layer (payment orchestration layer) that integrates and manages payments across multiple payment service providers. The Subscribe integration with NavigaPay allows for unified management across multiple payment service providers, ensuring reliability and convenience for Subscribe customers. With the introduction of this new feature, the additional development effort required whenever a new payment vendor has to be integrated with Subscribe will be very minimum.

In this release, Subscribe has successfully integrated with the payment vendor Payway (Edgil) through NavigaPay, where NavigaPay serves as a centralized API layer.

• Payway (Edgil) is integrated for One-CSR Portal, Self-Service Portal and Subscription Panel.

Only Credit Card (CC) Integration is supported for Payway via NavigaPay. Currently, Bank Draft (ACH) is not supported via NavigaPay. However, the existing Bank Draft feature through flat files via Circulation systems will continue to work as is.

1.1 General Workflow:

A user can initiate various payments (Restart, One-time payment, Auto-renew (EZpay), or Add Tip) using a Credit card through NavigaPay. Once the user clicks ‘Make a payment’ button, the payment page is loaded.

1. During the loading of the Payment page, the Subscribe API sends a request called StartPaymentSession to NavigaPay. The payload of this call varies depending on the consumer application. Usually the payload of this call from Self-Service Portal includes SubscriptionId, CustomerRegistrationId, PaymentType, etc. whereas the payload from One-CSR Portal includes SubscriberId, SubscriptionId, PaymentType, AccountNumber, etc.

2. NavigaPay sends IFrameUrl of the payment provider in response.

3. Self-Service Portal, One-CSR Portal or Subscription Panel (as applicable) then renders the secure URL received from the StartPaymentSession response within an iFrame of the payment provider. This page will be a hosted page.

4. The user enters their credit card details on the hosted page (including all sensitive information) and clicks the Submit or the equivalent button as the case may be.

5. The NavigaPay server then returns the details such as ProfileId (the token), GroupId, and PaymentType with other details to the consumer application (One-CSR Portal, Subscription Panel, or Self-Service Portal). The token received is the authenticated approval token from the payment provider that officially allows the payment transaction with the payment provider. This is called Tokenizing credit card.

6. Upon receiving the token, consumer application initiates the API request called EndPaymentSession. The payload of this call includes ProfileId, GroupId, PaymentType along with other consumer application-specific data.

1.2 API - NavigaPay

1. A new endpoint, POST /Authorization, has been developed for creating an authorization request based on the input parameters ProfileId (User ID associated with the transaction), TransactionAmount (amount of the transaction, which should be greater than zero), and PaymentType (type of payment: Credit Card, Bank Account, etc.).

2. A new endpoint, POST /Capture, has been developed to capture a payment transaction based on the input parameters TransactionID (the transaction ID obtained in the authorization request) and the PaymentType.

3. A new endpoint, POST /Sale, has been developed for creating a sale transaction, which involves creating an authorization request and capturing the payment transaction based on the input parameters ProfileId, TransactionAmount, and PaymentType.

4. A new endpoint, GET /Profile, has been developed for retrieving a user's profile details as well as payment information based on the input parameters ProfileId, GroupId (Optional, Group ID of the User associated with the transaction), and PaymentType.

5. A new endpoint, POST /Session/Start, has been developed to initiate a new session based on the iFrame URL configuration.

6. A new endpoint, POST /Session/End, has been developed to terminate a session following the verification of the provided input parameters ProfileId, GroupId, and PaymentType.

7. The NavigaPay API has now been successfully integrated with all the payment gateway-related operations, such as Single payments, New starts, EZPay, Restarts, and Tip, allowing NavigaPay to be utilized as a payment gateway.

8. Authorization and sale transactions processed using NavigaPay will now send the value defined in the MG2 Control API Internal setting "NavigaPay.StatementDescriptor" in the StatementDescriptor field. A new MG2 control internal setting, NavigaPay.StatementDescriptor, has been introduced for setting the description of charges or payments that should be displayed on bank statements.

Payway Integration - CMS Configurations

The users can configure the properties for SP Newstarts by going to:

• CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > PaymentMethodsV3 > NavigaPay Payway V3

• "The 'ErrorOnLoadMessage' property has been removed from the 'NavigaPay Payway V3' component. Although this property is available in the standard Payway integration, it was not included in the Payway NavigaPay component due to its lack of support by NavigaPay. that context. Consequently, the property has been removed from the 'NavigaPay Payway V3' component."

Implementation Notes:

The detailed Implementation settings for NavigaPay integration is available here: NavigaPay - Subscribe Integration - Subscribe - Confluence (atlassian.net)

2. Credit Card Processing Fee

Starting from this release, there is a requirement of the integration of credit card processing fee to the payment details, if the payment method selected is credit card. To suffice this, Payment page has been revamped to be a wizard presentation. The new payment wizard can submit all the payment variables in a single iFrame as required. The new payment wizard first collects all payment details and then completes the payment process in three different steps as follows:

1. Gathering information step

2. Showing payment details step

3. Final printable payment summary step.

2.1 Integration of Credit Card Processing Fee

Starting from this release, NCS clients will be able to charge a processing fee over the total amount if the customer makes payment through Credit Card. For other mode of payments, the processing fee is not applicable. The charging of processing fee can be set on or off using the MG2 Control Api setting key Billing.CreditCard.ProcessingFee.Enable.

In this release (Phase 1), if the MG2 control key is enabled, the credit card processing fee will be applicable as follows:

1. New starts via Subscription Panel

2. One-time payments

3. EZpay payments

4. Restarts via Self-Service Portal

Additionally, it will be possible to define the percentage of processing fee that can be applied on the overall amount using the MG2 control Api key Billing.CreditCard.ProcessingFee.Percentage when a user is transacting via Credit Card.

A tax on processing fee has also been introduced in this release and it will be configurable via MG2 Control Api key Billing.CreditCard.ProcessingFee.Tax.Enable. The percentage value of the tax will also be configurable via MG2 Control Api key Billing.CreditCard.ProcessingFee.Tax.Percentage.

The tax on Processing fee has been implemented from a future perspective. NCS does not support Tax on processing fee as of now.

If the processing fee is enabled via MG2Control for a client, it will be applicable to all offers of the client if the customer chooses to pay via Credit Card.

The processing fee will be calculated on the total amount a customer has to pay (rate + tax i.e. including taxing and any other applicable fee, tip, etc). On top of it, if tax on processing fee is also applicable, it should be calculated on the processing fee.

Credit card processing fee notifications to the user

When a customer selects credit card option for payment, they will be informed with a message on Self-Service Portal below the payment summary, about the processing fee being charged because of their selected payment method. Two CMS contents ProcessingFee.OneTime.Message and ProcessingFee.Recurring.Message have been introduced where the information messages can be configured for one time and recurring payments.

2.2 SS Payment Flows

One-time payment in SS:

In the first step (gathering information step), select a payment option with Term and Amount. Choose the option of leaving a tip and making a donation, opt or not for EZpay, and also select the payment method from Credit card and Bank account options.

In the next step, all payment details will be displayed, including credit card processing fee (if applicable for the client). Payment method details (Credit card details or Account details) will also be collected.

In the final step, the wizard displays the printable payment summary. In One-time payment, the Processing fee notification to the user set up in ProcessingFee.OneTime.Message will be displayed only if Processing Fee > 0.

Restarts in SS:

For Restart payment (on Restart page), the restart date is also collected in step1 along with other details (Payment option, Tip, Donation, & Payment method type). In this flow, step 2 (displaying payment details) can be skipped if the user has nothing to pay. In such cases, if the subscription has a credit balance, it will be deducted from Total resulting in TotalAmount to be paid as 0, indicating nothing to pay. In step 3, the user will be displayed a printable payment details summary including processing fee if the payment method is credit card.

During Restarts, the notification message set up in the ProcessingFee.OneTime.Message will be displayed only if Processing Fee > 0. The ProcessingFee.Recurring.Message will be displayed if the selected Payment Option forces EZPay Sign Up.

EZPay Sign Up:

For EZPay payment (on AutoPay SignUp page) the Processing fee will be calculated only if the subscription has an Outstanding Balance (the subscription has a debt to be paid) and the payment is done through credit card. The processing fee will be calculated over the outstanding balance. In Step 1, AutoPayOption, Tip, Donation, Terms and Conditions, and Payment method type will be collected from the user. The Processing fee and Processing fee tax (if applicable) will be calculated and displayed in Step 2. The final printable payment details including processing fee (if any) will be displayed in step3.

Note that if there is no outstanding balance, processing fee will not be considered for EZPay sign up workflow.

During EZPay sign up, the notification message set up in ProcessingFee.Recurring.Message will be displayed always. The ProcessingFee.OneTime.Message will be displayed only if Processing Fee > 0.

Tip Payments:

For Tips payment (on AddTip page) the Processing fee will be calculated over the Tip amount being paid (only for one-time Tip with Non-EZPay payment) through credit card. In step1, the Tip amount is collected along with the payment method type. If it is credit card, then in the second step, Processing fee and the tax (if any) will also be displayed along with the payment method details. If the payment is recurring (EZpay checkbox is checked), this second step will be skipped. then in the final step, all the payment summary will be displayed including processing fee. If the Tip payment is just one time, then the ProcessingFee.OneTime.Message will be visible only if Processing Fee > 0. If the Tip payment is recurring, then the ProcessingFee.Recurring.Message will be displayed.

During any payment flows, a user can navigate from one step to the next step by clicking the Next or Ok, and to the previous step by clicking Back buttons displayed in the wizard.

Implementation Notes:

• New CMS contents Step.Next, Step.Back, ProcessingFeeAmount.LabelText, ProcessingFeeTaxAmount.LabelText, PaymentMethod.CreditCardText, PaymentMethod.BankAccountText, AddTip.TotalAmountText, SelectOptionStep.Title, SelectOptionStep.Description, PaymentInfoStep.Title, PaymentInfoStep.Description, ConfirmStep.Title, ConfirmStep.Description have been created.

• New CMS contents ProcessingFee.Recurring.Message and ProcessingFee.OneTime.Message have been introduced for Payment, AutoPaySignUp, SubscriptionRestart and AddTip payement workflows.

• Subcon.Configuration: "DisplayPayButton" property has been removed from Payment page. “RenewalOptionsSection” is also deprecated. Both were under the SubcriptionRestart module.

2.3 Subscription Panel Payment Flows

1. If the processing fee property has been enabled in CMS, SP will now pass on the processing fee amount received from the Subscriptions API, CalculateSubscriptionCost, along with the amount charged, to the Purchase microAPI applicable for the credit card payment method.

2. The Input Box properties, "Disclaimer.Message" and "Disclaimer.Show", have now been included in the User Information V3 and Payment Methods V3 components.

   • If the "Disclaimer.Show" property is enabled (set to ON) in CMS, the Disclaimer Message will be displayed on the applicable sections of the Subscription Panel page based on the value defined against the "Disclaimer.Message" property. If the property has been set to OFF, the disclaimer message will not be displayed.

   • In addition, the disclaimer message, if turned ON, will only be displayed on the payment method screen if the selected payment method is a Credit Card. This functionality is applicable for Seamless flow as well.

3. Two new properties, "CreditCard ProcessingFee Show" and "CreditCard ProcessingFee Title," have been added to the StickyNoteV3 and StepV3 components.

   • If the "CreditCard ProcessingFee Show" feature in CMS has been enabled (set to ON), the Processing Fee will be displayed on the Subscription Panel page when the payment method selected is credit card. The CreditCard ProcessingFee Title property allows users to change the title of the processing fee that appears on the Subscription Panel page. The processing fee will not be displayed if the property has been set to OFF.

   • In addition, if the ProcessingFee property has been set to ON, it will only be displayed on the payment page if the payment method selected is a Credit Card.

   • The processing fee for a payment will be calculated using the Billing API, CalculateProcessingFee, and the total payment amount, including the processing fees for the chosen offer and product, will be calculated using the Subscriptions API, CalculateSubscriptionCost.

   Note:

   1. If the user wants the processing fee, the "processingFee" property in CMS must be enabled in all StepV3 and StickyNoteV3 components.

   2. If the processing fee is not required, the "processingFee" property should be disabled in CMS for all StepV3 and StickyNoteV3 components to ensure consistency across all of the steps.

Implementation Notes:

In CMS, the Processing Fee property should be set to either ON or OFF.

The user can configure the properties by going to:

• CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > Processing Fee property

• CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > StickyNoteV3 > Processing Fee property

• CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > UserInformationV3

• CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > PaymentMethodsV3

2.4 Processing Fee in Email Receipts

The credit card processing fee/tax on processing fee can be explicitly displayed in email payment receipts to the customer.

To achieve this functionality, the fee has to be configured as a parameter (SurchargeAmount) in the Credit Card Payment event type email. (The SurchargeAmount is a column from the Event_log table.)

How to configure the Credit Card Payment event type email?

1. Navigate to One-CSR Portal > Event Management > Event types emails

2. Filter the search by the option Event type ID and enter ‘30’ in Contains field.

3. Click Search > Edit on the search result grid.

4. Click tab Customer emails. Select Templates > Credit Card Payment Receipt.

5. Click Edit and add the required details and Save.

When a payment is done via Credit Card with Processing Fee settings enabled and the receipt mail successfully configured, the processing fee amount will be reflected in the payment receipt email as shown below:

Note: For Subscription Panel New start, the SurchargeAmount (processing fee) will be captured with event_type_id 3. For transactions conducted through SubConSite, the event_type_id will be 30.

2.5 API Dependencies

1. Clients have the option to enable the addition of a surcharge or additional fees when a subscriber pays with a credit card, based on the value defined in the MG2 control settings. The Billing API now includes a new endpoint, POST /Billing/CreditCards/ProcessingFee, for calculating the processing fees that will be charged to the user based on the payment amount for a credit card transaction.

2. The Purchase API endpoint, POST /Purchases, has been modified to add two new input parameters, ProcessingFeeAmount and ProcessingFeeTaxAmount, which allow the credit card surcharge amount to be passed on to the NCS Circ system.

3. The POST /Payment, POST /Payment/Restart, and POST /Payment/Tip endpoints have been modified to add two new input parameters, ProcessingFeeAmount and ProcessingFeeTaxAmount, to send the surcharge amounts to the NCS Circ.

   The surcharge amounts are only applicable for the Payment Type of Credit Card; providing any value for this for any other Payment Type will result in an error.

4. The POST /Subscriptions/Cost endpoint has been modified as follows:

   • A new input parameter, PaymentTypeId, has been added to represent the Solcon Payment Type. (1 - CreditCard, 2 - BankAccount, 3 - Cash, 4 - Check, etc.)

   • If processing fees are applicable or have been enabled in the settings for a credit card payment method type, the output parameters ProcessingFeeAmount and ProcessingFeeTaxAmount will now be included in the response.

   • If an activation fee has been setup for an offer, the activation fee output parameter will always be included in the response, regardless of the PaymentTypeId in the request.

Implementation Notes:

Four new internal MG2 control settings for calculating processing fees have been introduced.

1. Billing.CreditCard.ProcessingFee.Enable - Enable (1) or disable (0) the addition of processing fees.

2. Billing.CreditCard.ProcessingFee.Percentage - The percentage of the transaction amount that will be applied as the processing fee. For example, the client should set the value to "10" for 10% and "10.5" for 10.5%.

3. Billing.CreditCard.ProcessingFee.Tax.Enable - Enable (1) or disable (0) whether tax should be applied.

4. Billing.CreditCard.ProcessingFee.Tax.Percentage - Tax percentage to be applied.

Pre-Requisites:

• Circ System & Minimum Supported Version: NCS Circ, 2018

3. Country-Only Starts in Matrix

Previously, Subscribe allowed users to create a subscription by validating their addresses using three different options: either providing their delivery address, their billing address, or just entering their zip code. Recently, Subscribe has been updated to allow the creation of digital subscriptions for Matrix clients, with just the Country field as the minimum address requirement.

The Purchase API has been updated to enable Matrix clients to purchase subscriptions by only providing the Country as the address information. In the Matrix ADDADDRESS event, if just the Country has been entered as the address, the Address will have the House number as Null (0), the Country Code will remain as the provided Country Code, and the Street Name will be Country Name.

Note:

1. Country-only Starts flow for Matrix will also work on Seamless flow.

2. If a country-only address has been provided for a non-Matrix client, a validation error will be returned, but the flow will continue to be executed for Matrix clients.

Implementation Notes:

The user can configure the property by going to: CMS > Subscription Panel > Presentation > Choose a valid presentation

• To display the Country drop-down in the country-only start flow for Matrix, set the ‘IsInternational’ property in the Presentation Properties V3 component to ON.

• In Country only start flow for Matrix, properties related to Country should be ON in Billing component ('AddressLine Show', 'SecondAddressLine Show', 'Zipcode Show', 'State Show', 'PhoneNumber Show', etc. should be kept OFF).

• In BillingInformationV3, the below properties should be enabled for country-only start flow for Matrix:

  • Country.OptionalNextToPlaceholder

  • Country.OptionalNextToTitle

  • Country.Placeholder

  • Country.Show

  • Country.Title

  • Country.ValidateOnFocusLost

  • Country.Validation.Required.Apply

  • Country.Validation.Required.Message

• The following properties in IndependentAddressV3 should be enabled for country-only start flow for Matrix. If these properties do not exist, they must be added using the Management tool script; otherwise, they will break during the environment upgrade.

  • Country.Placeholder

  • Country.Show

  • Country.Title

Prerequisites:

1. The country-only rule must be set appropriately in the Matrix system for each country where country-only starts are allowed. Currently, the list of countries displayed in SP is not governed by the Matrix Country-Only rule. As a result of this limitation, if the country-only rule has not been enabled for any country in Matrix and the same country has been included in the list of countries displayed in SP, then the subscription will result in an error while it is being processed on the Matrix side, but no error occurs on the SP side during the purchase process.

2. Circ System & Minimum Supported Version: Matrix, 38.00.034.ITSP6

4. Scheduled Restarts for Matrix clients

Starting from this release it is possible for Matrix clients to select a restart date in the future for restarting a subscription. Previously whenever an eligible user opts for restarting a stopped subscription, Subscribe MicroAPI used to default restarting date to the current date in the client’s time zone. However, with this new enhancement, it is now possible for a user to opt for a future date as well as the current date for restarting the subscription. The user will not be permitted to select a restart date lesser than the current date in this flow.

Note:

1. The Matrix system may fail to restart a subscription if a certain address is part of more than one delivery route.

2. When a Matrix user completes the payment for a stopped subscription that is intended to be restarted on a future date, the status of the subscription changes from ‘Stopped’ to ‘Active’ immediately. This was mainly due to differences in the behavior and functionality of One-CSR Portal compared to the processing system, Matrix. According to Matrix settings, even if the subscription status changes to 'Active' immediately, the subscription will ideally start for the user only on the selected date.

5. New UI changes for Active Sub Check

In Subscribe, whenever a new subscription is created, an Active Subscription Check is performed at the backend if at least oneD of the flags (No existing subscription, subscription stopped recently, No outstanding balance) is set under Subscription Validation section in SolCon. If any of the flag is set, then a new subscription can only be created if the Active Subscription Check is passed. When performing an active subscription check using the PurchaseAPI, the API currently depends on the SolCon Offer flags for Delivery Address and Billing Address (under Address Requirements). If at least one of those flags is turned on, then the API executes the full address Active Sub Check (PakHash, LastName, Phone and Product). Otherwise, it executes the Zip Only Active Sub Check (ZipCode, LastName, Phone, Email and Product).

This approach has now been updated from this release. A new section called Search criteria has been introduced in SolCon (Offer Groups > Additional Options) with some additional flag fields. New validation checks have been implemented in the existing Active sub check to not to depend on just two Address fields, but also include the flags (under Search Criteria) as stated below.

1. Last Name

2. Phone

3. Email

4. Address

5. Zipcode

The users can select which flags are to be used for the Active sub check.

Note:

• Since the product is always included in the search and cannot be excluded from the search criteria, it isn't displayed in the UI.

• The 'Search Criteria' section will be displayed only if any of the checkboxes in the 'Subscription Validation' section are checked (one, or two in any combinations or all three))

If an Offer is not correctly set up in SolCon, the Purchase endpoint will now return a validation error. The following validation checks will be performed:

• At least one of the Search Criteria flags must be enabled. If none of the search flags is enabled, then another validation message will be displayed “Please select at least one search parameter”.

• Selecting Last Name alone or Zip Code alone is insufficient; any other flag also must also be enabled.

• If the user selects either Last Name or Zip Code only, then a validation error message will be displayed, “Please select one more search parameter”.

• Zip Code and Address cannot be enabled simultaneously.

• If any single Address flag under Address requirements section is checked, then by default, the Address flag under Search Criteria will be enabled. If both Address flags are unchecked, then the Zip Code flag under Search Criteria will be enabled automatically making the Address flag disabled.

• If any checkboxes were checked before they became disabled then they are considered as unchecked.

• If the Phone is not available at a subscription level, we skip this check

• If an existing Subscription with the same characteristics has been found in the database, the purchase endpoint will return a validation error and the purchase will not happen. For example, if the Offer has been set to check Last Name and Email and there already exists a Subscription for John Doe (email: [e-mail]), another Newstart with the same data will be rejected.

Implementation Notes:

After upgrading to V3.17.0, scripts must be executed to apply the standard Active Subscription Check logic to existing client offers. These scripts will update offers created before the upgrade to include the default search criteria. However, the search criterion "Phone" is exempted from these validations.

6. Adding Tip for non-EZPay Subscriptions

With this release, NCS subscribers with non-EZpay subscriptions can now pay a Tip to the publisher. If the subscription is non-EZPay, the checkbox “I want to leave a recurring tip” will be hidden from the user.

Initially, the Add Tip page was designed exclusively for EZPay subscriptions. However, starting from this release, non-EZPay subscriptions can also process a non-recurrent Tip.

Validation checks have been implemented in the Add Tip Availability API (GET /Billing/{subscriptionId}/AddTipAvailability) to allow only EZPay subscribers to add a Recurrent Tip; however, no checks will be performed for One-time tips. One-time tips will not be acceptable for digital or stopped subscriptions, but will be allowed for Paused and In-Grace subscriptions. For subscriptions without EZPay, the recurring tip is not allowed.

7. Configurable Credit Balance Usage

With the introduction of an MG2 Control API setting key Restart.ApplyCreditBalance (with a default value 0), credit balance adjustments have become configurable for both Self-Service Portal and One-CSR Portal from this release. If the setting is turned on and the subscription has a credit balance (user owes money from the publisher), that balance will be displayed in UI and will be deducted from the TotalAmount to be paid. If the setting is turned off and the subscription has a Credit balance, that balance will NOT be displayed in the UI and the total amount remains the same without any deduction. If the subscription has no balance, or has negative balance (customer owes money to publisher), the debt will be paid in the Restart payment transaction.

While submitting payment request during Restart flow, a new API key Restart.ApplyCreditBalance will be considered in the TotalAmount calculation logic as follows:

• If the setting is turned on and the subscription has a Credit balance (positive amount), that balance will be deducted from the TotalAmount.

• If the setting is turned off, the Credit balance will not be considered in TotalAmount calculation.

• Regardless of the value in the setting key Restart.ApplyCreditBalance, if the customer has a negative balance (i.e if they need to pay the company), the balance amount will be considered for TotalAmount calculation. The balance will be added to the TotalAmount to be paid.

If the total amount to restart a subscription (Restart+Tip+Donation) is less than or equal to available credit balance, then One-CSR Portal will allow a CSR/user to submit the restart request without payment.

In this special case, the payment iFrame will be hidden and other payment buttons such as Pay with credit card (or Bank Account) will be disabled. Only the action buttons Submit Restart and Cancel will be enabled. On clicking Submit Restart, the restart request will be submitted to microAPI and ultimately to the corresponding circulation system. On clicking Cancel, the current transaction will be cancelled as it is now. This special case works only if the MG2 setting Restart.ApplyCreditBalance is turned on.

If a subscription with a positive credit balance has been Permanently Stopped, the remaining balance will either be donated or refunded, and the subscriber has to pay the full amount when restarting the subscription.

• This is applicable to NCS and Matrix clients as of now.

Implementation Notes:

New MG2 Control setting key Restart.ApplyCreditBalance has been introduced with default value 0 (FALSE).

8. Enhancements on Household Level Page

8.1 HHL in One-CSR Portal

A new menu option, Household Level (HHL), and a corresponding page, have been introduced in One-CSR Portal to facilitate the management of various Household levels for clients. With this enhancement, CSR Admin/users can now edit the description of a Household level, providing a meaningful explanation to each Household level.

This new page is accessible under the Client Management menu option in the sidebar. The enhancement aims to assist clients in understanding the meaning of each HHL through its Description. Moreover, users have the flexibility to edit the description for added clarity. The description feature has been incorporated in all instances where clients are prompted to select an HHL or where an HHL is displayed, enhancing its significance. Examples include the Subscription search screen, Entitlements screen, etc.

The new menu option and page - Household Level

• You can filter and search for existing Household levels using either the 'Description' or 'Household level' by selecting the appropriate option in the 'Filter by' drop-down. If you're filtering by 'Description,' enter any word in the 'Contains' field and click 'Search' to list all Household levels with that word in their description. If you're filtering by 'Household level,' enter a numeral in the 'Contains' field and click 'Search' to list all Household levels in the Search result grid that contain the entered numeral in their ID.

• A ‘Show only active’ checkbox is also available to further refine the search results.

  

  Filtering Household levels with their IDs that contain the numeral '2'

• You can edit the Description of any Household level by clicking the 'Edit' button next to the Household level displayed in the search result grid. The maximum allowed character limit for a description is 50.

• Household level description will be now available wherever Household level is displayed in the application.

  For example, in One-CSR Portal: 1. Account information tab of the user (Subscription Information > Subscription search > Enter search criteria > Search > Start call) 2. Entitlement details screen (Client management > Entitlements > Entitlement details > Edit > Access section)

• If a Household level has no description, the description field of the corresponding HH level will be blank.

• In cases where the HH level description is displayed in a drop-down and the description is truncated, the full description will be available in a tooltip when you hover the mouse over it. Also, in a drop-down the description will now be available in the format “HHL ID - Description”.

8.2 HHL in SolCon

With the new enhancement, the HHL description from One-CSR Portal will now be available at the following pages in SL:

1. Household levels page (Reference Tables > Household Level)

2. Edit Offer group page (Offer Groups > Select an offer > Coding)

3. Edit Offer page (Offer > Select an offer > Coding)

Changes made to a Household level in One-CSR Portal are immediately reflected in the database. However, these changes will appear in SolCon (in the above mentioned instances) only after the successful completion of the synchronization job. Thus, the HHLs in One-CSR Portal will be available in SL while creating offer groups too.

Implementation Notes:

• New claim has been introduced, ‘SA_NewspaperManagement_HouseHoldLevel’ in mg2_control database.

• A new row ‘Household level’ has been added to the table adm_main_menu_v2 table in Subsvc database.

8.3 API - Entitlements

The HouseHoldLevels table schema has been updated to include a new property, Description, for the household levels.

HHSubscriptionLevel is HouseHoldLevelId

The HouseHoldLevels table schema previously included HouseHoldLevelId, HouseHoldLevel, Active, and Audit fields. The HouseHoldLevelId and HouseHoldLevel have now been merged into a single column, and a new column, Description, has been added, so that the HouseHoldLevels table schema now has HouseHoldLevelId, Description, Active, and Audit fields.

The Entitlements API endpoints GET /HouseHoldLevels/{houseHoldLevelId} and GET /HouseHoldLevels have now been modified to display the new property, Description, for the respective Household-Level Identifiers in the API response.

Implementation Notes:

The Description should be included while setting up the HouseHoldLevels.

Modified endpoints:

• GET /HouseHoldLevels/{houseHoldLevelId}

• GET /HouseHoldLevels

8.4 Household Level Removable from One-CSR Portal UI

Prior to this release it was not possible to remove a Household level entry from the Access section of the Entitlement details page. Starting from this release a Delete button has been introduced against each Access level entry for all clients.

Clicking the Delete button will prompt a confirmation message with OK and Cancel options. If you select OK and then hit Save button at the bottom of the page, the deletion process will be completed. Selecting Cancel option will cancel the deletion process.

If you attempt to delete the last Access level record from the Access section, the system will display a warning message stating, ‘At least one record is required in Access levels’.

8.5 Database changes for Sync jobs

The DB changes to implement HHL management are as follows:

• Changes in HouseHoldLevels table: HouseHoldLevel column is deprecated, Description column added.

• Change in Subscription table: hhSubscriptionLevel renamed to HouseHoldLevelId

9. eBill Availability

A new endpoint eBill availability has been created that executes all the conditions to check whether a subscription is eligible for eBilling. A subscription will be eligible for eBilling if it is not stopped, and it is not on EZPay. As an output model, 2 flag values will be returned to indicate if the user can sign up (SignUpAllowed) or manage eBilling (ManageAllowed). In case the subscription is Stopped or if it is on EZPay, validation errors will be displayed to the user.

If a subscription is already on eBill, the flag value of SignUpAllowed will be false and ManageAllowed will be true. If the subscription is NOT on eBill, the flag value of SignUpAllowed will be true and ManageAllowed will be false.

Self-Service Portal will start using the eBill availability endpoint from this release to evaluate whether a subscription is eligible for eBilling and has enough rights to access the corresponding eBilling page (eBill Sign up page or eBill Manage page).

• If a user tries to access the EBillManage page, and not subscribed to EBill (ManageAllowed flag value -> false), the user will be redirected to EBillSignUp page.

• If an already subscribed user tries to EBillSignUp page (SignUpAllowed flag value ->false), the user will be redirected to EBillManage page.

• If there is a validation error in the API and the error is displayed, then the user gets redirected to the Dashboard page.

10. BPay Integration with Subscribe

Naviga Subscribe has successfully integrated with BPay, an Australian Payment Gateway starting from this release. The BPay generates a unique Customer Registration Number for its customers, and it will be displayed on Self-Service once customers link their account with their subscription.

10.1 API - BPay

1. A new API, BPay, has been developed to handle the integration between the BPay and Subscribe.

2. The Post /Bills endpoint creates a new Bill in BPay based on the below input parameters.

   • billerCode: The code of the biller issuer (the newspaper)

   • dueAmount: The amount of the bill

   • customerNumber: The identifier of the newspaper client. (Account number).

   • includesCheckDigit: If it is a customer number that has previously made a bill, set 'true'; otherwise, set 'false'.

   • dueDate: The bill's issuance date (dd/mm/yyyy)

   • generateQRCode: Optional; Set 'true' to add a base64 QR code that represents the bill in the response body.

   • qrCodeImageType: Optional; The variable that defines the QR code format, e.g., 0: PNG and 1: JPEG.

   • qrCodeIncludeAmount: Optional; Set 'true' to include the bill amount in the Base64 QR code generated.

3. The Post /CRNs endpoint creates a new Customer Reference Number (CRN) in BPay based on the below input parameters.

   1. BaseCustomerNumber: The identifier of the newspaper client. (Account number).

   2. TransactionId: A unique identifier for the customer number for which the Check Digit is being calculated. This will be returned in the response and can be used to match up the response and request object elements. As a result, it must be unique for each customer number in this request. (For this reason, a random GUID represents the transaction ID.)

Implementation Notes:

MG2 Control internal settings "BPayUrl.Url", "BPay.ClientId", "BPay.ClientSecret", and "BPay.BillerCode" must be configured in Mg2Control DB for any client that uses BPay services.

10.2 API - Purchase

After creating a new subscription, the Newstart flow now includes a step to generate a Customer Reference Number (CRN) in BPay for Australian clients.

A new MG2 control internal setting, Purchase.GenerateCRN, has been added to define whether the step required for generating a customer reference number (CRN) must be executed. In order to generate a CRN, the value should be set to (1) for the specific client.

The generated CRN will be stored in the Subscription table under the CustomerReferenceNumber column and in the Event Log table under the misc_code1 column.

Implementation Notes:

• When the Newstart event is fired (event_type_code = 'STARTSTD'), the field "misc_code1" in Event_log table is populated with the new Customer reference number (CRN).

• The setting Purchase.GenerateCRN must be configured as 1 for a specific client to generate a Customer Reference Number (CRN).

10.3 API - Subscriptions

The Get Subscription by ID endpoint, GET /Subscriptions/{subscriptionId}, has been updated to return an additional output parameter, CustomerReferenceNumber, in the Subscription object of the API response.

10.4 Display Customer Reference Number in One-CSR Portal and Self-Service Portal

This functionality is only applicable to BPay.

The Customer Reference Number is now displayed on both One-CSR Portal UI and Self Service portal UI.

• With the introduction of a new property in the Subscription object that provides the associated Customer Reference Number, it is now possible to display the Customer Reference Number within the Account Information tab of SA. Note: If the value in API response is blank, then the field will not be displayed. Also, the value is completely read-only.

Customer Reference Number in SA

• Customer Reference Number will be displayed in the Subscription Information box in Update Subscriber page of SS. The field is available only for Australian clients as of now and is configurable from Subcon.Configuration.

Customer Reference Number in SS

Implementation Notes:

• The MG2 Control Api setting keys BPayUrl.Url, BPay.ClientId, BPay.ClientSecret, and BPay.BillerCode must be configured in MG2 Control DB for any client that use BPay services.

• When the Newstart event is fired (event_type_code = 'STARTSTD'), the field "misc_code1" in Event_log table is populated with the new Customer reference number (CRN).

• The setting Purchase.GenerateCRN must be configured as 1 for a specific client to generate a Customer Reference Number (CRN).

• New CMS content SubscriptionInfo.CustomerReferenceNumber and new Subcon.Config setting under SubscriberUpdate -> SubscriptionInformationSection: DisplayCustomerReferenceNumber.

• The Customer reference number field will be visible only if there is a response for CustomerReferenceNumber in Start Call API (/api/startCall/Subscription/subscriptionId?paperCode=).

11. Auth0 Customized Workflow with Connection Parameter

11.1 Auth0 - Add the possibility of passing a Connection through the Universal Login Page

Auth0 Universal Login Page will now be able to receive a custom connection through Query string for using a different authentication source (by default Auth0 uses Auth0 DB). The connection parameter will be mapped to a MG2 Control Api setting Auth0.App.Connection with default value “Username-Password-Authentication“. Implementation Notes:

• A new MG2 Control Api setting Auth0.App.Connection has been added with “Username-Password-Authentication“ as the default value.

• For the client Winnipeg, the Api setting value will be ‘Naviga-SAML-POC’.

  If the default value of Api setting is not changed, then there is no impact. If any other valid value is set, then Auth0 will use it to redirect to the right login page.

11.2. Restrict the create user flow based on config flag

This has been done to handle client-specific flow.

Previously, when a user's entered email address in SP wasn't found in the client's database, the input fields to create a new user were displayed.

Changes have been implemented to prevent users from creating new users based on the value defined in the SP config file.

1. In the SP config.System, a new property called "RestrictCreateUser" has been added.

2. In CMS, a new property, "Email RestrictCreateUserMessage," has been added to the UserinformationV3 component.

Now, the CreateUser flow will work such that:

• If the value of "Config.System.RestrictCreateUser" has been set to True and a message has been entered in the "Email RestrictCreateUserMessage" property under the User Information component in CMS:

  • If the entered email address already exists in the database, the user will be able to continue with their subscription.

  • If the entered email address does not exist in the database, the Continue button is disabled, and the message set in the "Email RestrictCreateUserMessage" property will be displayed on the screen.

• If the value of "Config.System.RestrictCreateUser" has been set to False, the system will continue the existing flow and display the fields for creating a new user.

Implementation Notes:

1. Add and set the "RestrictCreateUser" property to "true" in SP config.System.

2. In CMS, add a message to the "Email RestrictCreateUserMessage" property of the UserInformation component.

   The user can configure the properties by going to: CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > UserInformationV3

---

General Enhancements

Self-Service Portal

1. New CMS restriction for Carrier Collect subscriptions

A new CMS Restriction called ‘Carrier Collect’ has been introduced in this release. This restriction can hide/unhide a SS link based on the subscription’s billing method. When a subscription’s billing method is set to Carrier Collect, and a Carrier Collect restriction is configured for the corresponding SS link in CMS, the link will not be visible in the Self-Service Portal page .

For example, if a subscription’s preferred billing method is Carrier Collect, there is no need to display a ‘Make a Payment’ link on the Self-Service portal. This specific SS link can be hidden from CMS by configuring the newly introduced CMS restriction on the ‘Make a Payment’ link.

Implementation Notes: CMS > Navigation > Links/(Choose a valid link)> Hide Link For >Add ‘Carrier Collect’

2. FAQ Page for all clients

From this release, the FAQ page has been made available for all the clients. The contents of FAQ page can be configured from CMS as per your requirement.

Implementation Notes:

Any SS page can be displayed by following two configuration steps in CMS.

Prerequisite:

Navigate to SS and login to the dashboard page. From the URL displayed in the address bar, delete /dashboard and type in /faq to navigate to the newly created FAQ page. Copy the URL of the FAQ page.

Step 1: Generate a hyperlink to the new page from the CMS Links page.

• Select the Newspaper on the top menu bar.

• Navigate to CMS > Navigation > Links.

• Paste the copied URL to the Href field.

• Enter data in all the other mandatory fields.

• Click Save button to generate the hyperlink.

• Clear Cache: Manage Cache > Refresh CMS + Site.

Step 2: Configure the link on CMS Menu page.

• Navigate to CMS > Navigation > Menu.

• Select an option from the Menu drop-down under Link Assignment section. (Navbar, BillingMenu or SubscriptionMenu)

• Drag and drop the FAQ link from the Available links section to the Menu Links section.

• Click Save.

Note:

You can successfully configure a hyperlink only at three sections of an SS page.

1. As a menu option on Navbar

2. As a hyperlink in the SubscriptionMenu (Subscription Details section) of Dashboard page

3. As a hyperlink in the BillingMenu (Billing information section) of Dashboard page.

3. Deprecated Credit Card images section

Starting with this release, the credit card icon will no longer appear within the iFrame on the Payment page when a credit card is selected. Previously, when users entered their credit card number in the iFrame, the corresponding credit card icon would be displayed. The display of the AMEX credit card icon was previously controlled by the MG2 Control setting 'AmericanCardsImages.' However, in this release, this property has been removed. As a result, during credit card payments, no credit card icon will be shown within the payment iFrame.

Implementation Notes:

"AmericanCardsImages" property is removed from CreditCardSection, inside BillingWidgetSection, for all clients.

4. Customizable iFrame fields for Braintree

The Braintree hosted field place holders (in payment iframes) can now be customized by CMS contents. Previously these iframe field placeholders were hardcoded.

Implementation Notes:

The following CMS contents are used in Braintree payment iFrame from this release:

• Placeholder.CCName

• Placeholder.CCNumber

• Placeholder.ExpirationMonth

• Placeholder.ExpirationYear

5. New Page with Update Subscriber section

A new page, UPDATE SUBSCRIBER (Url: /subscriber/update) has been introduced in the Self-Service Portal, allowing only owners to edit their subscriber data. The new page includes an editable section, 'SUBSCRIBER INFORMATION,' which was previously part of the MyProfile page. The entire content on the page is CMS-driven. The page also has a read-only section where some subscription information is displayed which was previously a part of the MyProfile page.

Following this new development, MyProfile page no longer displays subscriber or subscription related information. The MyProfile page will only have registration fields (email, password and profile data sections).

This new page will be owned by Subscribers and hence it is restricted for guests and they will not have edit permissions on this page.

Implementation Notes:

New page and contents have been added to CMS (SubscriberUpdate). In Subcon.Config, SubscriberUpdate module has been added with SubscriberInformationSection and CurrentMembersSection. The CurrentMembersSection was removed from MyProfile page.

To display the hyperlink to this newly generated page on SS, follow the below two configuration steps in CMS.

Prerequisite:

Navigate to SS and login to the dashboard page. From the URL displayed in the address bar, delete /dashboard and type in /subscriber/update to navigate to the newly created Subscriber Update page. Copy the URL of the page.

Step 1: Generate a hyperlink to the new page from the CMS Links page. Copy paste the URL on the Href field, enter the mandatory data and Save. Manage the Cache.

Step 2: Configure the link on CMS Menu page. Select the location of the link from Menu drop-down. Drag and drop the generated link from the Available links section to the Menu links. Click Save.

The hyperlink to the Subscriber Update page will be visible at the configured location on the SS page where you have set it up.

6. Access - Message when there is no URL in DigitalAccess response

Based on some recent developments, it is not necessary for NewspaperEntitlementSettings table to have a redirect URL anymore. In such cases, the EntitlementsAPI could return a blank ReturnURL in the Output model. If this occurs, the Access page will be restricted from redirecting. In this scenario, the user will be displayed with a proper error notification message informing about the missing configuration. This error notification message is configurable from CMS (Error Code: SS_Access_04).

Implementation Notes:

The newly introduced Error Code SS_Access_04 can be customized from CMS.

1. Navigate to: Admin > Notification New > Notification New Mngmnt > Manage Error Codes > Add New Error Code.

2. Enter Code (SA_Access_04), Description and Click Save.

7. Map subscriptions with multiple registration to CMS restriction MultipleRegistrations

The CMS restriction, previously known as ‘CorporateSubscription,' has been renamed to 'MultipleRegistrations’ from this release. This restriction has been mapped in SubConSite accordingly. When any SS link is configured with CMS restriction ‘MultipleRegistrations’ in Hide links, the corresponding link will not be displayed in the SS UI, if the Subscription.RegistrationCount is not null and Subscription.RegistrationCount > 0 for the selected subscription.

7.1. Rename CorporateSubscription restriction as MultipleRegistrations

CMS > Navigation > Links (Choose a valid link)> Hide Link For > 'Multiple Registrations' restriction can be added

The CMS restriction 'Corporate Subscription' has been renamed 'Multiple Registrations' to better convey the purpose of the restriction. The restriction can be added in the "Hide Link For" field to prevent the link from being displayed if the registration count for the selected subscription is not null and is greater than 0.

Implementation Notes:

Open CMS, Select Navigation > Links section, then select a link from the drop-down menu. Multiple Registrations will be available in the Hide Link For.

8. Bigger PDF icon on Invoices page

The PDF icon on the /ebill/invoices page, used to download a user's OSG bill statement, was relatively smaller and had a very faint color. It has now been resized to a larger size to enhance visibility on the Invoice page.

9. Single Sign out functionality for clients using their own IDP

Starting from this release, it is now possible for the clients who have their own IDP to seamlessly logout users from all the sites where they were logged in, if they are logged out from the Self-Service portal.

When a logged-in user on both the website and SubCon Site logs out from the website, the user should not be logged out from the SubCon Site. However, in some instances of Firefox, the user gets logged out from the SubCon Site if they log out from the website, which is not the expected behavior.

Implementation Notes:

A new MG2Control Api setting Auth0.App.LogOutFromIDP has been introduced with the default value 0 (false). The value of this setting should be 1 (true) only for clients those who have their own IDP.

10. StopSaver - Bypassing TempStop step

Starting from this release, a digital subscriber entering StopSaver page will never see Temp Stop step. If something fails on Temp Stop step load routine for a digital subscriber, StopSaver workflow will just move to the next step to continue the workflow. The Temp Stop page will be bypassed. Before this enhancement, if the end user faced any issues in Temp Stop step, the whole page was failing out and was redirecting the user to the Dashboard page.

11. Supporting Classic and New Universal Auth0 login

The Identity provider Auth0 has introduced a new Universal login experience for its clients. Starting from this version, Subscribe supports both Classic and new Universal login of Auth0 through the Self-Service portal. However, there will be no visual changes for the user.

When a user hits the ‘Login’ button, Self-Service portal will direct the user to Sign-in page. Similarly, clicking the 'Register' button will still direct the user to the Sign-up page, as before. For those interested in learning more about the advantages of this new login experience, you may find additional information here:

Universal Login Experience (auth0.com)

One-CSR Portal

1. Enhancements in the Payment flows

The One-CSR Portal application has started using new endpoints in Payments API from this release for various payment flows such as One-time flows, Restarts and EZPay sign-ups. The grid for Rate details at the time of payment in all the flows will be as follows and consistent across all circulations irrespective of the payment method chosen (Bank payment or through credit card):

1. Term (e.g. 1 Month)

2. Rate

3. Other Cost

4. Tax

5. Amount

One-time flows:

Starting from this release One-CSR Portal application of NCS, Matrix, and CircPro clients will start using the new endpoint POST /api/Payment in the new Payment API for the successful completion of one-time payment flows. The Total amount calculation for one-time payment flow has been refactored, simplified, and centralized at Micro API level for all circulation systems. From this release, while submitting the payment request, Total amount will be (Amount + Tip + Donation + Activation fee (only for NCS)). This includes both credit card payment and payment through bank. However, payment through bank is not applicable for Matrix & CircPro circulation systems as of now.

• Tip is applicable only for NCS and CircPro clients. The MG2 control app setting key StartCallPaymentBillingTabTip can hide and display the Tip amount field.

• Donation is applicable only for NCS clients. The MG2 control app setting key StartCallPaymentBillingTabDonation can hide and display the Donation amount field.

• The Activation fee is only applicable for NCS clients and is configurable using two MG2 control keys StartCallPaymentBillingTabActivationFeeACH and StartCallPaymentBillingTabActivationFeeCC for payment through bank and payment through credit card respectively.

• The Amount displayed in the Subscription financial transactions grid after payment is the amount without including Activation fee.

Restart flow:

Starting from this release, One-CSR Portal application will start using the new endpoint POST api/RestartPayment in the Payment API for restarting a stopped subscription. While submitting payment request during Restart flow, a new API key Restart.ApplyCreditBalance will be considered in the TotalAmount calculation logic as follows:

• If the setting is turned on and the subscription has a Credit balance (positive amount), that balance will be deducted from the TotalAmount.

• If the setting is turned off, the Credit balance will not be considered in TotalAmount calculation.

• Regardless of the value in the setting key Restart.ApplyCreditBalance, if the customer has a negative balance (i.e if they need to pay the company), the balance amount will be considered for TotalAmount calculation. The balance will be added to the TotalAmount to be paid.

• Activation Fee will not be part of the calculation of TotalAmount from SA.

This Restart payment flow is applicable to both NCS and Matrix clients. However, for Matrix clients, Subscribe only supports Credit Card payment.

EZPay Sign up:

Starting from this release, One-CSR Portal application will start using the new endpoint POST api/EzPaySignUp in the Payment API for creating a new payment method for a Subscriber. Earlier, the microAPI used to handle both one-time payment & EZPay sign up in a single request. Starting from this release, One-CSR Portal will manage the requests and not the microAPI.

• If the customer has negative balance (customer owes money to the publisher), then the One-CSR Portal will call One-Time Payment endpoint first and then the EZPay sign up endpoint. The EZPay sign up endpoint will be called only if the One-time Payment endpoint returns a success. In case it returns a failure, message from the API will be displayed. When both end points return a success, existing success message will be displayed to the user, if any. Otherwise, the error from microAPI will be displayed.

• If the customer has positive balance, then the One-CSR Portal will directly call EZPay endpoint.

• The transaction including One-time payment and EZPay Sign up will be a single submit like the existing functionality.

The Subscribe integration with payment vendors Stripe and PayWay do not support Diners Club credit card for any of the payment flows.

Implementation Notes:

• The value of MG2 Control App keys StartCallPaymentBillingTabTip and StartCallPaymentBillingTabDonation determine the display of the Tip amount and Donation amount fields.

• The MG2 Control API setting key Restart.ApplyCreditBalance handles the positive balance (whether the subscription's positive balance (credit) is deducted from the TotalAmount or not) in Restart flow. The client can be enabled and disabled from the Support Viewer.

2. Placement change of Access and Settings sections on Entitlement details page

Starting with this release, the Access section, providing information about Access levels and Household levels, will be placed at the top of the Settings section on the Entitlement details page within One-CSR Portal (Client Management > Entitlements > Entitlement details > Select any Newspaper > Search > Edit button on any Entitlement search result).

Apart from placement change on UI, there is no change in the functionality of these features.

3. Nonmandatory Settings section on the Entitlements page

The Settings section on the Entitlements page has been made non-mandatory from this release while adding a new Entitlement. After creating a new Entitlement (Client Management > Entitlements > Entitlements button > Search > Add new Entitlement), select the Entitlement details tab and click Search button to list the newly created Entitlement. Click the Add button along the new entitlement record in the Search result grid. The Entitlement details page of the selected entitlement will be displayed. On the Entitlement details page, Access section and Settings section are displayed. From this release, only Access section will be mandatory for saving the new entitlement with Access level and Household level details. Settings section has become non-mandatory.

4. Subscription end date in the Account information Tab

The Subscription end date will be displayed for all subscriptions irrespective of the subscription status in the Account information tab of the One-CSR Portal from this release. Earlier this field and data was displayed only for stopped subscriptions.

5. Registration Search via Company name

It is now possible to search user registrations directly for a specific company using ‘Company name’ from this release. A new search field ‘Company name’ has been added in the search screen of User accounts in One-CSR Portal. (One-CSR Portal > User accounts > Search).

Based on the entered search criteria, the search results will be fetched from the database & displayed in the search result grid. The company name will be checked in the metadata property of registrations.

The display of the search field ‘Company name’ and the column ‘Company name’ is decided by the value of the existing MG2 Control key that is otherwise used to enable Company name search criteria on the Subscription search screen. If the key value is set to 1, the Company name search field and the Company name column in the search result grid will be displayed. If the key value is 0, the search field and the column will not be displayed in the search result grid.

The Company name field is not a mandatory search criterion. If data is entered in any of the other displayed search fields, the search results will be displayed based on the full/partial match of the search criteria considering all entered parameters.

Implementation Notes:

When the value of the key SubscriberSearchCompanyNameOption is set to 1, then the Company name search field and the corresponding column in the search result grid will be displayed, or else it will not be displayed.

6. Removal of Auto renew signup option from One-time payment flow

The ‘Auto renew sign up’ checkbox option will no longer be available for one-time payment flows from this release. When a user clicks on the button ‘Make a payment’ button, the ‘Auto renew signup’ checkbox will not be displayed to the user anymore. The user will be able to enter the rest of the payment details and continue with the payment successfully.

If a CSR wants to sign up the subscriber for auto-renew, they can use the regular EZPAY Sign Up option instead of this checkbox that was previously available under one-time payments.

7. Users accounts Search page: Requires at least one parameter

Until 3.16.3 version, when a CSR/user clicks the Search button on Users Search page (User accounts > Search) without entering any search parameter (Login name, First name, or Last name), system used to list all users from Subscribe database. However, with the recent API refactoring and in view of performance optimization, the Users Search page will now require at least one search parameter to perform the search function successfully. The search results will be based on the search criteria input.

If the Search button is clicked without any input parameter, an error message will be displayed - “Please enter a value in at least one of the input fields.”.

If there is no data to return as per the provided the search criteria, then an information message will be displayed to the user - “Sorry! No data found for the entered search criteria.”

8. Capturing Newspaper from User while updating registration details

From this release, while updating any registration, the CSR or One-CSR Portal user will be provided with a mandatory drop-down to select a Newspaper publication while updating the Profile settings of a user (User accounts > Search Grid > Registration button > Profile settings tab) regardless of subscription. The list in the new drop-down will be identical to what is already available in the Subscription Search screen.

Based on the user selection of Newspaper, the registration update request will be accepted and the Papercode of the selected Newspaper will be submitted to the User update endpoint. On clicking the Submit button, the user will be displayed with a notification message “Registration profile has been updated successfully”.

While updating the user profile, if the Newspaper is not selected in the drop-down, the user will be notified with an error message “Newspaper field is required”.

9. Relevant message to user when they are not part of Sales team in Add New Account Start Call Flow

When a user attempts to create a new subscription from One-CSR Portal by selecting a publication for which they are not part of the Sales team in SolCon, they are prevented from proceeding. However, the application previously did not provide any information about the issue or how to proceed. Starting from this release, such users will receive a relevant message explaining the issue and providing guidance on how to resolve it.

10. Relevant error notifications while adding a new account

When a Customer Service Representative (CSR) attempts to add an account and start a new call from One-CSR Portal, a generic message is currently displayed - 'Sorry, there are no offers available for the selected zip code.' This message is shown regardless of the actual issue with the zip code, which can be due to the following reasons:

1. No Active Offers

2. Missing Zip Code (Print Offers)

3. Past-dated Offer Validity in Offer Group → Additional Options → Validity.

To address this, starting from this release, a more informative message will be displayed to help the CSR understand the cause of the issue and avoid any confusion. The new message will be:

"Sorry, there are no offers available. Please ensure you have active offers set up in SolCon with appropriate Available Areas (if applicable) and the Offer Validity under Offer Groups → Additional Options is not past-dated."

11. Configurable Search format for Postal Code

To support different countries' addresses, the Postal/Zipcode field in the Subscription search within SubCon Admin now allows the entry of postal / zip codes in desired format. A new MG2Control key, "PostalCodeMask", has been introduced to define the format. By default, the Zipcode field accepts 5 numeric digits, and the subscription search works with these values. The Zipcode masking can be configured at the client level using the MG2Control key. Below are some examples of masking formats:

• AA99 = 2 alphabets followed by 2 digits

• AAAA = 4 alphabets, no digits

• 9999 = 4 digits, no alphabets

• ***** = any 5 characters

• ** *** = any 2 characters, a space & then 3 characters

Note: If spaces are needed in the Postal Code like in the last example above, an additional masking in SA config must be requested to Naviga team for the search to work correctly.

Implementation Notes:

A new MG2 control key PostalCodeMask has been introduced to handle the postal code masking client-wise, with the default value of 5 numeric characters.

---

Solicitor Concierge (SolCon)

1. New API endpoints to fetch live Rate codes & Billing System Code section data population

Implemented new API endpoints (GET /DirectIntegration/Rates & GET /DirectIntegration/Rates/{externalId}) to fetch live Rate codes and corresponding Rate code details from the microAPI endpoint DirectIntegration/RateCodes that can be used for both NCS and CircPro circulation systems.

Offer Groups > New Offer Group > Coding > Billing system code > Subrate

For CircPro clients, when the Subrate value is selected, the remaining necessary fields in the Billing System Codes section for the Offer will be automatically filled with the relevant data. This data population is made possible with the help of the DirectIntegration API. The fields ‘Pay Types’ and ‘Delivery Type’ will be static drop-downs.

Implementation Notes:

To display the drop-down in SolCon, the MG2 Control App setting, SLOfferGroupsCoddingBillingCodesdropdown, should be set to 1.

2. Reason Code drop-down for Comp Offers independent of Rate Code

From this release, while editing an Offer group for Complimentary subscriptions, Reason codes for an Offer group will not be based on the value of Rate codes. The values in the Reason Code drop-down will be fetched from NCS via API. The Rate Code field remains disabled.

Note: For other subscription kinds, the values in the Reason Code field are populated as per the selection in the Rate Code field.

3. Allowed Registrations field as per Subscriptions.MaxLinks value

The Allowed registrations field in SolCon Additional Options will now consider the value defined in Subscriptions.MaxLinks setting. Starting from this release, the user will not be able to enter a number greater in the field than the defined limit in the setting key.

If the user enters a value greater than the Subscription.MaxLinks setting, a message will be displayed: “Enter a value less than the maximum limit i.e. <Max>” where <Max> represents the defined value in the Subscription.MaxLinks setting.

Implementation Notes:

The MG2 Control key Subscription.MaxLinks defines the max value of possible Registrations clients can set against any Subscription.

4. Move the field "Requires SheerID Validation" under Subscription Kind section

The checkbox "Requires SheerID Validation" which was previously a part of Subscription Validation section has been moved to Subscription Kind section on UI. There is no change in business logic other than UI placement. Subscription Validation section was not a relevant section for the field ‘Requires SheerID Validation’ as the field is not linked to active sub-check in anyways. Hence, the field has been moved to "Subscription Kind" section. This is a configurable checkbox with the MG2 Control App settings key “OfferGroupAdditionalOptionSheerIdValidationFlag”.

Implementation Notes:

The checkbox ‘Requires SheerID Validation’ will be visible under Subscription kind section only if the value of MG2 Control App settings key value is 1.

---

Subscription Panel

1. Seamless Flow updated for Payment Method Selector

The payment checkout page interface of the seamless flow has been updated to display all available payment methods as defined in the PaymentMethodSelector Style property in the CMS such as radio button, drop-down, etc.

Implementation Notes:

The user can configure the PaymentMethodSelector Style property by going to:

CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > PaymentMethodsV3

2. Added Holder Name hosted field for Braintree

The CardHolderName (first and last names) has now been added as a hosted field (as part of the Braintree iframe) in the Subscription Panel user interface.

Note: The CardHolderName field will be displayed on the Subscription Panel page even if the CardHolderName show button has been turned off in the CMS presentation.

3. Password Validation

When purchasing a new subscription, a password validation error was displayed even when the same value was entered in both the Password and Confirm Password fields. In addition, the displayed password validation error had hard-to-read background and text colors.

Changes have been made to not display an error when correct values have been entered in the password fields, and if a validation error occurs, the message will be displayed in valid background and font colors.

4. Subscription Confirmation page now displays the latest Instagram logo

The Subscription Confirmation page in the Subscription Panel has now been modified to display the latest Instagram logo.

5. Expose Auth0 id in the set customer registration ID event

Through the Subscription Panel, the CRID (Customer Registration ID) was available to event triggers only after the user completed the User Information step. This prevented GTM/Fingerprint trackers from registering the CRID/Auth0 ID if the GTM scripts had already executed, as the Auth0 ID depended on the completion of User Information step. To address this, a new event is now triggered from the SP side once the customer registration ID is set in the application. Starting from this release, SP exposes the CRID (Auth0 ID) in the set_customer_registration_id event specifically for GTM trackers. With this enhancement, when the email ID is available in the SP header component or as soon as a user enters their email in the Email field of the User Information component, the set_customer_registration_id event is triggered. This event includes the Auth0 ID, which can be captured by GTM scripts for further analytics processing.

---

CMS

1. Removed the Base64 encoding format Attribute Type in CMS

In CMS, when adding or editing any Attribute, the Base64String option will no longer be available in the Attribute Type drop-down menu. In addition, the existing Attributes and CMS Settings in the database with the Base64String Type have been updated to the Character Type.

2. CMS Notification

CMS > Notification New > Notifications New Management > Manage Error codes

When creating, modifying, or deleting an error code record, the Notifications New Management page now displays relevant messages.

1. When an error code is created, a success message stating "Error code successfully added" is displayed.

2. When an error code is modified, a success message stating "Error code successfully updated" is displayed.

3. When an error code is erased, a success message stating "Error code successfully deleted" is displayed.

4. In addition, when a user attempts to save an error code after making no change to it, a warning message stating "Warning! No changes detected" is displayed.

3. Renamed the VideoLink Label in Benefits to YouTube VideoLink

The VideoLink field on the Benefits page has been renamed to YouTube VideoLink. A validation check has been implemented so that users can now only save a YouTube link in the field when adding a Benefit.

---

API

1. API - Entitlements

Previously, the Entitlements API needed records to be available in the NewspaperEntitlementSettings table in order to calculate the URL that has to be provided in the DigitalAccess endpoint, which was used by the Self-Service Portal's Access page for the redirect. This has now caused an issue since the Access Page is no longer being used, and clients are being forced to set up dummy data in the NewspaperEntitlementSettings table in order for the API to function properly.

Changes have been made to remove the validation checks to force NewspaperEntitlementSettings for entitlements that are used externally and do not require a redirect url provided by the API.

When generating Entitlements using the Entitlements API (POST /Entitlements), all dependency on the NewspaperEntitlementSettings table has been removed. If the EntilementCode has no association with any NewspaperEntitlementSettings when creating a digital access (POST /DigitalAccess), the steps to generate the URL will now be skipped.

2. API - Offers

The Offers API now includes a new endpoint, GET /CheckZipDeliverable, that validates the availability of a ZipCode in the Offer Delivery Area based on the input parameters ZipCode and OfferId.

3. API - Billing

1. Previously, a subscriber with multiple subscriptions was unable to change the auto-renew information of a subscription after one of the other subscriptions had been updated and received the error message "Payment method was modified recently. Please wait 24 hours or call our Customer Support team." This error occurred because the payment validation check for the past 24 hours was based on the Subscriber ID.

   Changes have been made such that the validation check for payments made in the past 24 hours will now be based on the subscription rather than the subscriber. A subscriber who has multiple subscriptions can now update them one after the other without having to wait the 24-hour interval; however, payments towards a single subscription can only be made once per day.

2. When entering new payment information, the masked Credit Card details received in the CreatePaymentMethod endpoint will now be stored in the subsvc database under the PaymentMethod table.

4. API - MailingOrchestrator

1. A new orchestration API, MailingOrchestrator, has been developed to handle the workflow orchestration between the external services and Subscribe Emails API.

2. The Post /Emails endpoint sends the email related to an event based on the provided input parameters EventId (a unique identifier of the event in the SubCon database) and Email (optional; if provided, it will replace the destination email specified in the provided event).

Note: Currently, consumer applications are not using this new API.

5. API - Auth0

1. A new API, Auth0, has been developed to handle the integration between the Auth0 and Subscribe.

2. The POST /Users/Authentication endpoint validates an access token based on the input parameter, Token (access token generated in the consumer application).

3. The GET /Users endpoint has been developed to receive a paginated list of all users registered in Auth0. Input parameters:

   • Email: Optional; Email address of the user.

   • InternalId: Optional; Internal custom ID of the user.

   • PageSize: Optional; Maximum number of items returned per request. Default value 10.

   • PageNumber: Optional; Requested page number of pagination. Default value 1.

4. The GET /Users/{Id} has been developed to retrieve the details of a user registered in Auth0 based on the provided ID (a unique identifier for the user in Auth0).

5. The POST /Users endpoint creates a user in Auth0 based on the below input parameters.

   1. Email: Email address of the user.

   2. Password: User’s password.

   3. FirstName: Optional; User’s first name.

   4. LastName: Optional; User’s last name.

   5. PhoneNumber: Optional; User’s phone number.

   6. UserName: Optional; User’s user name.

   7. NickName: Optional; User’s nick name.

   8. Picture: Optional; User’s picture. It needs to be a valid public URL and will be validated on the Auth0 side.

   9. InternalId: Optional; Internal custom ID of the user.

6. The PUT /Users/{Id} endpoint updates a user in Auth0 based on the provided ID (a unique identifier for the user in Auth0) along with the input parameters mentioned in the POST /Users endpoint.

7. The POST /Ticket/Password endpoint creates a URL for the user to change their password in Auth0 based on the provided UserID (a unique identifier for the user in Auth0).

Implementation Notes:

• The new API is set up under $/MG2CEP/Main/SubscribeAPI/LowLevel/Integration/Auth0/Dev.

• This new API will replace the current Auth0 MicroAPI starting with 3.17.0. As a consequence, the builds and releases for Dev and BetaRelease 3.17.0 have the new structure.

5.1 API - Auth0 - Tokens cache enhancements

Subscribe previously generated a new token for each Management API call since Auth0 required a token for interacting with the Management API. To prevent having to generate a token for each API call, a token cache has been introduced, in which Subscribe stores the token generated with an expiration date. The MG2 control internal setting, Auth0.MaxTokenExpirationSeconds, was used for determining the expiration date. An issue occurred when the value specified in the MG2 Control setting was longer than the expiration date of the token in Auth0, and the token cache had to be cleaned.

Changes have now been made to get the expiry date from the token rather than depending on the MG2 Control setting, so that the Auth0 API can store the access token to prevent further calls to the external API. In addition, when the token expires, it will be removed from the cache and a new token will be generated.

Note: The MG2 control internal setting, Auth0.MaxTokenExpirationSeconds, will no longer be used for determining the expiration date.

Implementation Notes:

The MG2 control internal setting, Auth0.MaxTokenExpirationSeconds, will no longer be used for determining the expiration date.

6. API - Purchase

• In the Newstart flow, the logic for the Phone has been updated such that:

  • If an existing Circ subscriber does not have a phone and no phone information has been specified in the Subscription Panel, the API makes no changes.

  • If an existing subscriber in Circ has phones but the phone in Subsvc is null, the API updates the phone in Subscribe DB.

  • If an existing subscriber in Circ does have a phone and the phone information specified in the Subscription Panel is already on that list, the API makes no changes.

  • If an existing subscriber in Circ does not have any phones but phone information has been provided in the Subscription Panel, the API updates the occupant in NCS to save it as a Primary Phone.

  • If the subscriber in Circ has phones but the phone information provided in the Subscription Panel is not on that list, the API updates the Occupant in NCS to save the collected phone information as the Primary Phone and the existing phone as the Other Phone.

• Previously, when creating a Newstart, columns such as the SubscriptionKindId, PaymentMethodType, or CC_type in the AUTHCC event were not being populated, making it difficult to troubleshoot when an issue occurs. When creating Newstarts, changes have now been made to collect and store all of the information received in the AUTHCC event.

7. API - Address

Because Comp subscriptions are not billable, the Subscribe API will now include the subscription's BillingMethod along with the RateCode when sending the request to the NCS in the AddMove (addmovetrandelschedchg) endpoint when creating Moves for Comp subscriptions with the MG2 control flow setting "Flow.AddressMove" set to RealTime.

Implementation Notes:

The MG2 control flow setting "Flow.AddressMove" has to be set to RealTime.

8. API - DTI

Currently, when requests have been sent to NCS from both Naviga Consumer Apps and External Consumer Apps, the user will be retrieved from the value defined in the MG2 Control Setting, DTI.CircAPIUserId.

To differentiate between requests received from Naviga Consumer Apps and requests received from External Consumer Apps in the NCS, an internal setting in the MG2 DB can be created by concatenating the Source System from which the request has been sent with the MG2 Control Setting, DTI.CircAPIUserId.

For example, if a client's Source System is ClientWebSite, an MG2 Control Internal Setting "ClientWebSite.DTI.CircAPIUserId" can be created, and if a value of "ClientWebSiteUser" has been set to it, the user value will be displayed as ClientWebSiteUser in the NCS when sending requests through this Source System.

Implementation Notes:

If a particular source system needs a different value when sending a request to NCS, it can be set up now.

9. API - Subscriptions

New Address fields for Australia

Previously, when standardizing an Australian address through the MelissaData API, it returned the parameters "Level Designator" and "Level Number" (as SubPremiseLevelType and SubPremiseLevelNumber, respectively), but SubscribeAPI was not mapping them.

Changes have now been made to the Purchase and Change Address flows such that the LevelDesignatorID and LevelNumber will now be provided when calling the NCS CircAPI, "Add Address/Occupant (addaddrocc)" for Australian addresses.

In addition, two columns, LevelDesignator and LevelNumber, have been added to the Address table in the subsvc database, which will be populated with the data received from the standardization.

Implementation Notes:

This functionality is only applicable when the MG2 control flow setting, MelissaDataIntegration, has been set to "GlobalOnPremise” or “GlobalCheckAPI”.

Prerequisites:

Circ System & Minimum Supported Version: NCS Circ, 2020-4.1

Subscribe Extract Minimum Supported Version: Subscribe Extract export version 6

API - Subscriptions - Remove ExpireDate Check to allow Cancel

Starting from this release, the validation that prevents InGrace users with ExpireDate in the past to Cancel their subscriptions, has been removed. Subscribers will be now able to cancel their subscription even if the subscription is in grace period regardless of the expiration date being past/future. Cancelling a subscription will not have any dependency on the expiration date.

---

Bug Fixes

DayPass Flow corrections

DayPass subscriptions are special subscriptions that grant users one-day premium access to Publications. That means, if a user purchases a 'DayPass' subscription today, they can access the premium content until midnight the following day. Currently, only the NCS circulation system supports this type of subscription. In this release, some changes have been made to the DayPass subscription flow. Here are some key points to note:

1. The subscription type (Subscription kind) of DayPass subscriptions in Subscribe will be set as ‘PaidPass’. In NCS, these subscriptions will have their DeliverySchedule designated as ‘DayPass’.

2. Whenever the subscription status becomes ‘Stopped’ for a DayPass subscription, the access to the Publication content will be denied.

3. The HouseHold Level value of DayPass subscriptions will be based on the Status of these subscriptions.

Implementation Notes:

The HHL rule to grant/revoke the access for DayPass subscriptions must be set in the HHL Business Rules.

Self-Service Portal

1. Cancellation reasons unavailable on SS page

The issue of the user being unable to view cancellation reasons in the drop-down while canceling a subscription has been resolved.

2. Logged in users getting redirected to homepage

The issue of logged in users getting redirected to homepage when any changes were made to the URL has been resolved. As a result of the fix, any alterations to the URL will no longer grant logged-in users access to the homepage. Instead, they will be automatically redirected to the Dashboard page.

3. Alignment issues in Dashboard page on iPhone

The alignment for the name, company name, and account number was not correct when compared to the system UI for the Self-Service Portal dashboard page on iPhone. However, this issue has been fixed.

4. Error message after the successful cancellation of the subscription

The user was displayed an error message after the cancellation of the subscription even when the cancellation was successful. This issue has been resolved now. After fixing, the Cancel Subscription workflow no longer displays an error message, even if the event is part of the Stop Saver flow and was successful.

5. Logo overlapping text in the payment receipt

When the user clicked the ‘Print’ button for the payment receipt of a successful restarted subscription, the client logo was overlapping with the ‘My Subscription’ text in the downloaded receipt. This issue was observed both on the laptops and iPhones. After the fix, the overlapping issue is resolved.

6. Multiple opt-in/opt-out instances in eBilling

The user could sign up for eBilling multiple times over and again even when successfully signed up. The same issue occured for sign-out process too. After the fix, when a user signs up for eBilling, they will see 'eBill Manage' link on SS. Conversely, when the user signs out from eBilling, they will then see the 'eBill sign Up' link.

7. User getting logged out from selectaccount page

The issue of user getting logged out from SS selectaccount page on refreshing the page has been resolved.

8. User with Trial subscription able to Restart subscription

Restart workflow is restricted for a stopped Trial subscription. However, in the Account information tab of a stopped trial subscription, ‘Restart’ button was available, and it was also possible to successfully run the Restart workflow for the user from SA. This issue has been resolved now.

9. Discrepancies in the information collected while downgrading or cancelling a subscription using Stopsaver

There were discrepancies in event information and email triggers when downgrading or canceling a subscription using Stopsaver, depending on whether the action was taken from SubCon Admin or SubCon Site.

• Downgrading from SubCon Site: Incorrect email triggered, missing downgrading reason and parent event ID, blank email address in SubCon Admin.

• Downgrading from SubCon Admin: No email triggered, but cancellation reason and event ID recorded, blank email address in SubCon Admin.

• Canceling from SubCon Site: Email triggered, reason and parent ID captured.

• Canceling from SubCon Admin: No email triggered, blank email address, but reason and parent event ID captured.

These issues have now been fixed.

---

One-CSR Portal

User not getting logged out from the Subscribe application without refreshing the page

When the user logs out from any of the sub application of Subscribe (SA, SS, and SolCon), the expected behavior is that they should also be logged out from all the other sub-applications opened on different tabs in the same browser. However, this was not happening. The user was logged out from other sub applications on other tabs only by refreshing the corresponding pages. The issue has been resolved now.

Customer Email trigger Issue for REDEEMGIFT event

Even though Internal and Customer email templates were configured for Gift Redeeming event under the Internal Emails and Customer Emails tabs accordingly, the email configured under the Customer Emails tab was not getting triggered after the successful completion of a gift redeeming flow. This issue has been fixed in this release.

After the fix, whenever a recipient redeems a gift subscription successfully, the congratulatory email configured under the Internal Emails tab and the notification email configured under the Customer Emails tab are sent to the recipient and purchaser accordingly.

Issues with stopped accounts having balances

For accounts with a positive balance (credit), a validation message was displayed, preventing the purchase of a subscription. Conversely, for accounts with a negative balance (outstanding), no validation message was displayed, allowing the purchase of a subscription. These issues have now been resolved.

---

Solicitor Concierge (SolCon)

1. Absence of the Close button in the Inventory module

The problem of lacking a Close button and instead having a Cancel button (along with a pop-up asking the user to Quit/Return to editing) when saving a record in the Inventory module has been addressed. After implementing the solution, users now have access to a Close button after saving in the Inventory module, and they are also automatically redirected to the previous screen.

2. Filter on HHL page

When the ‘Show only active’ filter (a checkbox) was unchecked on the House Hold Levels page under Reference Tables section (Reference Tables > House Hold Levels), the result grid was not showing inactive house hold levels. This issue has been resolved now. With the fix in place, when the ‘Show only active’ filter is checked, then only the active house hold levels will be displayed on the page and if the filter is unchecked, both active and inactive house hold levels will be displayed on the page.

3. Filter on Billing Plans page

When the ‘Show only active’ filter (a checkbox) was unchecked on the Billing Plans page under Reference Tables section (Reference Tables > Billing Plans), the result grid was not showing inactive billing plans. This issue has been resolved now. With the fix in place, when the ‘Show only active’ filter is checked, then only the active billing plans will be displayed on the page and if the filter is unchecked, both active and inactive billing plans will be displayed on the page.

4. Status Filter on Offer Groups page

Previously, the Status filter on the Offer Groups page did not properly filter the Active, Inactive, or Draft offer groups that were chosen for export. This issue has been resolved and the filter now functions correctly. After the fix, when the user clicks the 'Show Selected' button to view the offer groups selected for export and applies the status filter (Active, Inactive, or Draft), the selected offer groups in each category are displayed correctly, if any are present.

5. Offers not getting created under correct Client code on Import

When the user exported Offer groups and imported them to a specific client, the offer groups were created with Marketing text and Terms and Conditions, but no Offers were generated for the client. The created Offer groups were also non-editable. It was also observed that the Offers were being created under the ‘ALL’ category rather than for the selected client. This issue has now been resolved.

6. Issues on Safari browser and Export issue

The following issues that were reported in the Safari browser have been resolved:

• The Sync message was erroneously displayed in front of the ‘Clear cache’ button.

• The welcome message of SolCon was not displayed correctly.

• The Export feature (Admin > Users > Export) was non-functional. Upon clicking the Export button, the progress bar completed, but no file was exported.

7. Error message while updating an offer with ‘Marketing text’ or ‘Marketplaces’

The issue of user receiving error messages in SolCon Admin while updating an existing offer with Marketplaces or Marketing text has been resolved now.

8. Multiple issues observed in SolCon on Safari browser

While using SolCon Admin on Safari browser, the user was encountering below listed issues:

• Unable to enter value in the “Price” section

• Unable to open “Additional Options” section

• Unable to click on “Search” bucket while creating “Sales team” and “Team Member”

All these issues have been resolved. After the resolution, it is now possible to create offer group with valid price and also to search and create sales team and team members.

9. Error notifications on SL pages

The user received error notifications on Offers, Promotions and House Hold Levels pages while clicking on the up or down arrows (for sorting ascending or descending) in the header fields of the displayed grid on those pages. The error messages appeared when sorting was attempted on fields with empty headers. As part of the fix, the ‘Tags’ header field has been added on Offers and Promotions pages and ‘Status’ header has been added on Offers, Promotions and House Hold Levels pages. These fields have been added to the respective tables too. It is now possible to sort the grid records in ascending or descending order using any header fields displayed in the grid.

10. Timeout error while adding offer groups

The issue of getting timeout errors while adding offer groups for a new price point has been resolved. (Teams > Sales Teams > Select any Sales team from the grid >Offer groups). During timeouts the user is notified with proper error messages.

11. Error on Offers page

While clicking the Offer Group ID index column header on the Offers page, the user was displayed with error message saying, ”Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')". This error message was also displayed while clicking on the next or previous page buttons and on page number buttons. The user was restricted from page navigation too. This issue has been resolved now.

---

API

1. APICore

Previously, ApiCore has been updated to include a new feature that ignores the log attribute from the request model, preventing it from adding properties to attributes that are too long, such as Receipts in Webhooks. An issue with this occurred when there were null collections of nested objects in the input model, and an exception was logged in the log files.

This issue has now been resolved; the endpoint responds successfully, and no exceptions will be logged in the log files.

2. API - New Start Errors

When creating Newstarts, if NCS returns two occupants based on the provided email (one that matches exactly and one that matches partially), the whole Newstart process fails with the error message "Child Event: FINDADDRESSOCCUPANT failed. Error: Completed," since it was expecting only one occupant. This issue has now been resolved, and if NCS still returns two occupants, Subscribe will select the email that exactly matches the provided email and process the Newstart normally.

3. API - Restart-related issue

When a user reactivated a subscription through the One-CSR Portal, it created a new account for the user instead of reactivating their existing subscription in CircPro. However, when the user attempted to access the account using the One-CSR Portal, it displayed as inactive and prompted the user to sign up for a new account. This occurred because the inactive CircPro account remained linked to the One-CSR Portal rather than the newly created account. When the client changed the inactive account to active in order to get access to the account, the subscriber now has two active accounts.

This restart event issue in the One-CSR Portal has been resolved, and reactivating a subscription no longer results in the creation of a duplicate account.

4. API - Subscriptions

Previously, the GET /Users/{customerRegistrationId}/Subscriptions/v2 API was returning null responses for subscriptions that were inactive in the RegistrationSubscriptions table. This issue has been resolved and the API will now correctly return inactive records from the RegistrationSubscriptions table.

5. CreateSub API not encoding special characters in the DeliverySchedule parameter

The special characters in the DeliverySchedule parameter of the CreateSub API request URL were not encoded and this was failing the call. This issue has been fixed.

---

CMS

1. Component addition error under PageV3

Previously, saving a presentation after adding the InformationV3 component as a child under PageV3 resulted in the error message "Error! This item must not be here" and "Excess item". This setup issue has now been resolved, and the InformationV3 component can now be added as a child to PageV3.

Implementation Notes:

The user can configure the properties by going to:

CMS > Subscription Panel > Presentation (Choose a valid presentation) > PageV3

2. Logout issues in CMS

Previously, when a user logged out of the Landing Page, they were not automatically logged out of the CMS application.

This problem occurred when, following a successful logout in the landing application, it redirected the users to the login page, but CMS did not receive this message.

This has now been resolved by modifying the functionality logic on the landing page iframe such that when the landing application logs out and the CMS call fails, the iframe passes a message to the CMS application.

3. Incorrect success messages

1. CMS > Slideshow > (Select any Slideshow) > Edit (update the required values) > Submit > Remove Override When overriding a Slideshow , the incorrect success message "Slideshow successfully deleted" was displayed instead of the correct message "Slideshow override successfully removed". This issue has now been fixed.

2. CMS > Rewards > (Select any Reward) > Delete When deleting a Reward, the incorrect success message "Benefit successfully deleted" was displayed instead of the correct message "Reward successfully deleted". This issue has now been fixed.

3. CMS > Content > (Select any Page from the Filter By Page: drop-down menu) > Edit (update the required values) > Save > Remove Override (under Delete column)

   When removing an override of a Content, the incorrect success message "Content successfully deleted" was displayed instead of the correct message "Override successfully removed". This issue has now been fixed.

5. Application Error

When the user left the CMS application idle for a while and then did any operation such as changing the hierarchy or presentation, an error message "Sorry there was an unexpected error.Err:500" was displayed.

This issue has now been resolved, such that if a user loads the CMS and remains idle for more than half an hour before trying to perform any operation, the application now displays a time-out warning message, the entire page reloads, and the user is logged out of the session and redirected to the landing page.

6. Image Upload Error

CMS > Images > Upload > Add files > Actions > Start

When attempting to upload an image file greater than 5MB in size, an invalid error message "Sorry there was an unexpected error.Err:500" was displayed instead of the appropriate message "Maximum request length exceeded. Please upload a smaller file."

This issue has been resolved, and the correct error message will now be displayed.

7. Content Segments

The issue of being unable to save after setting all CMS Content Segments to "Active" has now been resolved.

---

Subscription Panel

User Interface Error

When purchasing a new subscription, when a user chose an offer, entered the email and address fields, and then clicked the continue button, the user interface behaved incorrectly by expanding and collapsing the fields before advancing to the next step. This issue has been resolved, and the user will be able to advance to the next step without the extra animation in the user interface.

Error during eBill Sign-up

During a Newstart from Subscription Panel, the eBill sign-up was failing with an error message stating, 'Could not find any processing command for event type and processor.' This issue has now been resolved.

---

Landing

Password validation issue in the ‘Forgot Password’ workflow

The problem with password validation in the Forgot Password workflow (the flow that is initiated when the user clicks on the link from the email) has been fixed. According to the validations, a subscription application password must be a minimum of 8 characters in length and must include at least one special character and one numeral.

---

Refactor and Maintenance

Self-Service Portal

1. Adding of Resolver steps in SS pages

Resolvers were added to Self-Service Portal pages to fetch the configuration before rendering the page to the user. Starting from this release, in addition to the Get Configurations, more steps have been added in every page to load in resolvers, so as to get information before rendering them. The following is the list of the candidate calls to be done in Resolvers:

• Get Availability (except on the Dashboard page)

  • Complaint

  • Address / AddressUpdate

  • Payment

  • AutoPay Sign Up

  • AutoPay Sign Out / AutoPay Cancel

  • AutoPay Manage

  • Add Tip

  • Ebill Sign Up

  • Ebill Manage

  • Subscription Cancel

  • Subscription Restart

  • Temporary Stop

  • Stop Saver

• Get Reasons/Options/Categories to populate drop-downs in forms

  • Feedback (Get Categories)

  • Stop Saver (Get Reasons)

  • Subscription Cancel (Get Stop Reasons)

• Get the key resource of the page (without that, there is no point in loading the page)

  • Subscription Update (Get Offers)

  • Temporary Stop (Get Stop Dates)

  • Rewards (Get Rewards)

  • Transactions (Get Transactions)

  • Update Subscriber (Get Subscriber)

  • Unsubscribe (Get Allowance)

  • Invitation Confirm (Get Target Invitation)

  • EBill Invoices (Get Invoices)

  • Forgot Password (Get Validity)

2. Unifying components on SS pages

With this release, Circ-specific components have been replaced with a generic and configurable approach for all pages in the Self-Service Portal application. The SS pages on which the components were unified across all circulation systems are:

1. TemporaryStops page - A single page now covers all Circulation systems. Also did the clean up of unused code. Example: the Wizard presentation.

2. AutopayCancel page - Previously this page was associated only to NCS. Now it is applicable for all circ systems. All components are renamed.

3. Transactions page - Previously this page was associated only to NCS. Now it is applicable for all circ systems. All components are renamed.

4. TemporaryStopRestart page - Previously this page was associated only to Saxo. Now it is applicable for all circ systems. All components are renamed.

Code cleaning has been achieved with this development. All the changes are transparent for the user. There is no visual implication.

Implementation Notes:

• The Subcon.Configuration setting "hideRedliveryTable" inside TemporaryStopModule is deprecated.

3. Deprecation of Wizard Presentations

Starting from this release, unused Wizard Presentations have been removed from the Complaints and Address pages of Self-Service Portal application. This change is transparent to the user.

4. Deprecation of Layout property from SS Configuration

The Layout property has been removed from every client’s SS.Config file. However, the Layout module is still in place. The Layout property was initially introduced with the assumption that clients would have two styles (Type A and Type B) of layouts to choose from. However, it was discovered that both layout styles were identical, using exactly the same code. Therefore, regardless of the client’s choice, the site would look the same. Hence, as part of the cleanup task, the layout property has been removed from the config file. There are no changes from the user's perspective.

Implementation Notes:

The layout property is removed from the Subcon.Configuration file since Type A and Type B were using the same code.

5. Angular - Environment enhancements

Originally, the environment.release.ts had client-specific versioning, requiring the team to update the variable throughout the entire file whenever a new branch was created.

A newer approach has now been introduced, unifying the WebApp and WebAPI in the same branch. This means that the WebApp can use the same version as the WebAPI.

The Environments file has been cleaned up to remove anything related to the version. Additionally, it has been ensured that the WebAPI version is displayed in the UI.

6. Upgrade to .NET 6

The SS application has been upgraded to .NET 6. The .NET core is already available on all servers.

7. Deprecate Autofac

Autofac, an open-source dependency injection (DI) container for .NET applications, has been deprecated in the WebAPI of the Self-Service Portal application.

8. Upgrade Braintree SDK

The Braintree-web library and other Braintree scripts have been upgraded from version 3.62.0 to the latest version, 3.100.0. There was a known issue in the Braintree SDK where the Cardholder Name field appeared as a numeric field on iPhones. This issue has been resolved in the newer versions of Braintree. The SDK upgrade has successfully addressed this issue in SS.

---

One-CSR Portal

1. New endpoints for UsersOrchestrator

1.1 GET: User end point implementation

A new User endpoint "api/registrations/GetUserdata" has been implemented to get the user data. One restriction for the GET request is that PaperCode should not be null or NA. Any random code of the client can also be passed. The existing behavior of the user data being from fetched from DB will continue.

Starting from this release, while getting User data, the object will have a property called State. Additionally, the registration State will be displayed in One-CSR Portal Registration lookup as applicable. If the Tenant is using a third-party auth system such as Auth0, Firefly, etc., then the State will always be Standard. If the Tenant uses MG2 Auth, the value of State will be as follows:

• When the Password is blank in the DB, State will be Lite

• When Verified is false in the DB, State will be Unverified

• When Password is not blank and Verified is true, State will be Standard

Implementation Notes:

Created a new MG2 Control App Setting DefaultPaperCodeSA for configuring default paper codes. A default paper code can be set client-wise that will be passed to lookup the users on the user screen, if paper code is not set.

1.2 POST: User end point implementation

For active users on the digital tab, the old user creation endpoint has been replaced with new "api/addUser". The activation flow works as per the existing behavior. The verifyEmail parameter is not being sent in the payload anymore. Hence the user activation (Creation of user) flow is effective for both authentication systems, Auth0 and Mg2Auth.

1.3 PUT: User Email end point implementation

A new User Email endpoint "api/registration/updateUserEmail" has been created to update the email address on the user update registration screen (User accounts > Search > Registration button > Profile settings tab) and Digital tab (Subscription information > Subscription search > Start call > Digital). The new endpoint will replace the old one.

Note: For Mg2groupstripe, email will be updated in DB instantly but for Auth0 clients, email update happens only after Sync.

1.4 PUT: User Password end point implementation

Created one new endpoint "api/registration/updateUserPassword" to update the password and replace the old one. In case of User accounts search screen, "Password" section (User accounts > Search > Registration button > Profile settings tab) will be only visible to clients using Auth0 authentication system.

1.5 PUT: User Customer registration id end point implementation

A new endpoint “api/registration/{CustomerRegistrationId}/CustomerRegistrationId” has been created to update the registration and replace the old one. There is no change to the existing functionality.

If a blank value for CRID is submitted for update, the following message will be displayed: 'Customer Registration ID cannot be blank'. The message will be the same in both screens i.e. via User Accounts & via Start Call Digital tab CRID Update.

Implementation Notes:

The section “Update customer registration ID" section in Subscription Search Screen (Digital Tab) and the field “Customer registration ID” in the User accounts screen (Profile settings tab) will be visible on UI only if the value of the MG2 control setting key StartCallDigitalTabEditCustomerRegistrationId = 1.

2. Replace RegistrationId with CustomerRegistrationId

Starting from this release, RegistrationId has been replaced with CustomerRegistrationId at several instances as follows:

2.1 GET /CampaignMessages

From now on CustomerRegistrationId will be added in the payload of the GET ComaplaintsHistory API request while adding a new delivery error (Subscription search > Start call > Service tab > Add new delivery error > Enter the valid error details > Save) in the place of RegistrationId.

Only the api/messaging/campaignsMessages endpoint was impacted in this replacement. After the replacement, the GET request is functioning as expected.

2.2 User Invitation

Along with the RegistrationID replacement, Phone key under MetaData has also been replaced with PhoneNumber in User Invitation/Registrations.

The Invitation Screen, Insert Invitation, Bulk Invitations, AppendInvitation, Update Invitation, Get PendingInvites, Update Registration, Get Registration, Export Registration, and Import Registration are the different points where User invitation/Registration is employed. There is no impact on the functionality with these replacements.

3. Deprecation of PayBalance flow

Beginning with this release, the PayBalance flow has been deprecated and will no longer be displayed in the One-CSR Portal UI for any scenario. Previously, One-CSR Portal had two separate flows - PayBalance and Restart. The assumption was that the PayBalance button was displayed only if the 'CheckRestartAvailability' endpoint returned false, and if the endpoint returned true, the Restart button was displayed. However, at the backend, both endpoints were calling the same 'Restart' endpoint, and the subscription account was getting restarted regardless of the 'RestartAvailability' response. Hence, the unnecessary PayBalance flow is now deprecated. The Restart option that redirects to SP new start flow is also deprecated.

From now on, the Restart button will be displayed in Account Information Tab only if the endpoint CheckRestartAvailability returns True. Clicking the Restart button will restart the same subscription. Negative & Positive balance are handled as per their expected behavior. If there is a negative balance, its payment is captured during the restart flow. If there is a positive balance, it is adjusted based on the new key Restart.ApplyCreditBalance introduced in 3.17.0.

Implementation Notes:

The Restart button will be available only if the API api/CheckRestartAvailability/subscriptionId returns True.

4. New endpoint to monitor the health of SA

A new endpoint to monitor the health of One-CSR Portal application (whether the application is up and running) has been functional from this release. Status/Ping route is added to One-CSR Portal API that enables the monitoring of One-CSR Portal.

Solicitor Concierge (SolCon)

New endpoint to monitor the health of SL

A new endpoint to monitor the health of SolCon application (whether the application is up and running) has been functional from this release. Status/Ping route is added to SL API that enables the monitoring of SolCon application.

API

1. API - Subscribe Entitlements

1. A new endpoint, Post /Access, has been developed to create access for the User based on the provided EntitlementID, RegistrationId, PlatformType, and UserAgent.

2. A new endpoint, Get /Access, has been developed to return whether the user has access based on the provided EntitlementId and CustomerRegistrationId.

3. A new endpoint, Get /Entitlements, has been developed to return the details of Entitlements based on the provided EntitlementCode.

4. A new endpoint, Get /TemporaryEntitlements, has been developed to return details of a user from the TemporaryEntitlement’s Table based on the provided CustomerRegistrationId.

5. A new endpoint, Post /TemporaryEntitlements, has been developed to create a new record in the Subscribe TemporaryEntitlement’s Table based on the provided user’s details and EventID.

Implementation Notes:

• A MG2 control internal setting: SubscribeEntitlements has been added.

2. API - Entitlements Orchestrator

1. A new orchestration API, EntitlementsOrchestrator, has been developed to handle the workflow orchestration between the external services and Subscribe Entitlements API.

2. The Post /Access endpoint creates Access Log record for the User based on the provided EntitlementCode and CustomerRegistrationId.

3. The Get /Access endpoint returns the current access level (Premium, Upgrade, Purchase) based on the provided EntitlementCode and CustomerRegistrationId.

4. The Post /TemporaryEntitlements endpoint creates a new record in the Subscribe TemporaryEntitlement’s Table based on the provided user’s details and EventID.

Enhancements have been implemented to enable One-CSR Portal to utilize the new set of endpoints mentioned above. Some of the changes in the flow (transparent to the user) are listed below:

• Access page POST an Access request to generate a log entry.

• Activate page should GET a Subscription's access to know which step to display next.

Additionally, some access codes have been hardcoded in the CMS as follows:

• SS_Access_01 = "Access Success"

• SS_Access_02 = "Access No Authorized"

• SS_Access_03 = "Get Access Level has failed"

• SS_Access_04 = "Unable to perform redirection because configuration is missing"

The Access messages against each Access code can be edited in CMS under for each access code.

Implementation Notes:

ProxyAPI needs to have the following settings in place in order to redirect to EntitlementsAPI or to EntitlementsOrchestratorAPI.

• MG2 control internal setting: EntitlementsOrchestrator has been added. This value includes a string.Format that must be used to determine the correct API route. The default value is “{0}/EntitlementsOrchestrator”.

Note: ProxyAPI calls EntitlementsOrchestratorAPI directly, so GatewayAPI is not involved in the request chain.

3. API - Payments

Starting with release 3.17.0, the logic for the following four payment flows has been transitioned from the existing Billing API to a new API known as Payments API:

1. One-time payment

2. Restart

3. Ezpay sign-up

4. Update Ezpay information (previously referred to as 'Change payment')

The Payments API features improved code and maintains the same functionality for these payment flows as previously provided by the Billing API.

1. The POST /Payment, POST /Payment/EzPay, and POST /Payment/Restart endpoints have been modified to add a new input parameter, PaymentOptionAmount, that allows users to provide the payment option amount that is being paid. This will simplify the calculations in the API and provide clarity in consumer applications. In addition, the PaymentOptionAmount value given in the request will be saved in the event log table under the payment_selected_amount column.

2. The POST /Billing/Payments/{subscriptionId}/EzPaySignup endpoint has now been replaced with a new endpoint, POST /Payment/EzPay, to create a payment method for a recurring payment (EZPay) in Circulation Systems (NCS Circ, CircPro, Saxo, and Matrix) and assign it to a subscription in Naviga System based on the below input parameters.

   1. SubscriptionId: Unique identifier of the Subscription in Naviga System.

   2. PaymentMethodId: Unique identifier of the payment method in Naviga System.

   3. PaymentOptionAmount: EZPay Option Amount that will be paid.

   4. Donation.DonationAmount: Donation amount. Not Applicable for CircPro.

   5. Tip.TipAmount: Tip amount.

   6. RenewalTerm: Indicates the term to the Circulation System Provider. Applicable only for Matrix, CircPro, and NCS.

   7. RenewalLength: Indicates the length to the Circulation System Provider. Applicable only for Matrix, CircPro, and NCS.

   Note: Recurring payment (EZPay) through a bank account is not supported for Matrix clients, and any payment method other than credit card will result in a validation error.

3. The PUT /Billing/{subscriptionId}/PaymentMethods endpoint has now been replaced with a new endpoint, PUT /Payment/EzPay, to update the payment method for a recurring payment (EZPay) in Circulation Systems (NCS Circ, CircPro, and Matrix) and assign it to a subscription in Naviga System based on the input parameters SubscriptionId (the unique identifier of the Subscription in Naviga System) and PaymentMethodId (the unique identifier of the payment method in Naviga System).

   Note: Recurring payments through a Bank Account are not supported for Matrix clients, and any payment method other than credit card will result in a validation error.

4. The POST /Billing/Payments/{subscriptionId}/ApplyPayment endpoint has now been replaced with a new endpoint, POST /Payment, to perform a one-time payment in Circulation Systems (NCS Circ, CircPro, and Matrix) based on the below input parameters.

   • SubscriptionId: the unique identifier of the Subscription in Naviga System.

   • PaymentMethodId: the unique identifier of the payment method in Naviga System.

   • DonationAmount: Donation amount. Not applicable for CircPro.

   • TipAmount: Tip amount.

   • TotalAmount: The total amount being paid (PaymentOptionAmount + TipAmount + DonationAmount + ProcessingFeeAmount + ProcessingFeeTaxAmount).

     1. If the PaymentType is Credit Card for NCS clients, an Activation Fee is charged to the TotalAmount. (Total Amount for NCS = PaymentOptionAmount + TipAmount + DonationAmount + ProcessingFeeAmount + ProcessingFeeTaxAmount + ActivationFee)

   • PaymentOptionAmount: The Payment Option Amount being paid.

   • IgnoreFee: Indicate whether the Activation Fee should be ignored. Applicable for NCS clients.

   • TransactionId: Transaction ID created by the Payment Gateway when creating a new Payment Method. Applicable for Matrix clients.

   • ProcessingFeeAmount: The Fee amount being paid. Applicable for NCS clients.

   • ProcessingFeeTaxAmount: The Fee tax amount being paid. Applicable for NCS clients.

   Note:

   • The Activation Fee is only applicable to NCS clients, and the amount can be defined in MG2Control setting DTI.ActivationFeeAmount (applicable if IgnoreFee is set to false). Currently, this is taken into consideration in the TotalAmount validation only for the NCS clients.

   • Payments through a Bank Account are not supported for CircPro and Matrix clients, and any payment method other than Credit Card will result in a validation error.

5. The POST /Billing/Payments/{subscriptionId}/RestartPayment endpoint has now been replaced with a new endpoint, POST /Payment/Restart, to restart a stopped subscription in Circulation Systems (NCS Circ and Matrix) based on the below input parameters.

   • SubscriptionId: the unique identifier of the Subscription in Naviga System.

   • PaymentMethodId: the unique identifier of the payment method in Naviga System.

   • Donation.DonationAmount: Donation amount.

   • Tip.TipAmount: Tip amount.

   • TotalAmount: The total amount being paid (PaymentOptionAmount + TipAmount + DonationAmount + ProcessingFeeAmount + ProcessingFeeTaxAmount - Subscription’s Balance).

   • PaymentOptionAmount: The Restart Option Amount being paid.

   • TransactionId: the Transaction ID generated by the payment gateway when a new Payment Method is created. Applicable only for Matrix.

   • RenewalTerm: Indicates the Circulation System Provider's renewal term. Applicable for CircPro and NCS.

   • RenewalLength: Indicates the Circulation System Provider's renewal length. Applicable for CircPro and NCS.

   • RestartDate: Indicates the Subscription’s Restart Date. Currently, this is applicable for CircPro and Matrix.

   • CreateRestartEvent: Indicates whether to create the RESTART event. For Saxo, CreateRestartEvent can be set to False if the client chooses to restart payment without restarting the subscription. Otherwise, this is optional.

   • ProcessingFeeAmount: Fee amount being paid. Currently, this is applicable only to NCS.

   • ProcessingFeeTaxAmount: Fee tax amount being paid. Currently, this is applicable only to NCS.

   Implementation Notes:

   For NCS Circ clients, two new MG2 control internal settings have been added to set the values for the SourceCode and the ReasonCode:

   1. Restart.DTI.ReasonCode

   2. Restart.DTI.SourceCode

   Depending on the client, the values for the above-mentioned internal settings will change. If the client does not specify a value for these settings in the MG2 control, the default values that have been given below will be sent to the NCS Circ system.

   • The default value for "Restart.DTI.ReasonCode" will be "payment".

   • The default value for "Restart.DTI.SourceCode" will be "MG2".

6. The following new endpoints have been created to enable One-CSR Portal application to consume the new Payments API and some of the Billing API endpoints. Note: The new One-CSR Portal endpoints are written in bold below.

   • Endpoint for performing a one-time payment: If Restart, Post API/ApplyPayment (Old) → Post api/RestartPayment => /Payment/Restart (MicroAPI) If not Restart, Post API/ApplyPayment (Old) → Post api/Payment => /Payment (MicroAPI)

   • Endpoint for updating a payment method in Circulation Systems: api/StartCall/updatePaymentMethod/{subscriptionId} -> Put api/updatePaymentMethod => /Payment/EzPay (Update EzPay Info MicroAPI)

   • Endpoint for creating a new payment method for a Subscriber: api/CreatePaymentMethod → Post api/PaymentMethod => Billing/PaymentMethods

   • Endpoint for getting a payment method from Naviga Subsvc database: api/getPaymentMethods/{subscriberId} → Get api/getPaymentMethod => /Billing/PaymentMethods/{paymentMethodId} (MicroAPI)

   • Endpoint for managing the addition of Tip amount (one-time or recurring) to the Subscription amount: Post AddTip =>POST /api/AddTipPayment

   • The Subscribe's PayWay, Stripe, and AuthorizeNet integrations do not support Diners Club credit card. These new endpoints have been incorporated for NCS, DSI, Matrix and CircPro clients from this release.

7. The endpoints of new Payments API in 3.17.0 fully replace some of the endpoints previously hosted in Billing API. Additionally, some improvements were made to the Payment Methods management within the Billing API, which involved creating new endpoints. These changes have been integrated into the SS consumer application. However, there is no change in the user experience.

   EzPay SignUp flow consumes the new PaymentsAPI endpoint (all circ systems), but nothing changes in the user experience. SS has been switched to use the new Create Payment method created in the new PaymentsAPI. There is no visual impact for the existing flow.

   • Activation fee is applicable only for NCS clients if it is configured in MG2 Control for the specific client.

   • Payment through bank is not supported for CircPro and Matrix clients.

   • NCS clients accept recurring Tips whereas SaxoCirc (DSI) clients accept both recurring Tips and Donations. CircPro and Matrix clients accept neither Tips nor Donations.

   Implementation Notes:

   1. Subcon.Configuration

      • In the Payment and Restart pages, there is an optional section called PaymentOptionsSection that specifies which columns should be displayed in the payment options grid. By default, it will only show 'Term' and 'Amount'. Example: "PaymentOptionsSection":{

          "DisplayTerm": true
          "DisplayRate": false
          "DisplayTax":false
          "DisplayOtherCosts": false
          "DisplayDate": false
          "DisplayAmount": true
          "DisplayIsAutoRenew":false
        }

      • The RestartInfoSummary section is deprecated (inside Restart module)

      • The ActivationFeeSection is deprecated (inside BankAccountSection and CreditCardSection from every BillingWidgetSection, present in payment-related pages)

   2. CMS

      • New CMS contents have been introduced for each page that has a payment options grid. PaymentOptionsHeader.Term PaymentOptionsHeader.Rate PaymentOptionsHeader.Tax PaymentOptionsHeader.Amount PaymentOptionsHeader.Date PaymentOptionsHeader.OtherCosts PaymentOptionsHeader.IsAutoRenew PaymentOptions.NoPaymentOptionsText

      • For Autopay options grid

        • AutoPaySignUpHeader.Amount AutoPaySignUpHeader.Term

        • For DSI there’s a new checkbox with this content

          • ShouldRestartSubscription

8. The POST /Billing/Payments/{subscriptionId}/AddTip endpoint has now been replaced with a new endpoint, POST /Payment/Tip, to handle the one-time and recurring payment transactions to add tips.

   A new MG2 control internal setting, Payments.MaximumTipAmountAllowed, has been introduced for setting the maximum amount allowed for tip payment.

   Implementation Notes:

   A new MG2 control internal setting, Payments.MaximumTipAmountAllowed, has been introduced for setting the maximum amount allowed for tip payment.

9. Previously, when restarting a permanently stopped subscription in NCS Circ, the restart flow triggered an ADDSUBSCRIPTION event to restart the Subscription. In other Circ systems, such as Matrix and CircPro, the RESTARTSUBSCRIPTION event is used rather than the ADDSUBSCRIPTION event.

   In order to standardize across all Circ systems, restarting a stopped subscription will now create a RESTARTSUBSCRIPTION event in NCS client databases rather than an ADDSUBSCRIPTION event.

   Note: The RESTARTSUBSCRIPTION event will trigger the same request that the ADDSUBSCRIPTION event did previously in the NCS CircAPI, CreateSubscription.

   Implementation Notes:

   Now, the RESTARTSUBSCRIPTION event is processed with exactly the same configuration as ADDSUBSCRIPTION.

10. Validation checks have been implemented for all the payment-related operation flows to ensure that only payment method types acceptable to the particular circ system will be allowed for each transaction.

    1. Single Payments:

       • NCS Circ: Transactions have been allowed through both a bank account and a credit card.

       • Saxo Circ: Transactions have been allowed through both a bank account and a credit card.

       • CircPro: Transactions can only be made with a credit card.

       • Matrix: Transactions can only be made with a credit card.

    2. EZPay:

       • NCS Circ: Transactions have been allowed through both a bank account and a credit card.

       • Saxo Circ: Transactions have been allowed through both a bank account and a credit card.

       • CircPro: Transactions have been allowed through both a bank account and a credit card.

       • Matrix: Transactions can only be made with a credit card.

    3. Update EZPay:

       • NCS Circ: Transactions have been allowed through both a bank account and a credit card.

       • Saxo Circ: Transactions have been allowed through both a bank account and a credit card.

       • CircPro: Transactions have been allowed through both a bank account and a credit card.

       • Matrix: Transactions can only be made with a credit card.

    4. Restarts:

       • NCS Circ: Transactions have been allowed through both a bank account and a credit card.

       • Saxo Circ: Transactions have been allowed through both a bank account and a credit card.

       • Matrix: Transactions can only be made with a credit card.

    5. Tips:

       • NCS Circ: Transactions have been allowed through both a bank account and a credit card.

    Note: Any transactions made using other than the allowed payment methods will result in a validation error.

    Flow	NCS	Saxo	CircPro	Matrix
    Payment	CC/Bank	CC/Bank	CC	CC
    EZPay	CC/Bank	CC/Bank	CC/Bank	CC
    Update EZPay	CC/Bank	CC/Bank	CC/Bank	CC
    Restarts	CC/Bank	CC/Bank	N/A	CC
    Tips	CC/Bank	N/A	N/A	N/A

11. Given that tip and donation payments have been considered one-time charges in the Restart subscription and will always be recurring in the AutoRenew subscription, the POST /Payment/EzPay and POST /Payment/Restart endpoints have been modified to remove the input parameters, IsTipAutoRenew and IsDonationAutoRenew, from the request body.

12. The Payment Methods table structure has been modified as part of the refactoring of the Payments API. As a result, the token will now be mapped to the PaymentGatewayToken column rather than the BillingSystemPaymentMethodId column.

    The Billing API has now been modified so that the ExternalPaymentMethodId will now be associated with the PaymentGatewayToken rather than the BillingSystemPaymentMethodId.

13. As part of the Payments API restructuring, the following Billing API endpoints that handle the creation and retrieval of Payment Methods have been deprecated and replaced with new endpoints with the suffix 'v2'.

    • Billing/{subscriptionId}/CreatePaymentMethod

    • Billing/CreateOrphanPaymentMethod

    • Billing/{subscriptionId}/CreatePaymentMethodInRepo

    • Billing/{subscriptionId}/PaymentMethods/{paymentMethodId}

    • Billing/{subscriptionId}/PaymentMethods/{externalPaymentMethodId}/FromRepo

    • Billing/CreateOrphanPaymentMethod

    • Billing/Payments/{subscriptionId}/EzPaySignup

    • Billing/Payments/{subscriptionId}/ApplyPayment

    • Billing/Payments/{subscriptionId}/RestartPayment

    • Billing/Payments/{subscriptionId}/AddTip

    • Billing/{subscriptionId}/PaymentMethods

14. To simplify calculations by ensuring that the API returns rounded values without requiring additional rounding operations in consumer applications, the Current Balance returned in the GET /Billing/AutoBill/{subscriptionId} endpoint and Processing Fees and Tax returned in the POST /Billing/CreditCards/ProcessingFee endpoint have been modified to return values with no more than two decimals.

15. The POST /Billing/{subscriptionId}/PaymentMethods endpoint has now been replaced with a new endpoint POST /Billing/PaymentMethods to create a new payment method for a Subscriber using either a Credit Card or a Bank Account and to create a new record in the PaymentMethod table in the database.

16. The Purchase API endpoint, POST /Purchases, has been updated so that the Newstart flow will create payment methods in the database based on the new Payment Method schema created as part of the Payment API refactoring.

17. The earlier method for Instant Access involved the API looking for eEdition Complaint events to grant Temporary Access. This method has been changed by integrating the Complaints API with the TemporaryEntitlements API. Now, when creating a complaint with eEdition access as the resolution, a new record will be added to the TemporaryEntitlements table to provide temporary access to the subscribers.

18. To prevent users from attempting to restart their subscriptions if they already have pending restarts in the future, a validation check has been implemented in the CheckRestartAvailability (GET /Billing/Payments/{subscriptionId}/CheckRestartAvailability) and Restart (POST /Payment/Restart) endpoints.

4. API - Billing

1. The GET /Billing/{subscriptionId}/PaymentMethods/{paymentMethodId} endpoint has now been replaced with a new endpoint, GET /Billing/PaymentMethods/{paymentMethodId}, to retrieve the payment method information from the Naviga System based on the provided input parameter, PaymentMethodId (the unique identifier of a payment method in Naviga System).

2. The GET /Billing/AutoBill/{subscriptionId} API response has now been standardized across all Circ systems to retrieve billing information for a subscription in a single array for both Regular and Stopped subscriptions.

   The following output parameters will be returned in the array:

   1. Length

   2. Term

   3. DatePaidThru

   4. Rate

   5. Tax

   6. OtherCosts

   7. Amount

   8. IsAutoRenew

   Following the above development, the schema of One-CSR Portal API consuming AutoBill Id has been modified to display accurate rates data in the grid for Payment, Auto renew and Restart flows.

   Note:

   The API GET /api/GetBillingInformation/options/{subscriptionId} will be used for Restarts from now on, while the API api/GetBillingInformation/StoppedSubscriptionPaymentOptions/{subscriptionId} will be deprecated.

3. When retrieving billing information for a stopped subscription in Matrix, the GET /Billing/AutoBill/{subscriptionId} endpoint has been modified to include the PeriodId (output parameters: Term and Length) in the response.

Prerequisites: Circ System & Minimum Supported Version: Matrix, 38.0.034.ITSP6

5. API - Users

1. The Subscribe integration with Newzware has been modified to bypass the Users API and instead utilize Proxy/Gateway to communicate directly with the Newzware API and return the required output.

   A code cleanup has been done in the Users API to deprecate all Newzware-related classes.

2. The Users API endpoints have been updated to replace references to the Users API and integrate with the new UsersOrchestrator endpoints, GET /Users and GET Users/{UserId}. To get users, the Users API endpoints now call the UsersOrchestrator API rather than the Users API.

6. API - Entitlements

The Subscribe integration with Newzware has been modified to bypass the Entitlements API and instead utilize Proxy/Gateway to communicate directly with the Newzware API and return the required output.

A code cleanup has been done in the Entitlements API to deprecate all Newzware-related classes.

7. API - Purchase

1. The Purchase API endpoint, POST /Purchases, has been updated to replace references to the Users API and integrate with the new UsersOrchestrator endpoints. To get users when purchasing a new subscription, the Purchase endpoint now calls the UsersOrchestrator API rather than the Users API. The GET /Users endpoint will be used for SSOR clients, while the GET Users/{UserId} endpoint will be used for other authentication systems.

2. The Purchase API endpoint, POST /Purchase, has been updated to replace references to the old Entitlements API and integrate with the new Entitlements Orchestrator endpoint, POST /TemporaryEntitlements. When purchasing a new subscription, this creates a new record in the Subscribe TemporaryEntitlement’s Table.

8. API - Invitations

The Invitations API endpoint, POST Invitations/{invitationId}, has been updated to replace references to the Users API and integrate with the new UsersOrchestrator endpoint, PUT User/ (update user). To update users when creating a new invitation, the Invitations endpoint now calls the UsersOrchestrator API rather than the Users API.

9. API - UserOrchestrator

1. A new endpoint, GET /Users/{CustomerRegistrationId}/Links, has been added to the UserOrchestrator to retrieve the list of subscriptions associated with the Registration from the SubscriptionLinks table based on the provided CustomerRegistrationId.

2. The User Orchestrator now includes a new endpoint, POST /Users, which handles the workflow orchestration between the external services and the SubscribeRegistration API to create a user based on the input parameters listed below.

   • Email: Required; Subscriber’s email.

   • CustomerRegistrationId: Optional; Unique identifier for the user in the authentication provider.

   • EncryptedCustomerRegistrationid: Optional; Encrypted unique identifier for the user in authentication system.

   • Password: Optional; Subscriber’s password.

   • VerifyEmail: Optional; Default false. If True is provided, then the registration will not be created right away. Naviga would wait until the user confirmed the registration by clicking the link in the verification email.

   • ReturnUrl: Optional; URL to which users must be redirected after they have successfully verified their registration.

   • IgnoreProvider: Optional; If the IgnoreProvider flag is false, it executes a Create operation through the ThirdParty system (Integration). If the IgnoreProvider flag is true, it executes a Create operation through the SubscribeRegistration API (Subscribe).

   • FirstName: Optional; Subscriber’s first name.

   • LastName: Optional; Subscriber’s last name.

   • Metadata: Optional; Metadata must be an object in camelCase format.

3. The User Orchestrator now includes a new endpoint, PUT /Users/{CustomerRegistrationId}, to handle the workflow orchestration between the external services and the SubscribeRegistration API to update a user based on the input parameters listed below.

   1. CustomerRegistrationId: Required; Unique identifier for the user in the authentication provider.

   2. Verified: Indicates whether the user has confirmed the registration.

   3. LastLogoutDate: Subscriber's last logout date in the Naviga platform.

   4. RemoveLastLogoutDate: Indicates whether to remove the Subscriber's last logout date.

   5. FirstName: Optional; Subscriber’s first name.

   6. LastName: Optional; Subscriber’s last name.

   7. Metadata: Optional; Metadata must be an object in camelCase format.

   8. IgnoreProvider: Optional; If the IgnoreProvider flag is false, it executes a Create operation through the ThirdParty system (Integration). If the IgnoreProvider flag is true, it executes a Create operation through the SubscribeRegistration API (Subscribe).

4. The UsersOrchestrator now has a set of new endpoints to handle the Forgot Password and Change Password operations.

   • The Forgot Password (START) endpoint, POST /Users/ForgotPassword, has been developed to create the STARTFORGOTPASSWORD (PWDREQ) event and send an email with a link to the subscriber.

   • The Forgot Password (Validate) endpoint, GET /Users/ForgotPassword/{{EncryptedEventId}}/Validity, receives an EncryptedEventId and checks whether it represents a valid event for the forgot password flow.

   • The Forgot Password (FINISH) endpoint, POST /Users/ForgotPassword/{{EncryptedEventId}}, receives the new password to set based on an event. This will impact the AUTH system.

   • The Update Password endpoint, PATCH Users/{{customerRegistrationId}}/Password, updates the new password for a given CRID. This will impact the AUTH system.

5. The UsersAPI endpoints, POST /Authenticate and POST /AuthenticateByToken, have now been replaced with a new UsersOrchestrator endpoint, POST /Users/Authentication. This endpoint will handle the workflow orchestration between the external services and the SubscribeRegistration API to authenticate a user based on the input parameters listed below.

   1. Login Name (Optional)

   2. Password (Optional)

   3. Token (Optional)

   Note: Token-based authentication will only be applicable for Auth0 clients.

6. The following UserOrchestrator endpoints have been integrated with the Subscription Panel to create, update, and retrieve user data.

   1. GetUser API (/v4/Users?email={email})

   2. CreateUser API (/v4/Users)

   3. Authentication API (/v4/Users/Authentication)

   4. Forgot password API (/v4/Users/ForgotPassword)

   5. GetUserByCRID API (/v4/Users/{customerRegistrationId}/?ignoreProvider={boolean})

   6. UpdateUser API (/v4/Users/{customerRegistrationId}):

   The UserInformationV3 component should be included in the presentation in CMS.

   CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > UserInformationV3

7. The GET /Users endpoint has been enhanced to allow the API to filter the user data in the Subscribe Registration based on the metadata fields.

   To search using the metadata:

   • Since it is a dictionary query parameter, each "Key-Value" pair must be sent individually with the prefix "metadata." For example, if the purpose is to filter users based on their first and last names, the query string will be: "https://UrlBase/Users?metadata.firstName=FirstName&metadata.lastName=LastName”.

   • When an Email is provided:

     1. the lookup will be performed in Auth system and only one record will be returned.

     2. either pass an Email or encrypted email in the request since the email parameter passed will override the encrypted email value.

   • When the Metadata is provided:

     1. no more than 10 metadata parameters should be sent.

     2. In addition, each Key and Value of the metadata parameter should not exceed 100 characters.

   • while creating data, the metadata parameters should be passed in the string type. passing the value as Array will be saved but the GET /Users endpoint will not fetch the data.

   • In addition, the workflow has been changed to avoid searching for users based on both the Email AND Metadata. if both values are provided, a validation error will be returned.

   • When an email is provided:

     1. The lookup will be performed in the Auth system, and only one record will be returned.

     2. Either pass an email or encrypted email in the request since the email parameter passed will override the encrypted email value.

   • When the metadata is provided:

     1. No more than 10 metadata parameters should be sent.

     2. In addition, each Key and Value of the metadata parameter should not exceed 100 characters.

   • While creating data, the metadata parameters should be passed in the string type. Passing the value as an array will save it, but the GET /Users endpoint will not fetch the data.

   • In addition, the workflow has been changed to avoid searching for users based on both email and metadata. If both values are provided, a validation error will be returned.

8. Changes have been made to the Get User by ID endpoint, GET /Users/UserId/, so that if the input parameter, IgnoreProvider, has been set to True, users will be able to get the details of a user based on both the Email and Metadata fields provided at the same time since the data search will be within the database.

   If the IgnoreProvider parameter has been set to False, Email and Metadata fields cannot be accepted at the same time, and the API will return a validation error.

9. The Get Subscription Links endpoint, GET /Users/{CustomerRegistrationId}/Links, has been updated to return a set of additional output parameters in the SubscriptionInfo object of the API response, which have been listed below.

   • First Name: The user's first name

   • Last Name: The user's last name

   • ServiceTypeInfo (Core object): Includes the details of the service type of the subscription.

   • EZPay: Indicates whether the subscription has EZPay enabled.

   • AddressInfo (Core object): Includes the address details of the subscriber.

   • NewspaperInfo (Core object): Includes the details of the subscribed newspaper.

   • Subscription Kind: Indicates the kind of subscription, such as trial, complimentary, gift, etc.

10. The Auth0 API has been integrated with the UsersOrchestrator to handle requests against Auth0 services.

    This integration also includes few changes in UsersOrchestrator endpoints as follows:

    • Create User endpoint (POST /Users):

      • UsersOrchestrator will execute the create flow with the prefix "nav" for Custom Customer Registration ID (internal ID) for clients with custom implementations, i.e., if the value of MG2 control flow setting "Flow.Auth0.IntegrationType" has been set to 'Custom'. If the value is not "Custom," the normal flow will be executed by UsersOrchestrator.

      • When creating a passwordless user, UsersOrchestrator will generate a dummy password and the proper Change Password URL.

    • Get User By Id endpoint (GET /Users/{UserId}):

      • UsersOrchestrator will execute the GET operation with Custom Customer Registration ID (internal ID) as the QueryString parameter for clients with custom implementations, i.e., if the value of the MG2 control flow setting, "Flow.Auth0.IntegrationType", has been set to 'Custom'. If the value is not "Custom," the normal flow will be executed by UsersOrchestrator.

    Implementation Notes:

    1. The following setting will be used for the business selection:

       • SettingKey = Flow.Auth0.IntegrationType

       • SettingValue = Custom

       • SettingType = Flow

    2. New class:

       • Auth0CustomCreateOrchestrator

       • Auth0CustomGetByIdOrchestrator

11. Validation checks have been implemented in the Metadata fields of the POST /Users and PUT /Users/{CustomerRegistrationId} endpoints to make sure that the value provided is in an acceptable format.

    When providing the Metadata,

    • The Metadata key should not be more than 100 characters long.

    • Non-object values of the Metadata parameter cannot be more than 100 characters long.

    • These validations will also be applicable to nested properties.

12. A new endpoint, PATCH /Users/{{CustomerRegistrationId}}/Email, has been developed to update the email of a Subscribe Registration in SubCon and the Auth System.

    The workflow for updating the email address of a Subscribe Registration will be as follows:

    • The UsersOrchestrator executes a GetById operation (GET /Users/{UserId}) through the third-party or the SubscribeRegistration API.

    • The UsersOrchestrator then executes an Update Email operation (PATCH /Users/{{CustomerRegistrationId}}/Email) through the ThirdParty/SubscribeRegistration API.

    • This will create a CHGEMAIL event for all the normal cases.

    • For Firefly tenants,

      • If the new email does not exist in Firefly, a simple update email for the existing user will be required. The CHGEMAIL event will also be triggered in this instance.

      • If the new email exists in Firefly, a TRANSFERLICENSE event must be triggered for each linked subscription in order to transfer the link from the old email to the new email.

13. The UsersAPI endpoint, POST /User/VerifyEmail, has now been replaced with a new UsersOrchestrator endpoint, POST /Users/Verification, to perform the email verification operation based on the provided email and the verification code.

14. A new endpoint, POST /Users/VerificationCode, has been developed to send or resend a Verification Code by email so that users can click on the verification link provided in the email in order to start using their new registration. Implementation Notes:

    Email for Event 670 needs to be set up in the One-CSR portal.

15. When carrying out CRUD operations, the FirstName and LastName properties will be added to the root of the User object instead of being part of the Metadata.

16. The UserOrchestrator API has been updated to include the registration status in the API response.

    • The GET /Users and GET /Users/id endpoints have been updated to include a new output parameter, State, which returns the status of a registration.

      The registration's status will be returned as follows:

      • If the tenant has been associated with a third-party authentication system such as Auth0, Firefly, etc., the State will be returned as Standard.

      • If the tenant has been associated with MG2 Auth:

        • When the Password field in the database remains blank, the State will be Lite.

        • When the Verified field in the database has been set to False, the State will be Unverified.

        • When the Password field hasn't been blank and the Verified field has been set to true, the State will be Standard.

    • The POST /Users endpoint has been modified to display an error when trying to create a registration that already exists in the database and has the Verified field set to false.

    • The POST /Users/Authentication endpoint has been modified to display an error when trying to login with an Unverified or Lite registration.

17. A new endpoint, PATCH /Users/{CustomerRegistrationId}/CustomerRegistrationId, has been developed to update the CustomerRegistrationId (CRID) of a Subscribe Registration in the database.

    The workflow for updating the CRID of a Subscribe Registration will be as follows:

    • Based on the CRID provided in the API request path, the UsersOrchestrator performs a GetById operation (GET /Users/UserId) through the SubscribeRegistration API. The flow will be terminated if the provided CRID does not exist in the database.

    • Based on the CRID provided in the API request body, the UsersOrchestrator performs another GetById operation (GET /Users/UserId) through the SubscribeRegistration API. The flow will be terminated if the provided CRID does not exist in the database.

    • The Update CRID endpoint updates the record found in the database with the information retrieved by the Provider.

      • If both the CRID and the EncryptedCRID have been provided, the API will update both values in the database.

      • If only the CRID has been provided, the API will calculate the EncryptedCRID and update both values in the database.

      • If only the EncryptedCRID has been provided, the API will return a validation error since the CRID must be provided.

18. In the old Users API, a few endpoints were based on RegistrationID, while others were based on CustomerRegistrationID. However, in the new Users Orchestrator API, all endpoints use the CustomerRegistrationID as the main key for finding a registration. As a result, changes have been made to replace the parameter, RegistrationID, in the old APIs with CustomerRegistrationId.

    The following APIs have been updated:

    1. MessagingAPI

       • In the GetCampaignEmails endpoint, RegistrationId has been replaced with CustomerRegistrationId. The CustomerRegistrationId will then be used to filter the Campaign Messages in the database Store Procedure. This change has no impact on the existing functionality.

    2. InvitationsAPI

       • In the CreateInvitation endpoint, HostUserId has been replaced with HostUserCRID. The HostUserCRID is then utilized in the database Store Procedure without impacting the existing functionality. In addition, events will now be created by providing the EventData with a CustomerRegistrationId instead of a RegistrationId.

    3. ComplaintsAPI

       • In the CreateComplaint endpoint, RegistrationId has been replaced with CustomerRegistrationId. The events will now be created by providing the EventData with a CustomerRegistrationId instead of a RegistrationId.

    Note: The logic for populating registration's info fields will now be based on the CustomerRegistrationId, instead of the existing logic using RegistrationId (ApiCreateEventLog).

19. Changes have been made at the application level in the Users Orchestrator such that each operation now triggers its own event, so that the Event Log has a clear picture of everything that takes place either in the AuthSystem or in the DB, regardless of the AuthSystem that tenant has been configured for.

    Implementation Notes:

    The new events created for UsersOrchestrator no longer require the trigger_post/newspapereventprocessorassignments configuration. However, the new events still require email configuration if needed.

20. Metadata properties such as DisplayName, OptOutMarketing, and AgreeToTerms will be part of the CreateUser endpoint in the UserOrchestrator API for Mg2Auth, Auth0 and SSOR user authentication system, starting from this release. When a new user is created following a subscription purchase from SP, the API request body will now include these metadata properties along with other parameters such as FirstName, LastName, etc. The FirstName, LastName, and metadata will be stored in the Registrations Table of the Subsvc database.

    This is applicable only to creating a new user or updating an existing user. Display Name and Full Name will be displayed in the Users section of SubCon Admin.

21. In this release, the SS application has been enabled to utilize the new set of endpoints in the UserOrchestrator API, replacing the old Users API. Importantly, these enhancements do not result in any visual impact for users.

Some of the valid changes as part of this development are listed as follows:

• Previously a single endpoint served multiple operations such as changes to Email, Password and Profile information. With the new API, separate endpoints have been dedicated for each transaction.

  • When changing an Email, the new endpoint PATCH /Users/{{CustomerRegistrationId}}/Email is used now. Note: The client GCI that was using Transfer Links endpoint earlier has switched to use this new endpoint.

  • While changing password, the endpoint PATCH Users/{{customerRegistrationId}}/Password is used.

  • When changing any of the Profile fields, the endpoint Update User is used, saving the fields within the Metadata.

• Cookie values will only be returned by Authenticate endpoints. Consequently, the Verify flow can no longer authenticate the user. As part of the new enhancement, the verification flow has been tweaked. Once email verification is done, users are prompted to login by entering their credentials. This ensures a seamless and secure authentication process.

Implementation Notes:

• Create User:

  • If the IgnoreProvider flag is false, it executes a GetByEmail operation through the ThirdParty system (Integration) and a Create operation through the ThirdParty system (Integration) and the SubscribeRegistration API (Subscribe).

  • If the IgnoreProvider flag is true, it executes a Create operation through the SubscribeRegistration API (Subscribe).

  • CreateOrchestrator- BaseClass - SubscribeRegistration behavior.

    • Auth0CreateOrchestrator - ChildClass - Uses Flow.UserProvider = “Auth0”

    • SSORCreateOrchestrator - ChildClass - Uses Flow.UserProvider = “SSOR”

    • GigyaCreateOrchestrator - ChildClass - Uses Flow.UserProvider = “Gigya”

    • FireflyCreateOrchestrator - ChildClass - Uses Flow.UserProvider = “Firefly”

• Update User:

  • If the IgnoreProvider flag is false, it executes an update operation through the ThirdParty system (Integration) and the SubscribeRegistration API (Subscribe).

    If the IgnoreProvider flag is true, it executes an update operation through the SubscribeRegistration API (Subscribe).

  • UpdateOrchestrator- BaseClass - SubscribeRegistration behavior.

    • Auth0UpdateOrchestrator - ChildClass - Uses Flow.UserProvider = “Auth0”

    • GigyaUpdateOrchestrator - ChildClass - Uses Flow.UserProvider = “Gigya”

    • FireflyUpdateOrchestrator - ChildClass - Uses Flow.UserProvider = “Firefly”

• Forgot Password

  • ForgotPasswordStartOrchestrator- BaseClass - SubscribeRegistration behavior.

  • ForgotPasswordValidateOrchestrator- BaseClass - SubscribeRegistration behavior.

  • ForgotPasswordFinishOrchestrator- BaseClass - SubscribeRegistration behavior.

• Change Password

  • UpdatePasswordOrchestrator- BaseClass - SubscribeRegistration behavior.

    • Auth0UpdatePasswordOrchestrator - ChildClass - Uses Flow.UserProvider = “Auth0”

    • GigyaUpdatePasswordOrchestrator - ChildClass - Uses Flow.UserProvider = “Gigya”

    • FireflyUpdatePasswordOrchestrator - ChildClass - Uses Flow.UserProvider = “Firefly”

• Authenticate

  • AuthenticateOrchestrator- Abstract BaseClass

    • SubscribeAuthOrchestrator - ChildClass - Uses Flow.UserProvider = “MG2”

    • Auth0UpdateOrchestrator - ChildClass - Uses Flow.UserProvider = “Auth0”

    • GigyaUpdateOrchestrator - ChildClass - Uses Flow.UserProvider = “Gigya”

    • FireflyUpdateOrchestrator - ChildClass - Uses Flow.UserProvider = “Firefly”

• The UserInformationV3 component should be included in the presentation in CMS.

  CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > UserInformationV3

• Auth0 API Integration

  1. The following setting will be used for the business selection:

     • SettingKey = Flow.Auth0.IntegrationType

     • SettingValue = Custom

     • SettingType = Flow

  2. New class:

     • Auth0CustomCreateOrchestrator

     • Auth0CustomGetByIdOrchestrator

• The new events created for UsersOrchestrator no longer require the trigger_post/newspapereventprocessorassignments configuration. However, the new events still require email configuration if needed.

10. API - Gateway

When linking a subscription or changing a user's details in the registration, the logic used to be to create a UPDATEOCCUPANT event to maintain the subscriber details in sync with the Auth and Circ systems. Changes have been made to remove this logic and to not change the occupant details when changing a user's information through the Update Registration (PUT /User ) and Link Owner (POST /User/OwnerUser) endpoints.

11. API - Proxy

1. The Proxy API has been modified to handle requests for both the old Entitlements API and the new Entitlements Orchestrator API listed below.

   1. Post Access (POST /Access)

   2. Post TemporaryEntitlement (POST /)

   3. Get Access (GET /Access)

   In order to redirect to EntitlementsOrchestratorAPI, ProxyAPI must have the following settings in place:

   • MG2 Control Internal setting, EntitlementsOrchestrator - Its value includes a "string.Format" that must be utilized to determine the correct API route. The value by default is "{0}/EntitlementsOrchestrator/".

   Note: Since the ProxyAPI directly calls the EntitlementsOrchestratorAPI, GatewayAPI is not involved in the request chain.

   Implementation Notes:

   If the error message— "Procedure or function 'ApiGetEntitlementAccessByCustomerRegistrationId' expects parameter '@EntitlementId', which was not supplied." has been returned, the Proxy API should be pointing to EntitlementsOrchestrator.

2. The following endpoints have been removed from the UsersAPI and GatewayAPI. In addition, changes have been made in the Proxy API so that if a client that has upgraded to 3.17 attempts to access any of these endpoints, an error message stating that the endpoint has been deprecated will be displayed.

   1. POST User/ByToken/ (GetUserFromTokenContent)

   2. GET User/Encrypted/{type} (encrypted crid)

   3. GET User/Encrypted/

   4. GET User/{customerRegistrationId}/{type}

   5. GET User

   6. POST User

   7. PUT User

   8. PUT User/{customerRegistrationId}

   9. POST User/Passwordless

   10. POST Authenticate

   11. POST AuthenticateByToken

   12. POST ForgotPassword

   13. POST ForgotPassword/Validity

   14. POST ForgotPassword/ChangePassword

   15. POST User/TransferLinks

   Implementation Notes:

   MG2 Control Flow Setting, Flow.Users.RedirectToOrchestrator should be configured correctly.

3. The Post/DigitalAccess endpoint has been removed from the Entitlements and Gateway APIs. In addition, changes have been made in the Proxy API so that if a client that has upgraded to 3.17 attempts to access this endpoint, an error message stating that the endpoint has been deprecated will be displayed.

4. Previously, the ProxyAPI handled tenant version selection as well as request redirection to the GatewayAPI, which sometimes acts as an orchestrator and sometimes does not, but always routes requests to internal services.

   As part of the Subscribe API refactoring, the old internal services have been migrated and moved to new ones using the orchestrator paradigm, allowing signatures to be created or modified and the output model to be modified in terms of ProxyAPI.

   A set of new endpoints has been created with the prefix “v4” as listed below:

   • v4_DirectIntegration

   • v4_Entitlements

   • v4_Subscriptions

   • v4_Users

   Versions 3.17.0 and higher:

   • ProxyAPI will support both the new and old endpoints.

   • The ProxyAPI will route requests to the relevant OrchestratorAPI for new endpoints with Prefix v4.

   • The ProxyAPI will redirect requests to the GatewayAPI for old endpoints (for backwards compatibility with older versions).

5. The Proxy API has been modified to return Headers (X-SessionId, X-RequestId, and X-Version) in the response headers as well as the correct Status Code (200, 400, 401, 404, 500, 502, etc. ) in the response status.

12. API - Ping

A new endpoint, GET /ping, has been developed so that the Naviga monitoring tool can keep monitoring to check whether an API is down.

Affected Endpoints:

1. Auth0

2. BPay

3. DirectIntegration

4. EntitlementsOrchestrator

5. MailingOrchestrator

6. Melissa

7. NavigaPay

8. SubscribeEmails

9. SubscribeEntitlements

10. SubscribeEvents

11. SubscribeRegistration

12. SubscribeRegistrations

13. SubscribeSubscriptionLinks

14. SubscribeSubscriptions

15. SubscriptionsOrchestrator

16. UsersOrchestrator

13. API - Subscriptions

1. The Subscriptions.HHSubscriptionLevel column in the Subscriptions table has been renamed to HouseHoldLevelId to establish a foreign key with the HouseHoldLevels table.

   The Subscriptions API endpoints GET /Users/{customerRegistrationId}/Subscriptions, GET /Subscriptions, and GET /Subscriptions/{subscriptionId} have now been modified to display the values in the API response based on the renamed property, HouseHoldLevelId.

   Modified endpoints:

   • GET /Users/{customerRegistrationId}/Subscriptions

   • GET /Subscriptions

   • GET /Subscriptions/{subscriptionId}

2. The PUT /Subscriptions/{subscriptionId} endpoint has been modified to include a new input parameter, PaymentMethodId, which allows a payment method to be assigned to the subscription in order to process the transaction.

14. API - Gateway

1. The GET /Settings/{settingkey} endpoint in the Gateway API has been deprecated because it duplicates with another endpoint, GET /Settings/, and requires the input parameter SettingKey to be provided as a PathString rather than a QueryString. The endpoint GET /Settings/ will now be utilized instead of the deprecated GET /Settings/{settingkey} endpoint.

2. The Apply Payment endpoint, POST /Payment, has now been added to the PaymentsController in the Gateway and Proxy API.

3. Previously, the Proxy and Gateway projects included input and output models for each request executed; however, they are no longer in use. Changes have been made to replace the input/output models for Proxy and Gateway projects with objects, preventing custom logic and parameters from being provided in the URL.

15. Naming Convention from PascalCase to camelCase

To maintain the consistency across applications, the naming convention of the metadata objects for all endpoints in the Invitation API has been changed from PascalCase to camelCase. This modification has no visual impact on users engaging in Invitation flows. The Invitation flows will continue to function as earlier. Invitations can be sent and accepted successfully, and users can be registered with all the provided information.

16. User session maintenance in SS and SP

For MG2Auth clients, when Sign in/Sign up happens on Self-Service Portal, Subscription Panel, or any .com site (auth managed by Connext) the following cookies will be created on the root domain:

• igmRegID

• igmContent

• igmAuth

The primary purpose of these cookies is to maintain the Single Sign-On between SS, Subscription Panel, and the .com site. The igmRegID cookie stores the encrypted Customer Registration ID.

In a recent development, the endpoint in the old Users API used to look up a user by the Encrypted Customer Registration ID was deprecated. However, for MG2Auth clients, the cookie value was crucial for recovering the user session. With the deprecation of the endpoint, it became challenging for MG2Auth clients to look up the user (since the cookie value was encrypted) and recover or maintain the user session between SS, SP, and .com site.

Instead of reinstating the old endpoint, the decision was made to add a new parameter in the Get Users endpoint. This new parameter will be included in the search criteria to facilitate the required functionality.

Starting from this release, the GET /Users endpoint in the User Orchestrator API will introduce a new parameter: EncryptedCustomerRegistrationId. To ensure consistency across all applications, SS will no longer decrypt the igmRegId cookie value for MG2 Auth clients. The encrypted cookie value will be considered as-is and will be utilized at the GET /Users endpoint in the User Orchestrator API to retrieve user details and recover the user session.

With this enhancement, a user logged into SS and SP with MG2 Auth will no longer be logged out upon reloading the page. This improvement enables the successful maintenance of user sessions.

Implementation Notes:

The User Information V3 component should be present in the presentation. The user can configure the properties by going to:

• CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > UserInformationV3

CMS

1. Clear Cache

In the Clear Cache API calls, a new header parameter, X-SourceSystem, has been added as a required field with the value CMS for all the clients.

In addition, the X-MediaGroupCode header parameter has been changed to X-ClientGroupCode.

2. CMS Content Module Changes

The footer page of the CMS Content Module has been changed from Visual Basic .NET (VB.NET) to NET Framework 4.8 (.NET 4.8).

3. New endpoint to monitor the health of CMS

The CMS API now includes a new endpoint, ping, for monitoring the performance of the CMS application. The application's status can be monitored using the Status/Ping route details.

SP

1. Performance Optimizations

On the subscription panel, performance issues caused by render-blocking resources such as CSS and JS files on the UI side have been resolved. To prevent the issue, the render-blocking resources will now be preloaded or loaded in an asynchronous manner.

In addition, the "commonResource" and "commonResourceBody" pug files have been included in the layout pug file in order to allow for multiple GTM script additions as well as the ability to add a script in the body of the pug.

2. Purchase API

When purchasing a subscription in SP through AuthorizeNet, changes have now been made to modify the way parameters have been sent in the CreatePaymentMethod through the Purchase microAPI.

1. The value of the parameter "ExternalPaymentMethodId" in Purchase microAPI will now have the value of the parameter "CustomerPaymentProfileId" in EndPaymentSession API.

2. In addition, a new parameter, "ExternalCustomerId," has been introduced to the Purchase microAPI, which will have the value of the EndPaymentSession API parameter, "CustomerProfileId."

Implementation Notes:

1. Credit card option should be checked for particular offer group id in SolCon.

2. Credit Card AuthorizeNet component should be there in the presentation.

SubCon DB

1. Optimization in Stored procedure

The Stored Procedure ApiGetActiveSubscriptionByCustomerRegistrationId is optimized now. The ‘where’ clause in the stored procedure was not optimized and hence it was taking time to execute. After the optimization rework, the performance of stored procedure is enhanced, and cost of execution is reduced.

2. Subsvc - Registrations Clean up

The Registrations table has undergone cleanup to align with the fields decided for mapping in the new Users Orchestrator API.

The list of columns after the cleanup are as follows:

• RegistrationId

• CustomerRegistrationId

• EncryptedCustomerRegistrationId

• EmailAddressId

• NameFirst

• NameLast

• LoginPassword

• VerificationCode

• Verified

• Metadata

• LastLogoutDate

• AddDate

• AddSource

• ChangeDate

• ChangeSource

Additionally, with the help of a script, data has been moved into the Metadata before deprecating the columns from Subs. The following changes have been done.

Data moved to Metadata:

• [title]

• [phone] - Metadata - PhoneNumber

• [gender]

• [age]

• [dob]

• [dobYYYY]

• [acceptsEmailOffers]

• [acceptsEmailAds]

• [acceptsEmailPromotions]

• [isOkToEmail]

• [isOkToPhone]

• [isOkToMail]

• [WorkPhone]

• [timeZone]

• [scoreMember]

• [companyName]

• [cellPhone]

• [acceptsEENotification]

• [ebill_flag]

• [eadvan_flag]

• [eedition_flag]

• [ee_email_flag]

• [promo_flag]

• [feat_flag]

• [dealdigger_flag] [ads_flag]

• [member_event_flag]

• [contentEngagement_flag]

• [subcom_flag]

• [survey_flag]

• [accountUpdates_flag]

• [Photo]

• [DisplayName]

• [OptOutMarketing]

• [AgreeToTerms]

• [bounceType]

Data Removed:

• [AuthSystemId]

• [nameFull]

• [nameMiddle]

• [emailAddress]

• [emailFormat]

• [registrationAddressId]

Further details are available here: ColumnMigratorApp → Subsvc - Registration - Column Migrator

3. Subsvc - Extended EncryptedCustomerRegistrationId column

Some discrepancies in the Database that were causing data issues have been fixed by altering the schema. There is no impact on the end user.

4. Subsvc - Script to migrate from old User to new UserOrc Event Types

As part of the API Refactor and the development of the new Users Orchestrator API, an entirely new set of Event Types have been introduced to replace the previous event types associated with transaction emails and were triggered by the old User API endpoints. A post-deployment script has been created to assign the TransactionEmail to the new event types, ensuring the successful sending of transaction emails when the corresponding new events are triggered. After deployment, TransactionEmails (that are configured under 'Event management > Event types emails' against each Event ID in One-CSR Portal) will be assigned to new event types.

The following event types are the ones that got replaced by the new ones:

Old Event Types with Event ID	New
CREATELOGIN 68	SUBSCRIBE_USER_CREATE 4002
VERIFYCODE 670	SUBSCRIBE_USER_CREATEPENDING 4003
PWDREQ 64	SUBSCRIBE_USER_STARTFORGOTPASSWORD 4009

Implementation Notes:

A script has been incorporated into the DACPAC (Data-tier Application Component Package) to replace the old event types with the new ones.

Sync Jobs

1. Payment Method Changes

A new version of the 'Create Payment Method' endpoint, previously part of the Billing API prior to 3.17.0, has been introduced in the new Payments API starting from version 3.17.0. To ensure synchronization between Sync jobs and the API refactor, the following modifications have been made:

• The input model has been streamlined to only receive the essential payment information (masked in case of CC), Payment gateway token, and customer ID (if the Payment gateway exposes it).

• The PaymentMethods table has been revamped retaining only the columns that are essential.

Payment Method changes

Deprecated columns 1. SubscriberId 2. NameFirst 3. NameLast 4. CompanyName 5. Title 6. Phone 7. Currency 8. Description 9.PaymentMethodType 10. customerSpecifiedType 11. merchantPaymentMethodId 12. sortOrder 13. creditCardSecurityCode 14. creditCardLastDigits 15. creditCardExpirationDate 16. billingSystemCustomerId

Added columns 1. PaymentGatewayToken 2.PaymentGatewayCustomerId 3. BankName

Renamed columns 1. RoutingNumber → BankRoutingNumber 2. creditCardType → creditCardTypeId

The change in the logic flow of Payment Method:

• There will no more relationship between Subscriber and PaymentMethods table. This means that, there will be only one payment method associated to each subscription (Subscription already has a Foreign Key to PaymentMethod table).

In the new logic, Sync jobs will perform the following:

• If a new Subscription record has to be created, its corresponding PaymentMethod record will be created.

  • If it's an EZPay Subscription, the Payment Method will be populated with the Autorenew information the corresponding subscription already has.

  • If it's NOT an EZPay Subscription, the Payment Method will be populated with the most recent Payment done by that Subscription.

• For existing Subscriptions, the sync job will assure that the information is correctly updated.

  • The current info (CC, BK, etc) will be compared with the information exposed in the file. If there is any change, the Subsvc record will be updated. Whenever an update occurs, the PaymentGatewayToken and PaymentGatewayCustomerId columns wil be updated to NULL.

2. Subsvc Registrations Table Schema Changes - Impact on OI, Discover & Other jobs

As part of the 3.17.0 Refactor, the Registrations table in Subsvc DB underwent cleanup so as to map the fields correctly to the new Users Orchestrator API introduced in this release. Some columns are retained, some are moved to Metadata field whereas a few are deprecated.

These modifications have eventually led to database schema changes. These changes were implemented in sync jobs to ensure effective data synchronization, subsequently reflecting correctly in OI DB, and from there, propagating to Subscribe DB.

---

Future Enhancements

1. PayTrace Integration through NavigaPay

The payment provider PayTrace has been successfully integrated with NavigaPay. Now it is possible to successfully complete payment transaction with PayTrace through NavigaPay from SP and Self-Service Portal. In the payment iFrame provided by PayTrace, the user can enter a credit card number with a maximum of 19 digits in the Credit Card field. The CVV number can have a maximum of 4 digits in the CVV field (4 digits of CVV is for AMEX cards).

NOTE: PayTrace does not support special characters in the User name field. If a user enters any special character in the User name field, the system will throw an error.

If the user is browsing in Incognito mode, then third-party cookies must be allowed in the Chrome settings to load NavigaPay PayTrace. To enable third-party cookies on the browser perform the following steps: Chrome > Settings > Privacy & Security > Third-party cookies > Allow third-party cookies.

This integration was achieved through enhancements made to the Subscription Panel, CMS and Self-Service Portal. The details of these application-specific enhancements are provided below:

PayTrace Integration - CMS Configurations

• A new CMS component NavigaPayPayTraceV3 has been introduced with the following properties.

• The users can configure the properties by going to: CMS > Subscription Panel > Presentation (Choose a valid presentation) > Page V3 > Step V3 > PaymentMethodsV3 > NavigaPay PayTrace V3

PayTrace style Customization

The style of PayTrace iFrame has been customized and matched with the look and feel of the Self-Service Portal and Subscription Panel.

Implementation Notes:

1. Client using NavigaPay with PayTrace should contain a CSS file of a particular theme.

   config.NavigaPayPayTrace = {
   defaultFileName: 'hostedDefault.css',
   simpleFileName: 'hostedSimple.css',
   seamlessFileName: 'hostedSeamless.css'
   };

2. For customizing PayTrace iFrame style, the following list of MG2 Control API setting keys must be in place:

   • SubscriptionPanel.NavigaPay.SiteCode = cvpaytrace

   • SubscriptionPanel.NavigaPay.SiteKey = fred

   • SubCon.NavigaPay.FieldOptionalString

   • SubCon.NavigaPay.LabelString

   • SubCon.NavigaPay.SubmitButtonString

   • SubCon.NavigaPay.CurrentCSS

2. API

2.1. API - Payments (DSI)

1. The POST /Billing/Payments/{subscriptionId}/ApplyPayment endpoint has now been replaced with a new endpoint, POST /Payment, to perform a one-time payment in Circulation Systems (Saxo) based on the below input parameters.

   • SubscriptionId: the unique identifier of the Subscription in Naviga System.

   • PaymentMethodId: the unique identifier of the payment method in Naviga System.

   • DonationAmount: Donation amount.

   • TipAmount: Tip amount.

   • TotalAmount: The total amount being paid (PaymentOptionAmount + TipAmount + DonationAmount + ProcessingFeeAmount + ProcessingFeeTaxAmount).

   • PaymentOptionAmount: The Payment Option Amount being paid.

   • IgnoreFee: Indicate whether the Activation Fee should be ignored. Applicable for NCS clients.

   • TransactionId: Transaction ID created by the Payment Gateway when creating a new Payment Method. Applicable for Matrix clients.

   • ProcessingFeeAmount: The Fee amount being paid. Applicable for NCS clients.

   • ProcessingFeeTaxAmount: The Fee tax amount being paid. Applicable for NCS clients.

   Note:

   • The Activation Fee is only applicable to NCS clients, and the amount can be defined in DTI.MG2Control setting ActivationFeeAmount (applicable if IgnoreFee is set to false). Currently, this is not taken into consideration in the TotalAmount validation.

2. The POST /Billing/Payments/{subscriptionId}/RestartPayment endpoint has now been replaced with a new endpoint, POST /Payment/Restart, to restart a stopped subscription in Circulation Systems (Saxo) based on the below input parameters.

   • SubscriptionId: the unique identifier of the Subscription in Naviga System.

   • PaymentMethodId: the unique identifier of the payment method in Naviga System.

   • Donation.DonationAmount: Donation amount.

   • Tip.TipAmount: Tip amount.

   • Donation.IsDonationAutoRenew: Indicates whether the Donation amount should be auto-renewed. Applicable only for Saxo.

   • Tip.IsTipAutoRenew: Indicates whether the Tip amount should be auto-renewed. Applicable only for Saxo.

   • TotalAmount: The total amount being paid (PaymentOptionAmount + TipAmount + DonationAmount + ProcessingFeeAmount + ProcessingFeeTaxAmount - Subscription’s Balance).

   • PaymentOptionAmount: The Restart Option Amount being paid.

   • TransactionId: the Transaction ID generated by the payment gateway when a new Payment Method is created. Applicable only for Matrix.

   • RenewalTerm: Indicates the Circulation System Provider's renewal term. Applicable for CircPro and NCS.

   • RenewalLength: Indicates the Circulation System Provider's renewal length. Applicable for CircPro and NCS.

   • RestartDate: Indicates the Subscription’s Restart Date. Currently, this is applicable for CircPro and Matrix.

   • CreateRestartEvent: Indicates whether to create the RESTART event. For Saxo, CreateRestartEvent can be set to False if the client chooses to restart payment without restarting the subscription. Otherwise, this is optional.

   • ProcessingFeeAmount: Fee amount being paid. Currently, this is applicable only to NCS.

   • ProcessingFeeTaxAmount: Fee tax amount being paid. Currently, this is applicable only to NCS.

3. The POST /Billing/Payments/{subscriptionId}/EzPaySignup endpoint has now been replaced with a new endpoint, POST /Payment/EzPay, to create a payment method for a recurring payment (EZPay) in Circulation Systems (Saxo) and assign it to a subscription in Naviga System based on the below input parameters.

   • SubscriptionId: Unique identifier of the Subscription in Naviga System.

   • PaymentMethodId: Unique identifier of the payment method in Naviga System.

   • PaymentOptionAmount: EZPay Option Amount that will be paid.

   • Donation.DonationAmount: Donation amount.

   • Tip.TipAmount: Tip amount.

   • Donation.IsDonationAutoRenew: Indicates whether the Donation amount should be auto-renewed. Applicable only for Saxo.

   • Tip.IsTipAutoRenew: Indicates whether the Tip amount should be auto-renewed. Applicable only for Saxo.

   • RenewalTerm: Indicates the term to the Circulation System Provider. Applicable only for Matrix, CircPro, and NCS.

   • RenewalLength: Indicates the length to the Circulation System Provider. Applicable only for Matrix, CircPro, and NCS.

4. The PUT /Billing/{subscriptionId}/PaymentMethods endpoint has now been replaced with a new endpoint, PUT /Payment/EzPay, to update the payment method for a recurring payment (EZPay) in Circulation Systems (Saxo) and assign it to a subscription in Naviga System based on the input parameters SubscriptionId (the unique identifier of the Subscription in Naviga System) and PaymentMethodId (the unique identifier of the payment method in Naviga System).

2.2. API - Subscribe Subscriptions

• A new endpoint, GET /Subscriptions/{SubscriptionId}, has been developed to retrieve the complete details of a particular Subscription based on the provided input parameter SubscriptionId.

• A new endpoint, GET /Subscriptions, has been developed to retrieve a paginated list of Subscribe Subscriptions.

2.3. API - SubscriptionsOrchestrator

1. A new orchestration API, GET /Subscriptions/{SubscriptionId}/Links, has been developed to handle the workflow orchestration between the external services and the SubscribeSubscriptionLinks API. The API retrieves the list of Registrations associated to the Subscription in SubscriptionLinks table based on the input parameter SubscriptionId.

2. A new orchestration API, GET /Subscriptions/{SubscriptionId}/LinksInformation, has been developed to handle the workflow orchestration between the external services and the SubscribeSubscriptionLinksInformation API. The API retrieves the Subscription.DefaultOwnersLimit and Subscription.DefaultGuestsLimit configured for a Tenant based on the input parameter SubscriptionId.

3. A new orchestration API, GET /Subscriptions, has been developed to handle the workflow orchestration between the external services and the SubscribeSubscriptions API. The API retrieves a paginated list of subscriptions based on the provided user’s details (First or Last name, account number, Email, Phone, etc.).

4. A new orchestration API, GET /Subscriptions/{Id}, has been developed to handle the workflow orchestration between the external services and the SubscribeSubscriptions API. The API retrieves a paginated list of subscriptions based on the provided ID (Subscribe SubscriptionId).

Implementation Notes:

1. A new MG2 control internal setting, SubscriptionsOrchestrator, has been added.

2. The below two new MG2 control internal settings have to exist in MG2 Control.

   • Subscription.DefaultOwnersLimit: The maximum number of Links that can be set for Owner Type is defined by this setting.

   • Subscription.DefaultGuestsLimit: The maximum number of Links that can be set for Guest Type is defined by this setting.

2.4. API - Subscribe Subscription Links

1. A new endpoint, GET /SubscriptionLinks, has been developed to retrieve the Subscribe Subscription Links based on the input parameters CustomerRegistrationId, RegistrationId, and SubscriptionId. In order to obtain the details, at least one of the aforementioned input parameters must be provided.

2. A new endpoint, POST /SubscriptionLinks, has been developed to create a new Subscribe Subscription Link in the SubscriptionLinks Table based on the input parameters CustomerRegistrationId, SubscriptionId, and TypeLink (OWNER or GUEST).

3. A new endpoint, PUT /SubscriptionLinks/{subscriptionLinkId}, has been developed for modifying the Subscribe Subscription Link in the SubscriptionLinks Table based on the input parameter SubscriptionId.

4. A new endpoint, DELETE /SubscriptionLinks/{subscriptionLinkId}, has been developed to delete a Subscription Link from the SubscriptionLinks Table based on the input parameter SubscriptionId.

5. A new endpoint, PUT /SubscriptionLinks/{SubscriptionLinkId}/Transfer, has been developed to update the CustomerRegistrationId of a Subscription Link in the SubscriptionLinks Table based on the input parameter CustomerRegistrationId.

Implementation Notes:

A new event_type_id, UPDATELINK event_type, has been added in subcon.database.

2.5. API - Subscriptions

1. The GET /Subscriptions/subscriptionId/Cancelled endpoint has been integrated with the PermStop CircAPI so that the Subscribe API now creates and processes the GETPERMANENTSTOP event to retrieve the real-time scheduled stops for a given subscription instead of consuming the data from the Subsvc database when checking the status during the cancellation of a subscription in NCS Circ.

2. The GET /Subscriptions/subscriptionId/Cancelled endpoint has been integrated with the getFutureChanges CircPro LawAPI so that the Subscribe API now creates and processes the GETPERMANENTSTOP event to retrieve the real-time scheduled stops for a given subscription instead of consuming the data from the Subsvc database when checking the status during the cancellation of a subscription in CircPro.

3. The GET /Subscriptions/subscriptionId/Cancelled endpoint has been integrated with the CancellationListID MatrixAPI so that the Subscribe API now creates and processes the GETPERMANENTSTOP event to retrieve the real-time scheduled stops for a given subscription instead of consuming the data from the Subsvc database when checking the status during the cancellation of a subscription in Matrix.

Prerequisites:

Circ System & Minimum Supported Version:

• CircPro, 2021-3.0

• Matrix, 38.0.034.ITSP6