Subscriber Payments

  • 1. Should coupon only or adjustment only payments skip the step-up rating process? BCP (Client) Subscribers on promotional rates will step up to another rate when a payment is made (for example, a “DS half-off” promo might step up to a “DS regular” rate). However, if a payment with only an adjustment or coupon is entered (no payment amount), you may not want the payment to step up the subscriber’s rate. Enter “yes” here if the rate step-up should be skipped in cases where there is no payment amount.

    Value

    Yes

    The rates should not step up if the payment contains only a coupon or payment adjustment.

    No

    The rates should step up as normal even if the payment contains only a coupon or payment adjustment.

  • 2. Is a check number required for a subscriber payment? BCP (Client) Entry of a payment-related tracking ID or number for each subscriber payment entered may be required, if desired, using this rule. Entry of the tracking ID or number may always be required, never required, or optional at the discretion of the operator. Examples would be a check number for a payment by check.

    Value

    Always

    If entry of a payment-related tracking ID or check number for a subscriber payment should always be required.

    Never

    If entry of a payment-related tracking ID or number for a subscriber payment is never required. The Check Number field will not be active for entry if this option is selected.

    Optional

    If entry of a payment-related tracking ID or number for a subscriber payment is optional; it may be entered at the discretion of the operator.

  • 3. Is a source code required for a subscriber payment? B (Client) It may be desirable to require entry of a source code for each subscriber payment to reflect the general source of the payment.

    Value

    Yes

    If entry of a source code is required when a subscriber payment is entered.

    No

    If entry of a source code is optional when a subscriber payment is entered.

  • 4. What is the default source code for a subscriber payment? B (Client) The default source code assigned during subscriber payment entry may be set up here, if desired. This default may be overridden by the operator during subscriber payment entry.

  • 5. Is a reason code required for a subscriber payment? B (Client) Indicate here whether entry of a reason code should be required when a subscriber payment is entered.

    Value

    Yes

    If entry of a reason code should be required when a subscriber payment is entered.

    No

    If entry of a reason code should be optional when a subscriber payment is entered.

  • 6. What is the default reason code for a subscriber payment? B (Client) The default reason code assigned during subscriber payment entry may be set up here, if desired. This default may be overridden by the operator during subscriber payment entry.

  • 7. Which draw adjust code should be used when a subscriber payment converts from “Carrier Collect” to “Office Pay”? BCP (Client) When a carrier collect subscriber makes a payment to the office, a draw adjustment must be created to credit the carrier for any papers delivered since the start of the office pay period to the current publishing day. The user-defined draw adjustment code to be used for this type of draw adjustment should be entered here. This draw adjustment code must be set up in advance.

  • 8. How many days will you allow a subscriber payment to be backdated? BCPD (Client) It may be desirable to backdate subscriber payments if, for example, payments are made directly to a lock box and are received by the paper at a later date. Indicate here the maximum number of days a subscriber payment may be backdated. The default number of days is 5.

  • 9. What is the default bank for subscription payments? B (Client) The default bank is used during subscriber payment entry to define the bank on the payment batch screen. This default may be changed during payment entry. Enter the user-defined bank that is most commonly used for subscriber payment deposits.

  • 10. Should payments validate subscription and bank to company? B (Client) Indicate whether you want to verify that the bank’s company is the same company as the subscriber’s publication for subscriber payments, batch payments, payment imports and auto payments.

    Value

    Yes

    Payments will validate subscription and bank to company.

    No

    This validation will not be performed.

  • 11. Should customer service payments create separate payment batches by publication? P (Client) This setting determines whether payments for different publications should be in separate batches, or in one batch. If this rule is set to “yes”, payments will be separated into different batches by product. The description will be “<ProductID> Credit Card Pmts” or “<ProductID> <BankID> CustServPmts”. If this rule is set to “no”, all credit card payments will go into a single batch with a description of “Credit Card Pmts”, and all bank draft payments will go into a single batch with a description of “<BankID> Customer Service Pmts”.

    Value

    Yes

    Payments for different publications should be in separate batches.

    No

    All payments entered in Customer Services on a given day should be in one batch.

  • 12. Should a payment auto-start a former subscriber? BCP (Client) Circulation has an auto-start feature which will automatically start the subscription of a permanently stopped subscriber if a payment is received and entered into the database. You may elect to always have this automatically happen, to simply allow entry of the payment only, with the entry of the start as a separate step, or to not allow the payment to be entered. Note that in order for the auto-start to occur, the reason code for the subscriber’s stop transaction must also allow auto-starting.

    Value

    Always

    If the entry of a payment should automatically start the subscription of a former permanently stopped subscriber.

    Never

    If the entry of a payment is not allowed for a former permanently stopped subscriber without a start transaction for that subscriber having been previously entered.

    Take Payment Only

    If payment entry and subscription starts should be treated as two separate operations, perhaps performed by two different operators. The payment may be entered before or after the start transaction is entered, but the start transaction must be entered before the payment can be processed.

    If Always:

    • 13. When the grace payment percentage is defined at 100%, should subscriptions be automatically started? BCP (Client) If a payment is sent by a former subscriber with grace owed, a start will only be created if the payment pays a certain percentage of the grace, defined by the stop reason code. If a former subscriber sends a payment and the grace percentage for their stop reason code is 100%, this setting determines whether the subscriber will be auto-started. For example, you could define a stop reason code to be used only for subscriber who expire-stop at the end of their grace period; you could set the grace percentage for this reason code at 100% and set this rule to “no”, which would prevent these subscribers from auto-starting if a payment is sent.

      Value

      Yes

      Former subscribers should be auto-started if they send a payment and the grace percentage of their stop reason code is 100% (if the payment pays off all grace).

      No

      Former subscribers should not be auto-started if they send a payment and the grace percentage of their stop reason code is 100%.

  • 14. What is the reason code for subscriptions that are auto-started by payments? BCP (Client) This is the start reason code to be assigned when a subscription start is automatically created when a payment is entered.

  • 15. How many days old can the expire date be to default as the effective date for payment from a carrier collect sub? BCP (Client) When a payment is entered for a current carrier collect subscriber, the operator must specify the effective date of the office pay billing method change. If the effective date is prior to the last publishing date, draw adjustments will be generated for the carriers on the route so that they receive credit for delivery. If the subscriber was formerly an office pay subscriber (office pay subscribers may be turned over to carrier collect when their subscription expires for lack of payment), the previous expiration date may be defaulted as the effective date. This setting defines the time period which the old expiration date must fall in before it is defaulted. Otherwise, the batch date is used as the default effective date. For example, if the previous expiration date was 08/31 and a payment is entered 11/15, Business Rules would default to 08/31 as the effective date as long as the rules state that the number of days after expire was 76 or more. The default value is zero days. Note that if the subscriber was in grace prior to being turned over to carrier collect, the end grace date will be used rather than the expire date.

  • 16. Should subscriber lockbox files verify the scan line against the check digit? B (Client) The lockbox feature allows subscribers to send payments directly to a bank. The bank uses the renewal notice scan line to retrieve subscriber information. These payment transactions are periodically sent from the bank to the newspaper (on magnetic tape or other medium) and read by Circulation. The check digit is part of the scan line, and its purpose is to verify that the payment information is correct. Some banks can supply check digits, and others cannot.

    Value

    Yes

    The bank can supply the check digit (and so it should be verified).

    No

    The bank cannot supply the check digit and Circulation should not try to verify it.

  • 17. Should the bank number be validated during subscriber lockbox processing? BCP (Client) US banks have a standard formula for valid bank numbers. When lockbox payments are imported, Circulation will verify that the bank number is valid based on this formula, if this rule is set to “yes”.

    Value

    Yes

    The bank number should be verified against the US banking formula.

    No

    The bank number should not be verified.

  • 18. What subscription ID should be assigned to a payment when the supplied subscription ID is invalid? B (Client) This setting enables a valid subscription ID to be used as a default entry instead of zero in the event that the subscription ID in a lockbox file is invalid. The original subscription ID and the line number from the lockbox file will be written to the Remarks field in the payment transaction. The default setting is zero.

  • 19. What is the source code for payments created for credit card auto renewed subscriptions? BCP (Client) This defines the source code to be used for the credit card payments generated for auto renew subscriptions. The source code must be a valid source code.

  • 20. What is the reason code for payments created for credit card auto renewed subscriptions? BCP (Client) This defines the payment reason code to be used for the credit card payments generated for auto renew subscriptions. The reason code must be a valid reason code for a payment.

  • 21. What is the source code for payments created for bank draft auto renewed subscriptions? BCP (Client) This defines the source code to be used for the bank draft payments generated for auto renew subscriptions. The source code must be a valid source code.

  • 22. What is the reason code for payments created for bank draft auto renewed subscriptions? BCP (Client) This defines the reason code to be used for the bank draft payments generated for auto renew subscriptions. The reason code must be a valid reason code for a payment.

  • 23. What is the source code for payments created for PayPal auto renewed subscriptions? BCP (Client) This defines the source code to be used for the PayPal payments generated for auto renew subscriptions. The source code must be a valid source code.

  • 24. What is the reason code for payments created for PayPal auto renewed subscriptions? BCP (Client) This defines the reason code to be used for the PayPal payments generated for auto renew subscriptions. The reason code must be a valid reason code for a payment.

  • 25. Do you want to generate statements for auto renew subscribers? BCP (Client) Auto renew subscribers can receive statements, similar to renewal notices, summarizing subscriber activity. This setting determines what type of auto renew subscribers should receive statements: “credit card” (only credit card auto renews); “bank draft” (only bank draft auto renews); “both” (all auto renews); or “never” (no auto renew statements will be produced). If statements are to be produced, the auto renew information will be exported to an ASCII file when processing auto renews. The file can then be imported into word processing software to produce the statements.

    Value

    Bank Drafts

    Statements will be produced for bank draft auto renew subscribers only.

    Both

    Statements will be produced for all auto renew subscribers.

    Credit Cards

    Statements will be produced for credit card auto renew subscribers only.

    Never

    No auto renew statements will be produced.

  • 26. Which format should be used to create the auto renew statement export? BCP (Client) If you use file mapping for the auto renew statement export, select “File Map”. The default setting, “DTI Standard”, is the standard format.

