Generate Chart of Accounts (GCOA) | Contents | SCVs | Search | Glossary | Reports | Solutions | XML | Index | Working with Banks (WBNK) |
Purpose: Use the Pay Type table to:
• add or maintain payment methods and their descriptions
• specify an alternate refund pay type if your company allows you to change the method by which you refund the customer
• indicate the minimum dollar value and the maximum dollar amounts for which your company will produce a refund
• specify the characteristics of credit cards that your company accepts as a method of payment including the limits, if any, for reauthorizing a credit card order and the authorization and deposit services
• specify the financial conditions under which an order will go on hold (for example, dollar amount limits, balance due)
• assign offsetting General Ledger account numbers
• define the format for displaying credit card numbers for a Credit Card pay category pay type on screens and reports in CWSerenade
• specify the cross-reference for a ChannelAdvisor marketplace, so that orders originating in that marketplace are assigned the matching payment method, and specify whether to calculate tax and shipping at the item level or the order level.
Pay type versus pay category: A pay type defines a specific method of payment such as check, cash, Visa, Mastercard, American Express, coupon, or cash-on-delivery (COD), etc. Each pay type is assigned to a pay category.
Valid pay categories are:
• Cash/Check
• Credit Card (including stored value card and debit card)
• A/R
• COD
• Coupon/Credit
Pay categories group pay types with similar characteristics. For example, your company might accept Visa, Discover, and American Express. These are three distinct pay types that share at least one characteristic; they are all credit cards. You create three pay type records and assign all three pay types to pay category Credit Card.
Charging against pay types: When billing each pay type on a multi-paytype order, the system automatically assigns charge sequences to different payment categories as follows:
Payment Method |
Pay Category |
Default Charge Sequence |
Cash or check |
Cash/Check |
1 |
Gift certificate, coupon or merchandise credit |
Coupon/Credit |
1 |
Stored value card |
Credit Card |
2 |
Credit card (any Card type besides a stored value card) |
Credit Card |
3 |
Accounts receivable |
A/R |
4 |
C.O.D. |
COD |
4 |
In addition, the system assigns the charge sequence for the “catch-all” payment method the highest charge sequence. For example, if the charge sequence for a gift certificate is 10, the system updates the charge sequence for the credit card on the order to 11 (provided the credit card is the “catch-all”).
In this topic:
• Work with Pay Type G/L # Screen
• Which Cards are Eligible for Credit Card Number Formatting?
• Setting Up a Credit Card Number Format
• Creating a Default Credit Card Number Format
• Credit Card Number Format Examples
• Credit Card Number Layout Screen
Overview: CWSerenade supports different types of credit cards, indicated by the Card type setting. Valid types are listed below.
Credit Card Type/Description |
Typically Requires |
Credit card: A card, typically issued by a bank, that consumers can use to make purchases. The consumer pays the card issuer back on the issuer’s terms, which might require payment in full each month, or monthly installments against a variable balance. You can offer deferred or installment billing for a credit card, or you can simply deposit the payment amount promptly after shipment. Mastercard, VISA, American Express, and Discover Card are examples. |
credit card number (typically 16 positions) might also require: • expiration date • leading digits Additionally, you can define a Credit Card Number Format to specify which digits of a credit card number are masked on CWSerenade screens and reports using a special character. |
Debit card: A card issued by a bank that draws directly on the consumer’s account. Although a debit card often bears the Mastercard or VISA logo like a credit card, it is restricted to the consumer’s current balance or line of credit with the bank. A Switch card is a type of debit card offered in the United Kingdom. |
credit card number (can be up to 20 positions) expiration date might also require start date or issue number Additionally, you can define a Credit Card Number Format to specify which digits of a debit card number are masked on CWSerenade screens and reports using a special character. |
Stored value card: A gift card containing a pre-paid dollar amount that consumers can use to make purchases. Before a customer can use a stored value card as payment, the card must be activated by the service bureau. You can also inquire on the remaining balance on the card during order entry and maintenance. |
stored value card (credit card) number Additionally, you can define a Credit Card Number Format to specify which digits of a stored value card number are masked on CWSerenade screens and reports using a special character. |
Direct bank disbursement: A customer’s bank draws the funds for a purchase directly from the customer’s account. Although similar in some ways to a debit card, a direct bank disbursement does not require authorization. For more information: See Processing Direct Bank Disbursements for an overview and additional setup. Note: An integration between CWSerenade and a bank system is not currently implemented. |
routing number account number Note: Although credit card number is still required, this field is informational only for this pay type, and is automatically populated with the pay type description, such as DIRECT BANK DEBIT. You cannot apply a Credit Card Number Format to a direct bank disbursement card type. |
PayPal: Draws funds from a PayPal account over the Internet. Note: CWSerenade supports a PayPal integration using Cardinal Commerce as its service bureau or a direct connection to PayPal during deposit processing.
See the following for an overview and required setup for each type of integration: |
credit card number reauthorization days authorization service deposit service Note: If you are using the PayPal - Cardinal Commerce integration, enter the Cardinal Commerce service bureau as the authorization service and deposit service. If you are using the PayPal - Direct Connection integration, enter PPL as the authorization service and deposit service. |
On Account: An Accounts Receivable payment method that uses an external A/R system to process the payment. Customer and order information is sent to the external A/R system in the Authorization Request XML Message (CWAuthorizationRequest). See A/R Payment Processing Using an External System for an overview and the required setup. |
credit card number (the system populates the credit card number with the text defined in the Prefix Value for On Account Card Type (L14) system control value + the bill to customer number or sold to customer number (if a bill to is not defined) on the order. authorization service deposit service Note: For this pay type to function as an on account pay type, leave the following fields unselected: credit card length modulus check require start date require expiration date require issue # |
About deferred and installment billing: You cannot use deferred or installment billing for any credit card pay type except for a regular credit card. To avoid having the system prompt you to select a payment plan in order entry, or to have the payment plan applied automatically, for other credit card types, you should set up payment plans to use a specific pay type, such as Mastercard or VISA. See Working with Flexible Payment Options (WFPO) for more information on setting up payment plans for deferred and installment billing.
Important: Bill Me Later processing is not currently implemented.
Overview: Bill Me Later is a payment method, offered by I4Commerce, in which the customer can set up an account with the issuer interactively during order creation and pay later for the purchase using this account. When first creating the account, you need to disclose the payment terms and conditions to the customer.
Setting up the Bill Me Later Account
When a customer first selects the Bill Me Later pay type as the payment method on the order, the system requires the following information:
• social security number: only the last four digits are required if the order total does not exceed the BML threshold; otherwise, the entire social security number is required
• date of birth: you must enter the entire eight positions of the date of birth in MMDDYYYY format
• terms and conditions: you define default codes for this pay type to identify the terms and conditions as they are disclosed to the customer. You can specify different codes for orders you create through regular order entry as opposed to orders created through the generic order API. You can override the default terms and conditions code on generic order API orders, while the terms and conditions code is not visible in regular order entry.
In Regular Order Entry
The system fills the Credit card number field on the Order Payment Method record with the description of the pay type, such as BILL ME LATER, and sets the Expiration date to 0000. This is the information that displays on screen for the payment method in order entry and at the Display Customer Order History Screen.
The customer must supply the date of birth and social security number, as described above.
Note: If you use Bill Me Later, it is necessary to enter all items on the order before entering payment information, in order for the system to compare the order total with the BML threshold and determine whether to require the full social security number.
The system always uses the BML T&C (terms and conditions) version (call center) for orders created through regular order entry, even if the order type matches the E-Commerce Order Type (G42).
If the order total exceeds the BML trans limit, the customer cannot use a Bill Me Later pay type when initially setting up the account; however, this limit does not apply to subsequent orders once the account has been established.
The system stores the customer’s social security number and date of birth in the Customer Sold To BML table until you send the information out for authorization.
Initial Authorization
When you submit a customer’s initial Bill Me Later payment method for authorization, the information sent to I4Commerce includes:
• social security number
• date of birth
• flag indicating that the Method of payment is Bill Me Later (BL)
• BML default account # specified for the pay type
• terms and condition code from the Customer Sold To BML table, which comes from the BML T&C (terms and conditions) version (call center) (if you entered the order in order entry) or the BML T&C (terms and conditions) version (web site) (if the order originated on your web storefront or through the Inbound Order Message, and the message did not include an alternate T&C code)
• ship-to name and address information
• total shipping cost
If I4Commerce sends back an approval, the system authorizes the payment method and updates the Customer Sold To BML table as follows:
• deletes the social security number and date of birth
• replaces the BML default account # with the account number provided by I4Commerce. This account number is not provided to the customer, although you can review it at the Display Customer Order History Screen in customer maintenance. Also, once you ship and bill the order, you can review the account number at the Display Invoice Pay Method Screen (Reviewing Deposit Information) in standard order inquiry; however, the pay type description is still stored as the credit card number in the Order Payment Method table and the Customer Sold To Order History table.
See Processing Authorizations and Deposits using CWIntegrate for more information on processing authorizations for a Bill Me Later pay type.
If the customer is initially declined: If I4Commerce does not approve the Bill Me Later payment method when the customer is first attempting to establish an account, the system deletes the Customer Sold To BML record and puts the order on hold. You can call the customer to confirm the social security number and date or birth, or request another payment method.
Using the Bill Me Later Pay Type
Once the customer has established a Bill Me Later account, the process of using the pay type on subsequent orders in regular order entry is similar to that used in establishing the initial account, i.e:
• again, the customer must provide the partial social security number and the date of birth; however, the system does not consider the BML threshold or the BML trans limit
• the system updates the Customer Sold To BML table with the social security number and date of birth
• when submitting the order for authorization, the system sends the same information described above to I4Commerce, except that it now sends the actual account number from the Customer Sold To BML table
• when I4Commerce authorizes the pay type, it sends the same information back, and the system makes the same updates to the Customer Sold To BML table. It is possible that the information sent from I4Commerce might include a new BML account number, which would replace the existing number.
Express bill orders: You cannot express bill an order that includes a Bill Me Later pay type.
If the Bill Me Later payment method is declined after the account is established: If I4Commerce declines to authorize the payment method on a subsequent order after establishing the Bill Me Later account, the system deletes the social security number and date of birth from the Customer Sold To BML table and puts the order on hold. You can call the customer to confirm the social security number and date or birth, or request another payment method.
When you reject an order: When you reject an order during entry, the system:
• clears the social security number and date of birth from the Customer Sold To BML table if the customer has already established an account
• deletes the Customer Sold To BML record if the customer has not already established an account (that is, the Account # field is blank)
Because the system deletes the Customer Sold To BML record if the Account # is blank, it is possible that an order could fail authorization if, for example, you:
1. Receive an order from the web storefront with an initial Bill Me Later payment method
2. Before this order is submitted for authorization, begin entry of another order for the same customer, also using a Bill Me Later payment method
3. Reject the second order
Note: When you reject a suspended order in a batch, the system does not delete the Customer Sold To BML record.
Generic order interface: The generic order interface is not subject to the BML threshold when determining whether to require the full 9 digits of the social security number; such orders will not be in error if only the last four digits of the social security number are included in the message. However, the BML trans limit is enforced: if the order value exceeds this limit, the order will be in error with a reason of Bill Me Later trans limit. Also, if the customer does not already have an account number established, the customer’s date of birth and last four digits of the social security number are required; otherwise, the order will be in error with a reason of Invalid date of birth or Invalid social security number.
When creating new orders through the generic order interface, the message can specify an override to the BML T&C (terms and conditions) version (web site); otherwise, the default specified for the pay type is used to update the Customer Sold To BML table.
Restrictions
The following restrictions exist for a Bill Me Later pay type:
• About membership orders: The system deletes the social security number and date of birth after each authorization response, so this information is not available to send to I4Commerce for any membership order created through Generating Membership Orders (EGMO) that uses a Bill Me Later payment method. Contact I4Commerce to determine whether you can use a Bill Me Later pay type on membership orders.
• Deferred or installment billing: You cannot use deferred or installment billing with Bill Me Later. See Working with Flexible Payment Options (WFPO) for more information on setting up payment plans for deferred and installment billing.
Setting up a Bill Me Later Pay Type for Promotions
You can offer promotional pricing to customers that sign up for a Bill Me Later account. When you process a Bill Me Later transaction that is assigned a promotion code, the system defaults a division code to the transaction that indicates a promotion has been assigned to the order.
In order to default the correct Bill Me Later division code to a transaction sent to I4Commerce via the cw_paymentech site in CWIntegrate, you will need to create at least 4 Bill Me later pay types in CWSerenade:
• 1 pay type for web orders that are eligible for a Bill Me Later promotion.
• 1 pay type for web orders that are not eligible for a Bill Me Later promotion.
• 1 pay type for non-web orders that are eligible for a Bill Me Later promotion.
• 1 pay type for non-web orders that are not eligible for a Bill Me Later promotion.
Example:
Paytype |
Channel |
Promotion? |
Results |
B1 |
web |
no |
For pay type B1 and the web order channel, the system defaults division code 078947 (non-promotion division) to the transaction. |
B9 |
web |
yes |
For pay type B9 and the web order channel, the system defaults division code 078946 (promotion division) to the transaction. |
BN |
regular |
no |
For pay type BN and the regular order channel, the system defaults division code 078947 (promotion division) to the transaction. |
BP |
regular |
yes |
For pay type BP and the regular order channel, the system defaults division code 078946 (non-promotion division) to the transaction. |
Communicating with I4Commerce
Communication with I4Commerce is currently supported through the cw_paymentech site in CWIntegrate. See Processing Authorizations and Deposits using CWIntegrate and the CWIntegrate Paymentech Integration reference for more information on processing authorizations via CWIntegrate.
How to display this screen: Enter WPAY in the Fast path field at the top of any menu or select Work with Pay Types from a menu.
Field |
Description |
Type |
A code that represents the pay type. Numeric, 2 positions; optional. |
The description of the pay type. Alphanumeric, 30 positions; optional. |
|
A code for a category of pay type. Valid values: • Cash/Check • Credit Card (including stored value card and debit card) • A/R • COD • Coupon/Credit Optional. |
Screen Option |
Procedure |
Create a pay type code |
Select Create to advance to the Create Pay Type Screen. |
Change pay type information |
Select Change for a pay type to advance to the Change Pay Type screen. At this screen you can change any information except the pay type code. See the Create Pay Type Screen for field descriptions. |
Delete pay type information |
Select Delete for a pay type to delete it. |
Select Display for a pay type to advance to the Display Pay Type screen. You cannot update any information on this screen. See Create Pay Type Screen for field descriptions. |
|
Work with general ledger numbers |
Select Work with G/L#’s for a pay type to advance to the Work with Pay Type G/L # Screen. |
Work with credit card number format |
Select CC # Format for a Credit Card pay category pay type to advance to the Credit Card Number Format. An error message indicates if the pay type is not a Credit Card pay category pay type: Not available for this pay type. |
Work with user defined fields |
Select User Field for a pay type to advance to the Work with User Fields Screen. |
Purpose: Use this screen to create a pay type code.
How to display this screen: At the Work with Pay Types Screen, select Create.
Field |
Description |
Pay type |
A code that represents a pay type, such as a check, VISA card, American Express card, COD, Accounts Receivable, or Gift Card. Numeric, 2 positions. Create screen: required. Change screen: display-only. |
Desc (Description) |
The description of the pay type. Alphanumeric, 30 positions; required. |
Category |
The category of the pay type. Valid values are: • Cash/Check • Credit Card (including stored value card and debit card). • A/R • COD • Coupon/Credit Required. |
The pay type to use for refunds to this pay type. Complete this field only if the pay type for refunds is different from the pay type used on the order. Example: If the customer uses COD when purchasing, you probably issue a refund check. The system checks the appropriate values defined for the alternate refund pay type, not the original pay type, when generating refunds. For example, if you define an alternate refund type of a check for a COD pay type, the system checks the refund check minimum you have defined for the check pay type when determining whether to create a refund for a COD order. The three related fields are the Ref chk min (Refund check minimum), Ref chk max (Refund check maximum), and the Release days. The alternate refund type must be a pay category of Cash/Check, A/R, Coupon/Credit, or Credit Card for Card type Stored Value. The system displays an error message if you enter an invalid alternate refund type: Only SVC pay type OR alt pay category of A/R, Coupon, or Cash/Check allowed. If the Use CC Net Exchange Billing (M23) system control value is selected, you cannot define an Alternate refund type or Alternate refund category for a Credit Card Pay type category pay type; the system displays an error message: Alt refund type/category not allowed with CC Net Exchange Billing. Numeric, 2 positions; optional. |
|
The pay category to which the system-generated refund can be charged during refund maintenance. Valid values are: • Cash/Check • Credit Card (including stored value card and debit card) • A/R • COD • Coupon/Credit When you define an alternate refund category for a pay type, you give yourself the option of changing the refund to the type that corresponds to this category. For example, you can define a coupon/credit alternate refund category for a cash/check pay type. In this case, the system automatically generates a refund check, but you can change the refund to a merchandise credit or stored value card credit through the Change Refund Screen. The alternate refund category must be a pay category of Cash/Check, A/R, or Coupon/Credit. The system displays an error message if you enter an invalid alternate refund category: Alternate pay type category must be A/R, Coupon, or Cash/Check. If the Use CC Net Exchange Billing (M23) system control value is selected, you cannot define an Alternate refund type or Alternate refund category for a Credit Card Pay type category pay type; the system displays an error message: Alt refund type/category not allowed with CC Net Exchange Billing. Required for COD pay types; otherwise, optional. |
|
Authorization service |
A code for the service bureau that authorizes or declines credit card charges. Alphanumeric, 3 positions; optional. |
Credit card length |
The required length of the credit card number. You can require any length up to 20 positions. Note: The system does not validate the credit card length if you enter a 0 in this field. Numeric, 2 positions; optional. |
Deposit service |
A code for the service bureau that performs credit card deposits for this pay type. Alphanumeric, 3 positions; optional. |
Leading digits |
The first digits numbers of a valid credit card number. For example, the first two digits in a Master Card account number are 5 and 4. You can enter up to 4 leading digits. Numeric, 4 positions; optional. |
The number of days before a credit card authorization expires. Numeric, 3 positions; optional. |
|
Modulus check |
This setting indicates if the system performs a calculation against the digits of the credit card number to ensure that the card is valid. Valid values are: • Modulus 10 = for a modulus 10 check • Modulus 11 = for a modulus 11 check • Modulus User Defined = for a user-defined modulus check • blank = no modulus check is performed If you enter MU in this field, the system uses the program name from the User Defined Modulus Check Program (E94) system control value. An error message indicates if a program name has not been defined: Modulus check program has not been specified for SCV E94. Note: The system cannot perform a modulus check against the number if the number includes spaces; for example: 4111 1111 1111 1111. To perform a modulus check, you must enter the number without any spaces between the numbers; for example: 4111111111111111. Optional. |
Indicates whether to require a start date when the customer uses this credit card pay type. For example, you might use a start date for a debit card to indicate the first date when the card is effective. If a start date is required but not entered, the system displays an error message in order entry or maintenance: Credit card start date (0) is not valid. The start date is a four-position date in MMYY format, similar to the expiration date. Select this flag if you want to require a start date for this pay type. This is a valid selection only if the pay type is a credit card. Do not select this field if you do not want to require a start date for the pay type. |
|
|
Note: • Even if you require a start date for a pay type, the system does not validate the credit card based on whether the start date is before or after the current date. Typically, if your authorization service requires a start date for this pay type, the service would validate the start date provided against the current date. • Debit cards might require a start date, an issue number, both, or neither. Even if a start date or an issue date are not required, you can still enter this information in order entry if it is available. • If you require the start date for any credit card type besides a debit card, you will not be able to enter the start date at the recap screen in order entry. Instead, you should advance to the Enter Payment Method screen, where all pay type fields are available for entry. However, if the pay type is a debit card, the system displays a pop-up window from the order recap screen for you to enter additional information such as the issue number and start date, regardless of whether these fields are required. |
Indicates the type of credit card. Valid values are: • Bill Me Later: (bill me later account; not currently implemented • Credit: Credit card • Debit: Debit card • Direct Bank Disbursement: Direct Bank Disbursement (see Processing Direct Bank Disbursements) • On Account: A/R On Account using external service • Stored Value: Stored Value Card (see Stored Value Card Overview and Setup) The card type is required for a credit card pay type (pay category = Credit Card). You cannot enter a card type for any other pay category. See Types of Credit Cards for an overview. You can define a credit card number format to specify how the credit card number should display on CWSerenade screens and reports; see Credit Card Number Format for instructions. Required for Credit Card pay category pay types. |
|
Indicates whether to require an expiration date when the customer uses this credit card pay type. Expiration dates are typically required for regular credit cards, but might not be required for stored value cards, for example. If an expiration date is required but not entered, the system displays an error message in order entry or maintenance: Credit card expiration date (0) is not valid. The expiration date is a four-position date in MMYY format. • Select this flag if you want to require an expiration date for this pay type. This is a valid selection only if the pay type is a credit card (pay category = Credit Card). • Leave this field blank if you do not want to require an expiration date for the pay type. |
|
Send reversal |
Used by the REVERSE Send Reversals for Expired Authorizations periodic function to determine if open Authorization History records for this pay type should be included in the REVERSE periodic function authorization reversal process. • Select this field to include open Authorization History records for this pay type in the REVERSE periodic function authorization reversal process. • Unselect this field to exclude open Authorization History records for this pay type from the REVERSE periodic function authorization reversal process. |
Indicates whether to require an issue number when the customer uses this credit card pay type. Some banks assign an incremental issue number when they replace a card because it is lost or stolen. Select this flag if you want to require an issue number for this pay type. This is a valid selection only if the pay type is a credit card. Do not select this flag if you do not want to require an issue number for the pay type. If an issue number is required but not entered in order entry or order maintenance, the system displays an error message: Credit card issue# () is not valid. |
|
|
Note: • Debit cards might require a start date, an issue number, both, or neither. Even if a start date or an issue date are not required, you can still enter this information in order entry if it is available. • If you require the issue number for any credit card type besides a debit card, you will not be able to enter the issue number at the recap screen in order entry. Instead, you should advance to the Enter Payment Method screen, where all pay type fields are available for entry. However, if the pay type is a debit card, the system displays a pop-up window from the order recap screen for you to enter additional information such as the issue number and start date, regardless of whether the issue number or start date are required. |
If a customer short pays an order by an amount equal to or greater than this amount, the system places the order automatically on BD (Balance Due) hold. Note: Orders are evaluated for Bal due $ limit (Balance due dollar limit) and Bal due % limit (Balance due percentage limit). Balance due % limit takes precedence over balance due $ limit, so the system puts the order on hold when it is underpaid by the percentage even if it not underpaid by the dollar amount. When you apply a cash/check payment method: • If there is a Bal due % limit specified, and the order is underpaid by this percentage, put the order on hold; otherwise, • If there is a Bal due $ limit specified, and the order is underpaid by this amount, put the order on hold; otherwise, • Do not put the order on hold for an underpayment. Example: A customer underpays a $1,250.00 order by $25.00. The Balance due $ limit is $5.00; however, the Balance due % limit is 5%. Five percent of this order is $62.50. This order will not go on hold. The customer has underpaid by more than the Balance due $ limit but less than the Balance due % limit. Note: If the underpaid amount is less than the amount specified here (and there is no Bal due % limit specified), the order does not go on hold. The system creates a balance due record (negative refund record) and puts this record into a write-off pending status. These refund write-off amounts accumulate for the sold-to customer, and can be applied to a subsequent order as an additional charge. The Default Additional Charge Code (C45) to be used in these instances is specified in the System Control table. Numeric, 9 positions with a 2-place decimal; optional. |
|
If the order total meets or exceeds this dollar amount, the system places the order on dollar hold, regardless of the pay category (A/R, cash/check, C.O.D., coupon/ credit, or credit card). Multi-pay orders: If there is more than one payment method on the order, the system places the order on hold if the order total meets or exceeds the Order $ limit for any pay type. Example: The order total is $200.00, and the customer sends a $50.00 check and puts the balance on a credit card. The Order $ limit for the check pay type is $150.00, and the Order $ limit for the credit card is $250.00. The system places the order on hold, because the order total of $200.00 meets or exceeds the Order $ limit of $150.00 for the check pay type (even though the check payment amount is less than the Order $ limit). |
|
|
Cash/check orders: The system evaluates both Order $ limit and Hold days. Order $ limit takes priority over Hold days. Example: The order total is $350.00 and the customer pays by check. Order $ limit is $225.00; Hold days is 5. Six days pass; this order will still be on hold. This customer order meets the value specified in Hold days but still exceeds the Order $ limit specified in this table. The system does not check this setting if: • the order is already on any type of system hold • an authorization service has been defined for this payment type; instead, the system places the order payment method automatically on CW (credit wait) hold Numeric, 9 positions with a 2-place decimal; optional. |
If a customer underpays on an order by a percentage equal to or greater than this amount, the system places the order on hold. Note: Orders are evaluated for both Bal due $ limit (Balance due dollar limit) and Balance due % limit. Balance due % limit takes priority over balance due $ limit. See the Bal due $ limit (Balance due dollar limit) for a discussion. Numeric, 9 positions with a 2-place decimal; optional. |
|
The number of days to hold an order while waiting for a check to clear the bank. The system releases the order from hold automatically through Daily Periodic Processing once the number specified here has passed. Note: Cash/check orders are evaluated for both Order $ limit (Order dollar limit) and Hold days. Order $ limit takes priority over Hold days. Numeric, 3 positions; optional. |
|
The minimum dollar amount for which you issue a refund. Refunds less than this amount are put in a write-off pending status. These write-off amounts accumulate in the Customer Sold-to table and can be used as an order credit on a subsequent order. The Default Cash Pay Type (C07) to be used in these instances is indicated in the System Control table. If a pay type has an alternate refund type, the system checks the refund check minimum for the alternate refund type. Numeric, 9 positions with a 2-place decimal; optional. |
|
The maximum dollar amount for automatic refund creation. Any refund exceeding this dollar amount is put on hold. For example, if you leave this field blank for a credit card alternate refund type, all refunds will go on hold because they exceed the blank (zero) amount. If a pay type has an alternate refund type, the system checks the refund check minimum for the alternate refund type. Note: The system will process refunds exceeding the refund check maximum amount if the Process A/R Credits Immediately (E80) system control value is selected. Numeric, 9 positions with a 2-place decimal; optional. |
|
The number of days to hold a refund from processing. The system changes the status of the refund to “open” when you process the refund if the release days have passed. This feature ensures that the customer's check for the order clears before you print a refund check for the overpayment. If a pay type has an alternate refund type, the system checks the refund check minimum for the alternate refund type. Numeric, 3 positions; optional. |
|
This field is not currently implemented. Indicates the total dollar value that triggers the requirement of the customer’s full social security number, rather than just the last four positions, when first creating a Bill Me Later account for a customer. For example, if you set this value to 100.00, when a customer’s order totals: • less than $100.00: only the last four positions of the social security number is required. The first five positions are not enterable. • more than $100.00: the full social security number is required Note: This threshold is not enforced for orders you receive through the Generic Order Interface (Order API). For more information: See Bill Me Later Processing. Numeric, 9 positions with a 2-place decimal; optional. |
|
This field is not currently implemented. A code indicating the Bill Me Later terms and conditions information that you provide to customers who create a Bill Me Later account through regular order entry, as opposed to orders you receive from the web storefront. The system always uses this terms and condition code for orders created through regular order entry, even if the order type matches the E-Commerce Order Type (G42). See Bill Me Later Processing. Numeric, 5 positions; optional. Required for a Bill Me Later pay type (the Card type is B). |
|
This field is not currently implemented. Indicates the maximum order value to accept when first creating a Bill Me Later account for a customer. For example, if you set this value to 500.00, you cannot create a Bill Me Later account for a customer if the order total is greater than $500.00. See Bill Me Later Processing. Numeric, 9 positions with a 2-place decimal; optional. Required for a Bill Me Later pay type (the Card type is Bill Me Later). |
|
This field is not currently implemented. A code indicating the Bill Me Later terms and conditions information that you provide to customers who create a Bill Me Later account through the web storefront. If the Inbound Order XML Message (CWORDERIN) (generic order interface) specifies a terms and conditions code, it overrides this default. See Bill Me Later Processing. Numeric, 5 positions; optional. Required for a Bill Me Later pay type (the Card type is Bill Me Later). |
|
This field is not currently implemented. The default account number to assign to customers when first creating a Bill Me Later account. Typically, this value should be set to 5049900000000000. The only purpose of this account number is for the system to send to I4Commerce in the authorization message, indicating to create a new Bill Me Later account. See Bill Me Later Processing. Numeric, 20 positions; optional. Required for a Bill Me Later pay type (the Card type is Bill Me Later). |
|
Store tender |
A cross-reference to the corresponding tender code in a point-of-sale system such as WinRetail. This field is available only if you specify a Default Location for Sales Download (K69). Alphanumeric, 4 positions; optional. |
A cross-reference to a ChannelAdvisor marketplace, set up through Working with ChannelAdvisor Integration Offers (WCAO), from which you receive orders: • If the CAORDUP periodic function creates an order from ChannelAdvisor, and the ItemSaleSource passed for the order matches this cross-reference, the periodic function assigns this payment method to the order. Your marketplace needs to match a ChannelAdvisor Site Token value. • If an order has a payment method whose cross-reference matches a ChannelAdvisor marketplace and also matches the ChannelAdvisor Order Type (L90), the Processing Refunds (MREF) option submits any pending refunds for the order to ChannelAdvisor, and does not actually generate the refund. If more than one pay type has the same matching cross-reference, the periodic function selects the pay type with the highest pay type code. Cash/check category: If a CA cross reference # is specified, the pay type Category must be Cash/Check. For more information: See ChannelAdvisor Integration Overview and ChannelAdvisor Setup. This field is available only if the ChannelAdvisor Order Type (L90) system control value specifies an order type. If you enter a value in this field, then the CA type field is required. Alphanumeric, 40 positions; optional. |
|
Controls how the CAORDUP periodic function calculates shipping and tax, and how refund amounts are passed when Submitting Refunds for ChannelAdvisor Orders. If this field is set to: • Item Level or blank = Consistent with the Amazon and eBay with premium tax marketplaces: • the CAORDUP periodic function calculates shipping and tax based on the amounts in the OrderLineItemItem element • refund processing calculates tax and shipping at the item level and passes these amounts in the RefundItem level in the SubmitOrderRefund message • Order Level = Consistent with the eBay marketplace (without premium tax): • the CAORDUP periodic function uses the tax and shipping amounts from the OrderLineItemInvoice element and prorates them across the lines on the order • the SubmitOrderRefund message specifies amounts at the order level This field is available only if the ChannelAdvisor Order Type (L90) system control value specifies an order type. If a CA cross reference # is specified for the pay type, then this field is required. |
Work with Pay Type G/L # Screen
Purpose: Use this screen to select or change general ledger account numbers used to post transactions for a pay type.
How to display this screen: Select Work with G/L#’s for a pay type at the Work with Pay Types Screen.
Transaction types: The transaction types you can associate with G/L account numbers are displayed on this screen.
They are:
• Bonus
• Cancel
• Refund
• Return/Deferred
• Return/Installment
• Contribution
• Return
• Sale
• Sale/Deferred
• Sale/Installment
• Write off
G/L account number: The G/L account number (G/L Acct#) to use for posting a transaction type to the general ledger displays to the right of the transaction type. A 0 displays if no G/L number has been defined.
Note: Not all transaction types are appropriate for each pay type. A contribution, for example, is a valid transaction only for a prepaid pay type (payment category 1). However, the system does not validate whether the transaction type for a payment category requires a G/L number.
The G/L account number is an 8-position, numeric field.
Return transactions: If you do not enter a G/L number for the Return transaction type, the system will back out return postings from the G/L account number defined for the Sale transaction type. For example, if you sell $100 in merchandise, and then the customer returns $50 worth, the system will back the Sale posting out from $100 to $50.
If you do enter a Return G/L number, the system does not back out the Sale posting; instead, it adds a separate Return posting.
Deferred transactions: The system posts sales to the Sale/Deferred Bill transaction type and posts returns to the Return/Deferred Bill transaction type if the payment method defined on the order is associated with a deferred payment plan.
If you do not enter a general ledger number for the Return/Deferred Bill transaction type, the system will back out return postings from the general ledger account number defined for the Sale/Deferred Bill transaction type. For example, if you sell $100 in merchandise using a deferred payment plan, and then the customer returns $50 worth, the system will back the Sale/Deferred Bill posting out from $100 to $50.
If you do enter a Return/Deferred Bill general ledger number, the system does not back out the Sale/Deferred Bill posting; instead, it adds a separate Return/Deferred Bill posting.
If you do not enter a Sale/Deferred Bill general ledger number, the system posts sales for orders containing a deferred payment plan to the Sale transaction type. The system backs out any return postings for orders containing a deferred payment plan from the general ledger number defined for the Sale transaction type.
Installment transactions: The system posts sales to the Sale/Installment Bill transaction type and posts returns to the Return/Installment Bill transaction type if the payment method defined on the order is associated with an installment payment plan.
If you do not enter a general ledger number for the Return/Installment Bill transaction type, the system will back out return postings from the general ledger account number defined for the Sale/Installment Bill transaction type. For example, if you sell $100 in merchandise using an installment payment plan, and then the customer returns $50 worth, the system will back the Sale/Installment Bill posting out from $100 to $50.
If you do enter a Return/Installment Bill general ledger number, the system does not back out the Sale/Installment Bill posting, instead, it adds a separate Return/Deferred Bill posting.
If you do not enter a Sale/Installment Bill general ledger number, the system posts sales for orders containing an installment payment plan to the Sale transaction type. The system backs out any return postings for orders containing an installment payment plan from the general ledger number defined for the Sale transaction type.
Screen Option |
Procedure |
Create or change a G/L number |
Select Change for a transaction type to advance to the Change Pay Type G/L Screen. |
Purpose: Use this screen to change a pay type general ledger number. You can change the general ledger number for the transaction type only.
How to display this screen: Select Change for the transaction type at the Work with Pay Type G/L # Screen. The transaction type displays to the left.
Credit card number formats allow you to specify which digits of a credit card number are masked on CWSerenade screens and reports using a special character, such as an asterisk (*). For example, you may wish to mask all but the last 4 digits of a 16-digit credit card number: ************1111.
Data security: You should set up a masking format for all credit cards. See Guidelines for Data Security in the Data Security and Encryption Manual for a checklist of recommended data security settings.
Tokenization: If you use credit card tokenization, the number that is masked is a token, rather than the actual credit card number.
Defining a format: You can use the Credit Card Number Layout Screen to define which digits of the credit card number on CWSerenade screens and reports are masked. You can define a separate credit card number format for a Credit Card pay category pay type and also define a default format to use for those Credit Card pay category pay types that do not have a credit card number format defined.
When a credit card number displays on a screen or report, the system looks at the pay type associated with the credit card number to determine which digits of the credit card number are masked. If the system cannot determine the pay type associated with the credit card number, the credit card number displays in the default credit card number format.
When is the credit card number masked?
• CWSerenade masks the credit card number using the specified credit card number format on all CWSerenade screens if you do not have authority to the Display Full Credit Card Number (B14) secured feature.
• CWSerenade masks the credit card number using the specified credit card number format on all CWSerenade reports, regardless of your authority to the Display Full Credit Card Number (B14) secured feature.
When is the credit card number unmasked? Even if a credit card number format is defined, the credit card number will display unmasked, meaning the entire number displays, in the following places:
• All CWSerenade XML messages. The full credit card number must display because the number is being sent to or received from an external system. However, for credit card numbers in the Outbound Email XML Message (CWEmailOut), all but the last four positions of the credit card number are replaced with asterisks (*), regardless of any credit card number masking defined.
• The CWSerenade database (tables). However, if you use credit card encryption and data security, the credit card number will be encrypted in the CWSerenade database, providing additional security of credit card data.
• Stored Value Card Notification Email. This email is generated when you purchase a virtual stored value card or send an early notification email with the card number. For virtual stored value cards, this email is the only notification that a stored value card has been activated for a customer. The customer must be able to view the entire stored value card number in order to use the card on a future purchase.
• The Stored value card number field on the Stored Value Card Assignment Screen, since you are in the process of entering the stored value card numbers for activation.
Replacing the credit card number with asterisks: For additional security, run the SECRISK periodic function to deactivate a credit card, replace the first 12 digits of the credit card number with asterisks (*), and remove the expiration date on closed and cancelled orders. See the Credit Card Retention Days (K65) system control value for background.
Credit card numbers in the database: Regardless of whether you use credit card encryption, the system masks the credit card number in the CWSerenade database, storing it in varBinary format. If you use credit card encryption to encrypt the credit card number in the CWSerenade database, you cannot unmask the credit card number in the database to view it.
Credit card encryption: Credit card encryption allows you to encrypt credit card numbers in the CWSerenade database to provide additional security for credit card data. You can define a credit card number format, regardless of whether you are using credit card encryption and data security. If you enable credit card encryption, the system encrypts the credit card number in the CWSerenade database, providing additional security of credit card data. In order to display the encrypted credit card number on CWSerenade screens and reports, the system must first decrypt the credit card number and then apply the credit card number format. See the Data Security and Encryption Manual for an overview.
Removing credit card numbers and expiration dates in the database: For additional security, you can select the Prevent Storing the Customer’s Last CC# and Exp Date (J86) system control value to automatically run a program to remove the credit card numbers and expiration dates from Customer Sold To and Customer Ship To Order History files and prevent them from being stored.
Which Cards are Eligible for Credit Card Number Formatting?
Eligible cards: You can define a credit card number format for the following types of Credit Card pay category pay types:
• Credit card (Card type Credit)
• Debit (Switch) card (Card type Debit)
• Stored value card (Card type Stored Value)
In addition, you can define a credit card number format for electronic gift certificates. Electronic gift certificates are paperless certificates that can be used as payment for an order. To create an electronic gift certificate, you create a credit card pay type (Pay category Credit Card, Card type Credit) and enter the pay type in the Electronic Gift Certificate Pay Type (G72) system control value.
Ineligible cards: You receive the error message Not available for this pay type if you try to define a credit card number format for any non-pay category Credit Card pay type.
Credit card number scan screens: You can scan on credit card number at the following CWSerenade screens:
• Order Maintenance Selection Screen
• Select Orders For Return Authorization Screen
However, if you have defined a credit card number format, the credit card numbers that display on the bottom half of the scan screen will be masked by the associated credit card number format.
In addition, if you have credit card encryption enabled, the system will not find a credit card number match unless you enter the full credit card number in the scan field. The credit card number you entered in the scan field is display-only at the top of the screen and the credit cards that display at the bottom of the screen are masked by the associated credit card number format.
Note: If you use credit card tokenization, you will not be able to scan on the full credit card number on these screens since the credit card number has been replaced with a token. Instead, you can scan on the last four digits of the credit card number on these screens; the system advances you to the Scan By CC Last 4 screen, where you can review orders that contain a credit card payment whose CC Last 4 field in the Order Payment Method table matches the last four digits of the credit card number that you entered in the scan field.
The Display Full Credit Card Number (B14) secured feature controls whether the full credit card number displays on CWSerenade screens.
• If you allow access to this feature, you can view the full credit card number on CWSerenade screens, regardless if a credit card number format has been defined at the Credit Card Number Layout Screen. If you use credit card tokenization, the number that displays is a token, rather than the actual credit card number.
• If you prohibit access to this feature (default setting), the credit card number displays in the credit card number format specified at the Credit Card Number Layout Screen for the specified pay type. If a credit card number format is not defined for the pay type, the number displays in the default credit card number format. However, if a credit card number format has not been defined for the pay type and a default credit card number format is not defined, the full credit card number will display on CWSerenade screens. If you use credit card tokenization, the number that displays is a token, rather than the actual credit card number.
Reports: Regardless of a user’s authority to the Display Full Credit Card Number (B14) secured feature, the system masks the credit card number in the credit card number format specified at the Credit Card Number Layout Screen for the specified pay type on all CWSerenade reports.
Restrict access to credit cards in OIOM: Regardless of the setting of this secured feature, if you do not have authority to the Restrict Access to Credit Card Numbers in OI and OM (A88) secured feature, the credit card number and expiration date will not display in order entry, order maintenance, or standard or streamlined order inquiry.
Setting Up a Credit Card Number Format
Use the Unformatted credit card number positions field on the Credit Card Number Layout Screen as a layout of the number of positions in the Credit card number field. There are 20 positions available in a credit card number that you can select to display or mask with a special character.
Note: Even if a credit card number only includes 16 digits, you will still be required to enter a value in positions 17-20 of the credit card number format. Enter 17, 18, 19, and 20 in the respective fields if you do not want a special character to display.
To create or change:
1. |
At the Work with Pay Types Screen, select CC# Format for a Credit Card pay category pay type to advance to the Credit Card Number Layout Screen. |
2. |
In the Formatted credit card number positions fields, decide which digits of the credit card number you wish to display and enter the digit number in the appropriate field. For example, if you wish to display the last 4 digits of a 16-digit credit card number, enter 13 in field 13, 14 in field 14, 15 in field 15, and 16 in field 16. |
3. |
In the Formatted credit card number positions fields, decide which digits of the credit card number you wish to mask and enter a special character in the appropriate field. You can enter any special character, such as an asterisk (*) or a number sign (#) as well as any letter, such as C. However, you cannot use a number to mask a credit card number. For example, if you wish to mask all but the last 4 digits of a 16 digit credit card number using an asterisk, enter * in fields 1-12 and enter 13, 14, 15, and 16 in the respective fields. |
Note: You cannot mask the digits of a credit card number using a number. If you enter a number between 1 - 20 in any of the Formatted credit card number positions fields, the system will display that digit of the credit card number in the position specified. For example, if you enter 9 in field 1, the system will display the 9th digit of the credit card number in position 1 and not the number 9. You will receive an error if you enter a number greater than 20: Only one character or number 1-20 allowed per position. |
|
4. |
Select OK to validate your entries. You must enter a number between 1and 20 or a special character in each of the Formatted credit card number positions fields. |
To delete: To delete a credit card number format, clear the data in all of the Formatted credit card number positions fields and select OK.
If you delete a credit card number format, but still have a default credit card number format defined, the credit card number will display in the default format on CWSerenade screens and reports.
Creating a Default Credit Card Number Format
If you wish to assign most of your Credit Card pay category pay types to the same credit card number format, you can create the format and select the Set as default format field. Credit Card pay category pay types that do not have a credit card number format defined, will use the default credit card number format.
You can create only 1 default credit card number format. If you flag a credit card number format as the default and then create a new credit card number format and flag it also as the default, the system advances you to the Override Default window, where you must confirm that you wish to change the default credit card number format.
Select Accept to change the default credit card number format; otherwise, select Exit to keep the current default credit card number format.
If you wish to create a default credit card number format, but still display the entire credit card number for one of your Credit Card pay category pay types, create a credit card number format for that pay type and enter all of the credit card digits in the Formatted credit card number positions fields: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20. The system will display the entire credit card number on CWSerenade screens and reports.
If you do not define a default credit card number format, and a format has not been defined for a Credit Card pay category pay type, the system displays the full credit card number for that pay type on CWSerenade screens and reports.
Credit Card Number Format Examples
The table below displays examples of credit card number formats.
Credit Card Format |
Credit Card Display |
|
Mask the credit card number using the number sign. |
# # # # # # # # # # # # # # # # # # # # |
If the number is 4111111111111111, it displays as: #################### |
Display the full credit card number. |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Note: You may wish to define this format if you have also defined a default credit card number format and you want to display the full credit card number for this pay type. For example, you may wish to display all stored value card numbers. |
If the number is 4111111111111111, it displays as: 4111111111111111. |
Only display the last 4 digits of a 16-digit credit card number. For all other digits, display an asterisk. |
* * * * * * * * * * * * 13 14 15 16 17 18 19 20 |
If the number is 4111111111111111, it displays as: ************1111 |
Display all but the last 4 digits of a 16-digit credit card number. For all other digits, display an asterisk. |
1 2 3 4 5 6 7 8 9 10 11 12 * * * * 17 18 19 20 |
If the number is 4111111111111111, it displays as: 411111111111**** |
Only display the first 4 digits and the last 4 digits of a 16-digit credit card number. For all other digits, display an asterisk. |
1 2 3 4 * * * * * * * * 13 14 15 16 17 18 19 20 |
If the number is 4111111111111111, it displays as: 4111********1111 |
Display all of the digits in a 16-digit credit card number, but display the first 4 digits in the last 4 positions and the last 4 digits in the first 4 positions. |
13 14 15 16 5 6 7 8 9 10 11 12 1 2 3 4 17 18 19 20 |
If the number is 4788250000121443, it displays as: 1111111111114111 |
Credit Card Number Layout Screen
Use this screen to create a credit card number format; see Credit Card Number Format for an overview and setup instructions.
How to display this screen: Select CC# Format for a Credit Card pay category pay type at the Work with Pay Types Screen.
Field |
Description |
Pay type |
The code and description of the credit card pay type assigned to the credit card number layout. Pay type code: Numeric, 2 positions; display-only. Description: Alphanumeric, 30 positions; display-only. |
Indicates if you wish to set this credit card number format as the default format. Credit Card pay category pay types that do not have a credit card number format defined, will use this format. • Selected = This credit card number format is the default format to use if a format has not been defined for a Credit Card pay category pay type. • Unselected (default) = This credit card number format is not the default format and is only used to display credit card numbers for this pay type. If you select this flag and a default credit card number format already exists, the system advances you to the Override Default Window, where you can confirm that you wish to change the default credit card number format. Note: If you do not define a default credit card number format, and a format has not been defined for a Credit Card pay category pay type, the system displays the full credit card number for that pay type on CWSerenade screens and reports. |
|
Displays the number of positions available to format in a credit card number. Use this field as a reference when creating the credit card number format in the Formatted credit card number positions field. Alphanumeric, 20 positions; display-only. |
|
The position and format of each of the credit card digits to display on CWSerenade screens and reports. For example, to display only the last 4 digits of a 16 digit credit card number, enter a special character, such as an asterisk (*) in fields 1 - 12. Enter the digit number in fields 13 - 20. * * * * * * * * * * * * 13 14 15 16 17 18 19 20 If the credit card number is 411111111111111, the system displays ************1111 as the credit card number on CWSerenade screens and reports. Note: You must enter either a digit number (1-20) or a single position special character in each field or an error message displays: Only one character or number 1-20 allowed per position. See Setting Up a Credit Card Number Format for setup instructions and examples. Numeric, 20 positions; required. |
Generate Chart of Accounts (GCOA) | Contents | SCVs | Search | Glossary | Reports | Solutions | XML | Index | Working with Banks (WBNK) |
WPAY OROMS 5.0 2018 OTN