NCS Circ Rapid Release: 2025-3.1
This is a draft version.
Note: This release is in pre-beta.
Product Information contained within this document, including technical information and functional specifications, is subject to change without notice, and Naviga reserves the right to make any changes to the information in this document at any time without notice. Naviga makes no warranty, representation, or guarantee regarding the suitability of its products and services for any particular purpose.
✨Introduction
Welcome to the NCS Circulation 2025-3.1 release. This rapid release includes enhancements and bug fixes across Customer Service, Accounting, Payments, Extracts, iServices Distribution, and the Circulation API.
This release adds tokenized Bank Draft payment support across multiple Circulation API endpoints, including Create Subscription, Create Subscription by Campaign, Create Payment, Billing Change, and Billing Change by Campaign. The Customer Service API now supports tokenized Bank Draft payments for single payments and auto pay. In Accounting, the ACH Bank Draft export now supports optional Addenda Records (Type 7), which can be enabled through a new Business Rule. Other enhancements include custom payment authorization messages for ImpressPay in Setup and standardized customer ID mapping for Moneris payments when CustomTags is enabled.
This release also includes important bug fixes. The credit card surcharge calculation for Advanced Premium Day charges in Customer Services has been corrected. The Hosted Order Page no longer becomes unresponsive during credit card payments or Auto Pay billing changes, and the Legacy Hosted Order Page now returns the Vault ID correctly during credit card vaulting. Additional fixes address Account Lockbox Processing errors for two-token payment vendors, missing expire transactions for Grace status subscribers in the expire_date.txt file of Subscribe Extract, and incorrect route assignment for Targeted Marketing product complaints. In iServices Distribution, an error message is now displayed when the required Business Rules are not configured, indicating the missing Business Rule value before a return submission can proceed.
🖥️Minimal Requirements
Naviga Pay
2.2
Payment Authorization Service (PAS)
8.11.61
Circulation
2025
Subscribe
TBA
🛠️Resolved Issues
👥 Customer Service
QAS Hierarchical Address Expansion Issue Resolved Previously, when using the QAS platform for address cleansing, the “+” icon used to expand hierarchical address results, such as streets within a locality or address ranges within a street, did not function correctly due to an issue in the ActiveMQ JAR file.
This issue has been resolved. Users can now expand and navigate hierarchical address levels in the QAS platform as expected.
(CM2-12764, PBS44#80)
Correct Route Assignment for TM Product Complaints When a complaint was entered for a Targeted Marketing (TM) product, the system incorrectly assigned the Route ID from the subscriber’s route-delivered subscription instead of the Route ID associated with the TM product. As a result, complaints were routed incorrectly for distribution and dispatch.
This issue has been resolved. The system now assigns the correct Route ID associated with the TM product when a complaint is entered, even if the subscriber also has a separate route-delivered subscription. Complaints are now dispatched based on the TM product’s delivery route.
(CM2-13053, CM44#1190)
Auto Pay Validation Error Resolved for Moneris with HOP Bypass When recreating Auto Pay for former Auto Pay subscribers using Moneris through Naviga Pay with Hosted Order Page (HOP) bypass enabled, entering valid vault details previously triggered the validation error “Entry 2 is outside the range of list FIRSTNAME.LASTNAME (560).”
After the error occurred, the Credit Card Holder Name field was cleared and locked, and the IssuerID entered during payment setup was replaced with a system-generated value after the transaction was accepted.
This issue has been resolved. The validation error no longer occurs when valid VaultID and IssuerID values are entered. The Credit Card Holder Name field now remains populated and editable after saving payment information, and the IssuerID entered by the user is retained and no longer overridden after transaction acceptance.
(CM2-13068, CM44#1220)
💼 Accounting
Occupant Information Not Populated on Hosted Order Page in Payment Entry When using Naviga Pay, the Hosted Order Page in Accounting > Account Payments > Payment Entry did not automatically populate Occupant information during payment processing.
This issue has been resolved. The Hosted Order Page now automatically populates available Occupant information, including Phone Number, ZIP Code, and other related data when present in the system, along with associated customer and transaction data.
(CM2-12498, CM44#1300)
Invoice Selection Cleared When Payment Amount Is Modified in Payment Entry In Accounting > Account Payments > Payment Entry, when the Apply Method was set to Invoice, reducing the Payment Amount after selecting invoices did not clear the previously selected invoices. This resulted in inconsistencies, including the creation of negative Unapplied Payments (UNAP) and incorrect updates to OpenItem records. This issue has been resolved. When the Payment Amount is reduced after selecting invoices, the system now clears the previously selected invoices and requires them to be reselected before applying the payment.
(CM2-12799, CM44#1230)
Account Lockbox Processing Error with Two-Token Payment Vendors An issue in Account Lockbox Processing affected payments processed through Naviga Pay two-token payment vendors. This issue has been resolved.
Payments now complete successfully for all supported two-token vendors. (CM2-12935, CM44#1160)
🌐 iServices Distribution
Return Submission Fails Without Configured Business Rules in iServices Distribution When submitting a return in iServices Distribution, the system redirected back to the Returns page without saving the return, and no error message was displayed.
This occurred when the following Business Rules were not configured with a value, preventing the return from being processed, even if unauthorized returns were not used.
Business Rules—
When entering a return transaction, what is the return adjust code for authorized returns? (QuestionID: DistRtnAdjCode, CMO > Distribution > Returns section) and
When entering a return transaction, what is the return adjust code for unauthorized returns? (QuestionID: DistUnAuthRtnAdjCode, CMO > Distribution > Returns section)
This issue has been resolved. An error message is now displayed when the required Business Rules are not configured, indicating that the Business Rule value is missing.
BR - DistRtnAdjCode error 
BR - DistUnAuthRtnAdjCode error (CM2-12054, CM44#630 - CMO44#60)
🏦 Payments
HostedPageProviderConfig Convert Configuration Missing for ImpressPay The HostedPageProviderConfig Convert configuration for ImpressPay was removed across environments. As a result, authorization failed for ImpressPay transactions when the required configuration was not present.
This issue has been resolved. The HostedPageProviderConfig Convert configuration for ImpressPay is no longer removed across environments.
(CM2-12597, CM44#1280)
Hosted Order Page Unresponsive During Credit Card Payments and Auto Pay Billing Changes
An issue caused the Hosted Order Page (HOP) to become unresponsive when creating Credit Card payments or submitting Billing Changes for AutoPay. After selecting Submit, the page did not progress, displayed no error, and appeared to freeze.
This occurred because the system was setting the Email field value to null. In cases where the Email field is not displayed on the HOP, the missing value prevented the payment request from being processed.
This issue has now been resolved. The HOP submits as expected, and Billing Changes and payment actions process correctly.
(CM2-12869, CM44#1130)
Legacy Hosted Order Page Not Returning VaultID During Credit Card Vaulting Previously, sites using the Legacy Hosted Order Page (HOP) instead of Naviga Pay were able to enter Credit Card details in the HOP UI, but the vaulting process did not complete because the VaultID was not returned to the NCS Circ system.
This issue occurred because JxBrowser blocked the required hostname during HOP navigation, which prevented the system from receiving the VaultID. As a result, Credit Card vaulting failed across multiple modules, including Customer Service (Payment Entry, Billing Changes) and Accounting (Payment Entry).
This issue has been resolved. The Legacy Hosted Order Page (HOP) now correctly returns the VaultID, and Credit Card vaulting completes successfully across all affected modules.
(CM2-12877, PBS44#100)
Corrected Credit Card Surcharge Calculation in Customer Services The Credit Card Surcharge calculation on the Customer Services > Rates tab has been corrected to ensure accurate surcharge and tax calculations.
Previously, the surcharge fee was not applied correctly to Advanced Premium Day charges, and surcharge tax was not included when the surcharge was configured as taxable. As a result, the CC Total Amount in the Rate Terms subtab and the CC Payment Amount in the Price Quote subtab, under the Rates tab, did not align with the amount calculated during Credit Card payment processing.
This issue has been resolved. The calculation logic now follows the correct formula:
CC Total Amount = (Base Amount + Premium Amount) × (1 + Fee Percentage) × (1 + Tax Percentage)
The surcharge is now applied to both the Base Amount and the Premium Amount, and when configured as taxable, the surcharge tax is included in the final CC Total Amount. The CC Total Amount and CC Payment Amount now align with the calculation used during payment processing.
During payment entry, the user continues to enter the base payment amount (excluding surcharge). When the payment method is Credit Card, the system automatically applies the surcharge.
In addition, two new columns, CC Surcharge and CC Surcharge Tax, have been added to the rate grid in the Rate Terms subtab to display the surcharge amount and surcharge tax separately.
Rates > Rate Terms — CC Surcharge and CC Surcharge Tax columns Prerequisites:
The CreditCardSurcharge add-on must be activated.
Business Rule: Should the CC surcharge be applied on term/grace value only? (Subscriber Payments section) must be set to Yes.
Business Rule: What is the default percent to use for Cash Discount? (Subscriber Payments section) must be set to a value greater than 0.
(CM2-13038, CM44#1250 – CMO44#140) (CM2-13039, CM44#1260)
📄 Extracts
Expire Transactions Missing from expire_date.txt Extract for Grace Status Subscribers Expire transactions for subscribers in Grace status were not included in the expire_date.txt file of Subscribe Extracts when negative adjustments were applied for premiums or related transactions.
This occurred because the extract logic required both TranDate and ModifyDate to meet the export start date (ipdaExportStartDate) criteria. When a subscriber remained in Grace status for an extended period, the TranDate could fall outside the threshold, preventing the record from being included even when subsequent modifications were made.
This issue has been resolved.
The extract logic has been updated to include records where either TranDate or ModifyDate meets the ipdaExportStartDate criteria. This results in relevant modified expire transactions being included in the expire_date.txt extract.
(CM2-13165, CM44#1290)
💠 Circulation (Circ) API
Validation of AutoRenewTerm and AutoRenewLength in CircAPI CreateSubscription Previously, the CircAPI (CreateSubscription) allowed a subscription to be created even when an invalid or expired AutoRenewTerm or AutoRenewLength was specified for the publication.
This issue has been resolved. The CircAPI now validates AutoRenewTerm and AutoRenewLength values against the subscriber’s publication. Requests that include invalid or expired values now return an error, preventing the creation of incorrect subscriptions.
(CM2-12830, HM44#150)
Validation of AutoRenewTerm and AutoRenewBillingGroup in CircAPI Billing Change Previously, the CircAPI (billchange) allowed a Billing Change to be created even when an invalid or expired AutoRenewTerm or AutoRenewBillingGroup was assigned for the subscriber’s publication.
This issue has been resolved. The API now validates AutoRenewTerm and AutoRenewBillingGroup values against the subscriber’s publication. Requests that include invalid or expired values now return an error, preventing Billing Change creation.
(CM2-12849, HM44#160)
GetTax API Now Uses Subscriber Accounting Business Rules for Tax Determination Previously, the GetTax CircAPI determined taxability solely from the address information provided in the API request, even when publication-based taxing was configured.
This behavior has been updated. The GetTax CircAPI now evaluates taxability based on the configured answers to the applicable Business Rules.
Business Rule: Which address should be used for determining a subscriber’s taxability? (Subscriber Accounting section)
Subscriber: Tax is calculated using the subscriber address provided in the API request.
Publication: Tax is calculated using the publication address. Address values provided in the API request are not used.
Business Rule: If taxability is based on the publication address, must the subscriber live in the same state? (Subscriber Accounting section)
Yes Tax is applied only when the subscriber and publication are in the same state. Otherwise, the API returns zero tax.
No Tax is calculated using the publication address regardless of the subscriber’s state.
(CM2-12973, HM44#230)
🚀 Enhancements
💼 Accounting
Optional Addenda Record (Type 7) Support in ACH Bank Draft Export The ACH Bank Draft export file has been updated to optionally generate an Addenda Record (Type 7) for each Entry Detail Record (Type 6).
A new Business Rule has been introduced to control this behavior and allow additional payment-related information to be included in the export file.
Business Rule— Should an Addenda record be included in the standard ACH bank draft export file? (QuestionID: ACHAddendaRecord, Pymt Auth – General section) Default value: No
Yes:
Each Entry Detail Record (Type 6) is followed by a corresponding Addenda Record (Type 7).
Position 79 of the Entry Detail Record (Type 6) is set to 1, indicating that an Addenda Record (Type 7) follows.
The Addenda Record (Type 7) is generated with the following values:
Record Type Code: 7
Addenda Type Code: 05
Addenda Sequence Number: 0001
Entry Detail Sequence Number: Last seven digits of the associated Entry Detail Trace Number
The Free Form field is populated using the statement descriptor defined by the Business Rule— When using Naviga Pay, what statement descriptor should be used for auto payments? (Pymt Auth – General section). A maximum of 18 characters is accepted by this Business Rule, and only 18 characters are included in the ACH export file.
No:
Addenda Records (Type 7) are not generated.
The ACH export file continues to follow the existing structure and behavior.
Business Rule— ACHAddendaRecord (Pymt Auth – General section)
To ensure the ACH export file remains accurate when Addenda Records (Type 7) are included, the following changes apply:
Batch Header Record (Type 5):
Company Identification field (positions 41–50) is derived dynamically from the Bank Setup configuration associated with the ACH export file.
Batch Control Record (Type 8):
Entry/Addenda Count field (positions 05–10) includes the combined total of Entry Detail (Type 6) and Addenda (Type 7) records.
File Control Record (Type 9):
Entry/Addenda Count field (positions 14–21) includes the combined total of Entry Detail (Type 6) and Addenda (Type 7) records.
(CM2-12905, CM44#1210)
⚙️ Setup
Custom Payment Authorization Messages for ImpressPay In Setup > System > Pymt Auth Messages, custom messages can now be configured for approved and failed transactions when using the ImpressPay payment vendor.
The system introduces PaymentAuthorizationVendor and PaymentAuthorizationMessage records to replace vendor-supplied messages or blank responses. These records are used to display consistent transaction status messages.
(CM2-12170, CM44#370)
🏦 Payments
CustomerID Mapping Updated for Moneris Payments with CustomTags Enabled In NCS Circ, CustomerID mapping for Moneris payments has been updated when CustomTags is enabled (set to true). This update ensures that all required fields are included and mapped in the correct order for Moneris processing.
When CustomTags is enabled, the CustomerID is mapped as follows:
For Subscription Payments: ProductID | SubscriptionID | SubPaymentBatchID
For Carrier/Dealer Payments: CompanyID | AccountID | CashBatchID
This behavior applies only to Moneris payments when CustomTags is enabled. When CustomTags is disabled (set to false), the CustomerID continues to include only the Publication ID.
(CM2-12922, CM44#1150)
PayPal No Longer Supported as a Payment Source for Credit Card Payments through Payway Support for processing PayPal payments through Payway when PaymentType is set to Credit Card and Payment Source is PayPal has been removed. The system no longer accepts payment requests using this combination.
All previously introduced supporting logic has been reverted, and PayPal is no longer treated as a valid Payment Source for Credit Card payments.
(CM2-12980, HM44#220 – CM44#1180)
Tokenized Bank Draft Payment Support Across CircAPI and Customer Service APIs
Support has been added across multiple CircAPI and Customer Service API endpoints to process tokenized Bank Draft payments.
CircAPI CreateSubscription
The CircAPI CreateSubscription endpoint has been updated to support tokenized Bank Draft payments.
Subscription creation requests can now include offsite Bank Draft vault profile information, which is stored with the subscription to support auto-renewal processing.
The following Bank Draft parameters are now supported:
BDTokenID (Bank Draft Offsite Vault ID)
BDUniqueCustomerID (Bank Draft Offsite Customer ID)
These parameters follow the same validation rules as existing Credit Card profile fields.
For Payway Bank Draft payments, only BDTokenID is applicable.
(CM2-12977, HM44#170)
CircAPI Create Subscription by Campaign
The CircAPI Create Subscription by Campaign endpoint has been updated to support tokenized Bank Draft payments.
Campaign-based subscription creation requests can now include Bank Draft profile and payment information, enabling processing for both Auto Renewal and Single Payment transactions.
The following optional Bank Draft parameters are supported for Auto Renewal payments:
BDTokenID (Bank Draft Offsite Vault ID)
BDUniqueCustomerID (Bank Draft Offsite Customer ID)
The following optional Bank Draft parameters are supported for Single Payments:
BDPymtTokenID (Bank Draft Offsite Vault ID)
BDPymtUniqueCustomerID (Bank Draft Offsite Customer ID)
BDAuthNumber (Bank Draft Authorization Number)
BDTranID (Bank Draft Transaction ID)
These parameters follow the same validation rules as existing Credit Card profile and payment fields.
For Payway Bank Draft payments:
For Auto Renewal payments, only BDTokenID is applicable.
For Single Payments, only BDPymtTokenID, BDAuthNumber, and BDTranID are applicable.
(CM2-13019, HM44#250)
CircAPI CreatePayment
The CircAPI CreatePayment endpoint has been updated to support tokenized Bank Draft payments.
The API now accepts Bank Draft profile and payment details when submitting Bank Draft payment requests.
The following optional Bank Draft parameters are now supported:
BDTokenID (Bank Draft Offsite Vault ID)
BDUniqueCustomerID (Bank Draft Offsite Customer ID)
BDAuthNumber (Bank Draft Authorization Number)
BDTranID (Bank Draft Transaction ID)
These parameters follow the same validation rules as existing Credit Card payment fields.
When Bank Draft payment information is provided, the payment is validated through Naviga Pay and processed using the existing payment status workflow.
When these parameters are not provided, the system continues to process Bank Draft payments using the existing Bank Draft payment flow.
For Payway Bank Draft payments, only BDTokenID and BDTranID are applicable.
(CM2-12978, HM44#180 – CM44#1170 – CMO44#110)
CircAPI BillingChange
The CircAPI BillingChange endpoint has been updated to support tokenized Bank Draft payments.
Billing Change requests can now include optional Bank Draft profile information, which is stored with the subscription to support auto-renewal processing.
The following optional Bank Draft parameters are now supported:
BDTokenID (Bank Draft Offsite Vault ID)
BDUniqueCustomerID (Bank Draft Offsite Customer ID)
These parameters follow the same validation rules as existing Credit Card profile fields.
For Payway Bank Draft payments, only BDTokenID is applicable.
(CM2-12979, HM44#190)
CircAPI Billing Change by Campaign
The CircAPI Billing Change by Campaign endpoint has been updated to support tokenized Bank Draft payments.
Requests can now include Bank Draft profile information, which is stored with the subscription to support auto-renewal processing.
The following optional Bank Draft parameters are now supported:
BDTokenID (Bank Draft Offsite Vault ID)
BDUniqueCustomerID (Bank Draft Offsite Customer ID)
These parameters follow the same validation rules as existing Credit Card profile fields.
For Payway Bank Draft payments, only BDTokenID is applicable.
(CM2-13020, HM44#200)
Customer Service API – SinglePayment
The Customer Service API – Credit Card or Bank Draft Form Page (Single Payment) endpoint now supports tokenized Bank Draft payments.
Single payment requests can include offsite Bank Draft vault and payment information, enabling validation and processing through Naviga Pay.
The following optional Bank Draft parameters are now supported:
BDOffsiteCustomerID (Bank Draft Offsite Customer ID)
BDOffsiteVaultID (Bank Draft Offsite Vault ID)
BDAuthorizationNumber (Bank Draft Authorization Number)
BDTransactionID (Bank Draft Transaction ID)
These parameters follow the same validation rules as existing Credit Card payment fields.
When BDOffsiteVaultID and BDTransactionID are provided, the payment is treated as already captured. A payment record is created with a status of Settlement Pending, and the payment follows the existing Naviga Pay validation and settlement behavior.
When these parameters are not provided, the API continues to process the payment using the existing Bank Draft flow.
For Payway Bank Draft payments, only BDOffsiteVaultID and BDTransactionID are applicable.
(CM2-13021, CMO44#120)
Customer Service API – AutoPay
The Customer Service API – Credit Card or Bank Draft Form Page (Auto Renew) endpoint now supports tokenized Bank Draft payments.
Auto Pay requests can include offsite Bank Draft vault information to support profile storage and auto-renewal processing.
The following optional Bank Draft parameters are now supported:
BDOffsiteCustomerID (Bank Draft Offsite Customer ID)
BDOffsiteVaultID (Bank Draft Offsite Vault ID)
These parameters follow the same validation rules as existing Credit Card profile fields.
For Payway Bank Draft payments, only BDOffsiteVaultID is applicable.
(CM2-13022, CMO44#130)
Last updated