If File Map:

  • 27. Which file map should be used to create the auto renew statement export when the file map format is selected? BCP (Client) If you set the Business Rule, Which format should be used to create the auto renew statement export?, to “File Map”, enter the name of the file map here. It must have a file map usage of “SubBilling”.

  • 28. Should auto renew payments include perm stopped subscribers with balances due? BCP (Client) Setting this rule to “yes” allows auto renew subscribers with a balance to request a final payment.

    Value

    Yes

    Auto renew subscribers may request a final payment.

    No

    Auto renew subscribers may not request a final payment.

  • 29. If a matching rate term cannot be found, should an auto renew payment be created? B (Client) This parameter determines what happens if there is no matching rate terms set up for an auto renew term and length.

    Value

    Yes

    The subscriber will still be included in the auto notice export and/or auto renew batch.

    No

    A message will be logged, and the subscriber will not be included in the auto notice export and/or auto renew batch.

  • 30. If no billing change is made, how many days should be skipped before a declined auto renew is selected again? BCP (Client) This setting controls the number of days after a credit card decline that a subscriber should once again be selected for auto renewal. The default is zero.

  • 31. How many auto renew declines without an accepted auto renew can a subscriber have before being removed from auto renew? BCP (Client) This Business Rule controls how many auto-renew payments can be declined before a subscriber is taken off auto renew, has their rate changed, and is included in the next subscriber billing process. It can be set to 0-99. If the answer is set to 0, a single auto renew decline will create a billing change to remove the subscriber from auto renew. If the answer is 1, two consecutive auto renew payment declines or cancellations are required create a billing change. If the answer is 999, then a billing change will never be created. The Cloud default is 0, and the on-premises default is 999.

  • 32. For payments that put a subscriber on credit card auto pay, which billing group should be assigned to the subscriber? BCP (Client)

  • 33. For payments that put a subscriber on bank draft auto pay, which billing group should be assigned to the subscriber? BCP (Client) When a system-generated billing transaction (such as a lockbox payment or renewal offer) changes a subscriber to automatic renewal, the subscriber must have an auto-renew billing group assigned. If more than one auto-renew billing group (defined in Setup) could apply to a subscriber, then the setting entered here will be used. Note: Separate Business Rules are used for credit card and bank draft auto renewals. The default is “All” for both of them.

  • 34. Do you allow alternate values in the credit card field? B (Client) This parameter determines whether you can store alternate credit card numbers (tokens) for subscriber payments. This is not the same as a vaulted token, but is an alternate number provided by a third party application such as ISD (Chatterbox) through the Customer Service API.

    Value

    Yes

    Alternate credit card numbers can be interfaced for subscriber payments.

    No

    Alternate credit card numbers are not used with subscriber payments.

    Note: If this Business Rule is changed to “Yes,” only credit card numbers with prefixes that match a CC Token Prefix code can be entered. See CC Token Prefix for more information.

  • 35. What is the subscriber adjust code used for storing subscriber credit card surcharges? BCP (NCS) If you add a small surcharge percentage to payments made by credit card to cover processing fees, specify the subscriber payment adjustment code to use for credit card surcharges here. Surcharges are currently only supported for Australian sites.

  • 36. To which system are you interfacing credit card payments? BCP (Non) Note:

    • All of the credit card interfaces require a separate license fee to use. Contact the Naviga Support Center for more information.

    Both regular and auto renew subscribers can make payments by credit card. You can optionally export credit card information to an ASCII file, which can then be imported to credit card distribution software.

    Value

    EdgCapture

    Credit card payments should be exported to an ASCII file in EdgCapture format.

    Edgil

    Credit card payments should be exported to an ASCII file in Payway Complete format. In order to select this option the Payway Complete add-on (a licensed option) must be installed.

    EIGEN

    Credit card payments should be exported to an ASCII file in the EIGEN format.

    ICVerify

    Credit card payments should be exported to an ASCII file in ICVerify format.

    None

    Credit card payments will not be interfaced.

    Paymentech

    Credit card payments should be exported to an ASCII file in Chase Paymentech format.

    PC Charge

    Credit card payments should be exported to an ASCII file in PC Charge format.

    POS-Partner 2000

    Credit card payments should be exported to an ASCII file in POS-Partner 2000 format.

    Skipjack

    Credit card payments should be exported to an ASCII file in Skipjack format.

    TrnsFirst TrnsCentrl

    Credit card payments should be exported to an ASCII file in TransFirst Transaction Central format.

    viaWarp

    Credit card payments should be exported to an ASCII file in viaWarp format.

    VirtualTerminal

    Account credit card payments should be exported to an ASCII file in Virtual Terminal format.

    VISANET

    Credit card payments should be exported to an ASCII file in VISANET format.

    If ICVerify:

    • 37. If exporting to ICVerify, should the credit card expire date be formatted MMYY or YYMM? BCP (Non) The credit card month and year may be required in different formats, depending on the ICVerify version.

      Value

      MMYY

      The month should be exported, then the year.

      YYMM

      The year should be exported, then the month.

    • 38. If exporting to ICVerify, how many blank fields should be at the end of each credit card payment? BCP (Non) This setting is used to handle version 3.1 of ICVerify. The trailing blanks after the payment record are not allowed in version 3.1. However, some sites need to use trailing blanks. Enter the number of trailing blanks that should be exported at the end of each payment record. The default on-premises answer is 14 (blank at Cloud sites).

    • 39. If exporting to ICVerify, is the ST field required in the output file? BCP (Non) The ICVerify system might require an “ST” field to denote the beginning of the close batch record. This setting determines whether “ST” is exported.

      Value

      Yes

      An “ST” field should be exported to the ICVerify file.

      No

      The “ST” field should be omitted from the export.

    • 40. If exporting to ICVerify and using the ST field, how many blank fields should follow the ST field? BCP (Non) This setting is used to handle version 3.1 of ICVerify. The trailing blanks after the ST record are not allowed in version 3.1. However, some sites need to use trailing blanks. Enter the number of trailing blanks that should be exported at the end of each ST record. The default is 21 for on-premises sites, and blank for Cloud sites. Note that not all sites use the ST field. If you have already indicated in Business Rules that you do not use the ST field, this setting will be ignored.

    • 41. If exporting to ICVerify, which export file format should be used? BCP (Non) If you use ICVerify, you can select “Retail” to use the original file format or “MOTO” to use the MOTO format. Otherwise, enter “None”.

      Value

      MOTO

      The MOTO format is used.

      None

      ICVerify is not used.

      Retail

      The original, retail format is used.

    If EIGEN:

    • 42. If you interface credit card payments to EIGEN, what is your term ID group? B (Non) This setting determines the term ID that is exported to the ASCII file interfaced to EIGEN.

    If VISANET:

    • 43. If you interface credit card payments to VISANET, what is your merchant ID? BCP (Non) The merchant ID is included in the VISANET export file.

    If POS-Partner 2000:

    • 44. If you interface credit card payments to POS-partner 2000, what is your V number? BCP (Non) Enter the V number.

    If Paymentech:

    • 45. If you interface credit card payments to Paymentech, what is your format version? BCP (Non) Enter the version number (defaults to “2_0_0”).

    • 46. If you interface credit card payments to Paymentech, what is your user name? BCP (Non) Enter your user name (defaults to [blank]).

for American Express:

  • 47. Should American Express credit card data be separately exported? BCP (Non) American Express credit card payments may be processed through a separate clearing house than other credit card types. In order to separate American Express payments from other credit card payments, carrier and subscriber payments with American Express (whether a single payment or an auto renew) may be sent to a separate file in /dti/exchange/cm. If Business Rules are set to export American Express payments separately, payments with credit cards other than American Express will go to the standard export file (ICVerify, Payway Complete, VISANET, etc.). American Express payments will be exported to their own file, rather than the standard file.

    Value

    Yes

    American Express credit card payments should be exported to a separate file.

    No

    American Express credit card payments should be exported with other credit card payments in the ICVerify, Payway Complete, VISANET, etc. file.

    If Yes:

    • 48. If you export credit card payments for American Express, what is your merchant ID? BCP (Non) The merchant ID is included in the American Express export file.

    If Edgil or EdgCapture:

    • 49. If you export payments using the Edgil/EdgCapture format, what is your merchant ID? BCP (Client) The merchant and OEP IDs defined here will be exported to the Edgil or EdgCapture file.

    • 50. If you export payments using the Edgil/EdgCapture format, what is your OEP ID (order entry process ID)? BCP (Client)

    • 51. If you export payments using the Edgil/EdgCapture format, what is your OEP ID for recurring (auto-pay) payments? BCP (Client)

    If Skipjack:

    • 52. If you interface credit card payments to Skipjack, what is your merchant serial number? BCP (Non) The merchant serial number is included in the Skipjack export file.

    • 53. Should the payment amount default from the previous payment in Subscriber Batch Payments? B (Client) Defaulting the amount from the previous payment can speed up payment entry, especially if you sort your payments by amount.

      Value

      Yes

      Payment amounts should default from the previous payment.

      No

      No payment amount should default.

  • 54. Are group payments applied only to subscriptions that have received a renewal notice but have not sent a payment? BC (Client) Group payments are payments spread across multiple subscriptions, all of which are billed to the same occupant. When entering group payments, all subscribers that have subscriptions billed to this occupant may be listed, or only office pay subscribers who have not made a payment for their last renewal, depending on how this rule is set.

    Value

    Yes

    Only subscriptions billed to the occupant that have not made a payment for their last renewal should be listed when entering group payments.

    No

    All subscriptions billed to the occupant should be listed when entering group payments.

  • 55. When entering a new group payment how should the payment amount be distributed? BC (Client) When entering a group payment, this setting governs whether the payment is initially split evenly among all subscriptions billed to the occupant, or whether each subscription begins with a zero amount.

    Value

    Automatic

    The payment should be automatically split among the subscriptions billed to the occupant.

    Manual

    No payment amounts should initially default for the subscriptions.

  • 56. Should refunds be made to credit card if most recent payment was by credit card? BCP (Client) When entering refunds, you indicate in the Credit Card field whether the refund should be to a credit card. If this setting is “yes”, Credit Card will default to “y” during refund entry if the subscriber’s most recent payment was by credit card. The credit card number and expiration date from the last payment will also be defaulted.

    Value

    Yes

    Refunds will default to credit card if the most recent payment was by credit card. Note that if refunds are being automatically selected (Selected Option is “All” or “Requested”), then refunds for expired credit cards will be treated as cash refunds instead of credit card refunds.

    No

    Refunds will not default to credit card.

  • 57. Should refunds be made to bank draft if most recent payment was by bank draft? BCP (Client) This setting works the same way as the previous Business Rule for credit cards.

    Value

    Yes

    Refunds should default to bank draft if the most recent payment was a bank draft.

    No

    Refunds will not default to bank draft.

  • 58. Should refunds be made to PayPal if most recent payment was by PayPal? BCP (Client) This setting works the same way as the previous Business Rules for credit cards and bank drafts.

    Value

    Yes

    Refunds should default to PayPal if the most recent payment was by PayPal.

    No

    Refunds will not default to PayPal.

  • 59. How should grace be paid off when a payment is received? BCP (Client) When a payment is processed for a subscriber with a grace owed transaction, the grace owed is subtracted from the payment, resulting in a grace paid transaction. This setting determines whether the grace paid is calculated using the dollar value of the grace owed, or the number of days in grace, and whether the grace paid is deducted from the payment before or after payment terms are found.

    Value

    Before Purchase

    If the grace owed amount should be deducted from the payment before the subscription terms are found. For example, if a subscriber sends in 21.00 for 13 weeks, and has 1.00 grace, the 20.00 remaining in the payment will not be enough to buy 13 weeks and so smaller terms will be bought. If you have term discounts (e.g. a 13 week term is a better deal than a 1 week term) this might result in a significantly shorter subscription period.

    After Purchase

    If the subscription terms should be found using the full payment amount. The grace amount will then be valued (using the rate the subscriber had while in grace) and the days deducted from the subscription period.

    Best Deal

    If the subscriber should receive the best deal. This works like “After Purchase”, except that the days valued by rating the grace amount are compared to the actual days the subscriber was in grace; whichever is the best deal for the subscriber (i.e. the lesser number of days) will be deducted from the subscription period.

    Best Deal if Rate Chg

    If the subscriber should receive the best deal, but only if the subscriber rate was changed via a billing change. The current rate will be used to value the grace amount. If there was no billing change, the “After Purchase” method will be used.

  • 60. If a payment is less than or equal to the subscriber's grace owed, should the grace period be extended? BCP (Client) This setting determines whether the end grace date is pushed back for a payment that does not buy a new subscription term (only pays off grace owed). If this rule is set to “yes”, the grace period will be extended by the number of days bought with the payment. A new expire transaction will also be created to reflect the new “paid through” date. This scenario is common if the newspaper has long grace periods but short subscription terms; subscribers can remain in grace indefinitely.

    Value

    Yes

    If the payment is less than or equal to the grace owed amount, extend the grace period.

    No

    Do not extend the grace period for payments less than or equal to the grace owed amount.

  • 61. Should payments with invalid rates be rerated during payment processing? BCP (Client) If a subscriber’s rate changes between the time a payment is entered and processed, the number of days bought by the payment (term and length) will most likely change. When this happens, the payment can either be rerated automatically by Payment Processing, or error out and require manual modification to reenter the term and length. This setting determines whether the automatic rerate method is used.

    Value

    Yes

    Payments that have a rate change between entry and processing should be automatically rerated, changing the term and length.

    No

    Payments that have a rate change between entry and processing should error out, requiring manual modification to set the term and length.

  • 62. What is the default payment type for subscription payments? BC (Client) This setting determines the payment type (cash, check, credit card or bank draft) that defaults when payments are entered in Customer Service or Batch Payment Entry.

    Value

    Cash

    The default payment type should be cash.

    Check

    The default payment type should be check.

    Credit Card

    The default payment type should be credit card.

    Bank Draft

    The default payment type should be bank draft. Use this setting only if the majority of your addresses are in the United States.

  • 63. What is the valid bank account type? BC (Client) Bank draft payments can be made to the subscriber’s savings or checking accounts, but only one of these bank account types may be valid at your newspaper. Indicate here whether bank drafts can be made to savings accounts, checking accounts, or both.

    Value

    Checking

    Bank draft payments can only be made to checking accounts.

    Savings

    Bank draft payments can only be made to savings accounts.

    All

    Bank draft payments can be made to both checking and savings accounts.

    None

    Bank draft is not a valid payment option.

  • 64. Should the bank client type be entered by the user? BC (Client) The bank client type indicates whether the bank account is a personal or business account. Client type information may or may not be required when entering a bank draft payment, depending on the policy of your newspaper. This setting governs whether the Client Type field is active when entering bank draft payments.

    Value

    Yes

    The client type should be supplied when entering bank draft payments.

    No

    The client type does not need to be supplied, and the field can be skipped.

  • 65. Should bank draft payments be exported using the Edgil/EdgCapture file format? BCP (Client) If your credit card payments are interfaced to an Edgil or EdgCapture system (as determined by the Business Rule, To which system are you interfacing credit card payments?, above), you may also include auto renew and one-time bank draft payments in the export. If so, enter “yes” here. Otherwise enter “no”.

    Value

    None

    Bank draft payments should not be interfaced with Edgil or EdgCapture.

    EdgCapture

    Bank draft payments should be included in the EdgCapture credit card export.

    Edgil

    Bank draft payments should be included in the Edgil credit card export.

  • 66. Should one-time bank draft payments be exported using the Intell-A-Check file format? BCP (Client)

    Value

    Yes

    One-time bank payments should be exported using the Intell-A-Check format.

    No

    One-time bank payments should not be exported using the Intell-A-Check format.

  • 67. If interfacing bank draft payments to Intell-A-Check, what text should be exported in the ‘Check Pay To Name’ field? BCP (Client) Enter the text be exported in the Check Pay To Name field for each bank draft payment. The text will be stored in the 40-character Check Pay To Name field in Intell-A-Check export files, which are created when batches of bank draft payments are accepted.

  • 68. For one-time bank draft payments, should a new batch be created daily? BCP (Client) This setting (when set to “no”) allows bank draft payments to be added to the most recent prior suspended bank draft payment batch. When set to “yes” (the default), a new payment batch will be created daily.

  • 69. Which subadjust code is used when exporting the NIE amount with BillServ Renewals? BCP (Client) If you generate renewal notices in the BillServ format, a subadjust code is required for NIE amounts. The code you enter here will be exported.

  • 70. How many days should be added to the payment date for cash/check payments imported through subscriber activity? B (Client) A predefined number of days can now be added to the payment date for cash or check payments imported via the Subscriber Activity Import, as governed by this setting. For example, if a check payment is imported with a payment date of 5/12, and this rule is set to “1”, the payment will be created in Circulation with a payment date of 5/13. The default is zero.

  • 71. What date should be used when creating route activity messages during payment processing? BCP (Client)

    Value

    Effective Date

    The effective date will be used.

    Publishing Date

    The publishing date will be used.

  • 72. Should batches that are imported or created by the system be accepted automatically? B (Client) This setting determines if system-generated or imported batches should be accepted automatically when running the Auto Accept Batches utility (see the User Manual). The default setting is “No.”

    Value

    Yes

    Imported batches should be accepted automatically by Auto Accept Batches.

    No

    Imported batches should not be accepted automatically by Auto Accept Batches.

    If Yes:

    • 73. Should payment batches containing one-time bank draft payments be auto accepted? B (Client) You can exclude one-time bank draft batches from being automatically accepted by setting this parameter is set to “No.”

      Value

      Yes

      One-time bank draft payments imported or created by the system should be automatically accepted when running Auto Accept Batches.

      No

      One-time bank draft payments will not be automatically accepted, but must be accepted in Batch Payments. This will allow bank draft payments for multiple days to be in the same payment batch.

  • 74. Do you allow payment batches with payments that have blank rates to be accepted? B (Client) Subscriber Lockbox Processing and the Subscriber Activity Import allow payments with blank rate codes. It is possible to enter an unroutable start, enter a payment for that start through Lockbox Processing or the Subscriber Activity Import, and accept the batch of payments. Payment Processing will not process the payment as long as the start remains unrouted. Once the start has been routed and that start has been processed through Transaction Processing, it is possible to run Payment Processing for the payment. The payment is re-rated using the subscriber's current rate.

    Value

    Yes

    Allow payment batches to be accepted if they contain payments with blank rates.

    No

    Do not allow payment batches to be accepted if they contain payments with blank rates.

  • 75. How many days must be purchased by an adjustment only payment before the number of renewals is reset? BCP (Client) This setting identifies the number of days an adjustment-only payment must purchase in order to reset the number of renewals sent to the subscriber. The default is zero.

  • 76. Should temp-stopped subscribers who are not in their grace period be selected for auto renew? BCP (Client) Temp stopped subscribers who are not in grace may be skipped from auto renew processing.

    Value

    Yes

    Temp-stopped subscribers are included in auto renew processing even if they are not in grace.

    No

    Temp-stopped subscribers are skipped in auto renew processing unless they are in grace.

  • 77. Should Auto Payments/Auto Notice be generated for Subscriptions with unprocessed Perm Stop on expire? Default Value: Yes This setting identifies whether Auto Payments or Auto Notice should be raised if there is a future Unprocessed Permanent Stop in the subscriber's Expire date. If the value is set to No, raising invoices or generating Auto-Renew Payments will be suppressed if the subscriber's Expire date has a future Unprocessed Permanent Stop.

  • 78. If a subscriber owes a fee, should an auto renew payment be increased to cover the fee? Default Value: No This setting determines whether to include the unpaid fee amount in the payment amount for a subscriber when processing AutoRenew payments.

Last updated

Logo

COPYRIGHT © 2024 NAVIGA