Chapter 40: Using the Credit Card Authorization Interface
Purpose: The Credit Card Authorization Interface allows you to transmit and receive electronically the information required to authorize your credit card orders and deposit amounts charged to the credit cards.
You can also use this interface to transmit inventory, pricing, purchase order, invoice, shipping, or any other type of information to any on-line service you use.
Note: In this chapter, the term service bureau will be used instead of authorization service since the interface is not limited to credit card authorizations.
In this chapter:
• How Credit Card Orders are Authorized
• Hierarchy for Placing the Credit Card On Hold
• Credit Card Authorization Reversal
• What Happens When the Authorization Reversal is Approved?
• What Happens When the Authorization Reversal is Declined?
• When Communication Failures Occur
• Transmitting and Receiving Authorizations
• Credit Card Authorization Listing
• Address Verification Service (AVS)
• Address Verification Response List
• Credit Card Security Service (CID, CVV2, CVC2)
• Credit Card Authentication Service
• Process Paymentech Transactions Using CWIntegrate
• Process Paymentech Transactions Without CWIntegrate
• Additional Paymentech Processing
• Transmitting and Receiving Deposits
• Reprocess Authorizations Screen (RPAA)
• Retransmitting the Authorization File
• Receiving the Authorization File
• Reprocess Drop Ship Authorizations Screen (RPDS)
• Retransmitting the Authorization File
• Receiving the Authorization File
The setup required to communicate with a service bureau for authorization and deposit settlement is described below.
For more information: See:
• Stored Value Card Overview and Setup for more information on the setup required to process a stored value card.
• Processing Authorizations and Deposits using CWIntegrate for more information on processing transactions between CWDirect and a service bureau via a CWIntegrate site.
• The CWIntegrate Site Reference for a particular service bureau for more information on the processing that occurs when sending transactions between CWDirect and a service bureau via a CWIntegrate site.
• Chase Paymentech Orbital Gateway Integration for more information on processing transactions between CWDirect and Orbital Gateway via point-to-point communication.
System Control Value |
Description |
Defines whether you are using the interface to electronically transmit authorization and deposit information for your credit card orders to an authorization service. |
|
Determines whether a separate authorization and invoice will be created for each pick slip associated with an order, or if only one authorization and invoice will be created per shipment. |
|
Defines whether the system performs online credit card authorization during order entry. See Chapter 49: Performing Online Credit Card Authorizations for an overview and required setup. |
|
Determines the maximum number of times to attempt to authorize an order before flagging the order for cancellation. |
|
Specifies how to handle orders put on the same type of AVS hold a second time after you have released them. If you set this field to Y, the system will not hold an order more than once for the same AVS response code if, for example, you need to reauthorize the order again because a backordered item is now available for shipment. |
|
Default Credit Card Authorization Number for Soft Declines (F93) |
Defines the authorization number the system defaults when a credit card authorization is declined but is under a specified dollar amount. |
Use Credit Card Vendor Response Entity Ship Via Dollar Limits (F94) |
Defines whether the system performs an edit against a credit card vendor response to determine if the dollar amount for the credit card authorization exceeds the dollar limit defined for the ship via on the order. |
Defines whether the credit card on the order is authorized for the entire dollar amount defined for the card or the shippable amount defined for the card when you perform online authorization during order entry. |
|
Defines the authorization number the system automatically applies to credit cards that require authorizations that are under one dollar. |
|
Defines whether the system processes online authorizations for $1.00 for the purpose of validating the card. During batch authorizations, the system authorizes the card for the shippable dollar amount and voids the online authorization for $1.00. |
|
Defines the authorization service for which the system sends an authorization inquiry request to determine if an authorization response is available for an open authorization history record before performing batch authorization. See Batch Authorization Inquiry Processing. |
|
Defines the dollar amount the system uses to determine when to automatically assign the authorization number defined in the Authorization Number for Authorizations Under $ Threshold (K37) system control value to a credit card payment. |
|
Authorization Number for Authorizations Under $ Threshold (K37) |
Defines the authorization number you wish the system to automatically apply to credit cards that require authorization for an amount that is less than the dollar amount defined in the $ Threshold for Automatic Authorization # Assignment (K36) system control value. |
Defines the shippable dollar amount the system uses to determine whether to process an online authorization for the credit card payment on the order. |
Number Assignment |
Description |
Assigns the next sequence number to the online authorization when you receive a response from the authorization service during online credit card authorization. |
|
Assigns the next sequence number to the Reference ID field in the Integration Process Control file. CWDirect updates the merchantFileTrace value in the CWAuthorizationRequest message and CWDepositRequest message with this number. Important: • When sending authorizations and deposits to certain service bureaus, the Batch Auth File Trace Number cannot be greater than 3 positions. Enter 999 in the End number field for this number assignment value to ensure that this number does not exceed 3 positions. • If you are using more than one CWDirect company, make sure that the Batch Auth File Trace Number for each company has a different number and that the numbers do not overlap. For example, company 1 uses 1-499 and rolls back to 1 again and company 2 uses 500-999 and rolls back to 500 again. |
Use the Defining Authorization Services (WASV) menu option to:
• • define the service bureaus that you use, such as:
• • Authorization services, to authorize charges against a credit card or stored value card.
• • Authorization/Deposit services, to authorize card charges and receive deposit amounts.
• • Deposit services, to provide settlement for card payments.
• identify the type of service the service bureau performs
• define the parameters that identify your company to the service bureau
• define the information necessary to connect, transmit, and receive data to and from the service, such as:
• the method of communication: via a CWIntegrate site or point-to-point
• if communicating via a CWIntegrate site, the integration process control job used to transmit data between CWDirect and the service bureau via a CWIntegrate site
• valid pay types
• response codes (vendor responses, AVS responses, and CID responses)
• currency codes
• merchant IDs for individual entities within your company
Some of the information required to establish a service bureau on your system is provided by the service bureau. For example, each service bureau will assign you a unique password.
You define whether an order type is eligible for on-line authorizations and if the order type will display a window during order entry when a response is received from the service bureau, based on the On-line authorization field:
• 1 = the order type is eligible for on-line authorizations and the Select Authorization Response Option Window opens.
• 2 = the order type is eligible for on-line authorization and the Select Authorization Response Option Window does not open.
• 3 = the order type is not eligible for on-line authorization.
See Performing Online Credit Card Authorizations for more information on online authorizations.
Each credit card pay type eligible for authorization should have the service bureau set up as its authorization and deposit service. See Working with Pay Types (WPAY) for more information on setting up pay types.
How Credit Card Orders are Authorized
The information required to authorize a credit card is captured in the Authorization file. The information is transmitted electronically to the service bureau:
• in interactive mode at the time of order entry, order maintenance, or when you use the Batch Authorization menu option if you are using online credit card authorization. See Chapter 49: Performing Online Credit Card Authorizations.
• in batch mode when you generate pick slips if the Batch/online field for the authorization service is set to B (batch only) or C (online or batch).
The service bureau processes the authorization requests, and transmits the information back to your company.
• If the credit card is authorized, the authorization date, authorization code, and the amount authorized for the order is updated to the Authorization History file, which can be viewed through Order Inquiry (select F15, then enter 8 next to the pay type to display).
• If the authorization is declined, the order is not authorized. Additionally, the order may be put on hold or flagged for cancellation. See Chapter 44: Defining Vendor Response Codes.
Authorizations are required for all orders that are being paid by credit card.
Note: A separate authorization is required for each card if the customer is using more than 1 credit card on an order.
Address verification: Some service bureaus also provide an address verification service to ensure that the billing address on the credit card is legitimate; see Address Verification Service (AVS) for more information on address verification.
Card security identification: Some service bureaus also provide card identification to help reduce fraud by verifying that the credit card is present at the point of sale and to ensure that the credit card data from the transaction matches the data stored by the authorization service for that card; see Credit Card Security Service (CID, CVV2, CVC2) for more information on credit card identification.
Card authentication: Some service bureaus also provide card authentication to help reduce fraud by verifying that the cardholder is authorized to use the credit card; see Credit Card Authentication Service for more information on credit card authentication.
Pay plans: An order using a deferred or installment billing pay plan does not typically require a full authorization at the time you generate pick slips. Such an order would require an authorization at the time you process the deposit instead. See Processing Auto Deposits (SDEP) for an overview of how authorizations for pay plan orders differ from those for regular (non-pay plan) orders.
Hierarchy for Placing the Credit Card On Hold
The credit card pay type may be placed on hold if the credit card is not approved, the AVS verification fails, or the credit card identification fails.
The system uses this hierarchy to determine if the credit card pay type should go on hold:
• Vendor response has a hold reason defined: If the credit card charge is declined (not authorized), the credit card may be placed on hold (based on the value in the Hold reason field in the Vendor Response file). The order header is also placed on AT (declined credit card) hold. You must take the order header and credit card pay type off of hold through the Release Held Orders function and resend for authorization or cancel the order.
• AVS response has a hold reason defined: If the credit card charge is approved (authorized) but the credit card fails the address verification check, the authorization may be placed on hold (based on the value in the Hold reason field in the Vendor Response file). The order header is also placed on AT (declined credit card) hold. You must contact the customer and obtain correct address information, then take the order header and credit card pay type off of hold through the Release Held Orders function and resend for authorization or cancel the order.
• Card security identification response has a hold reason defined: If the credit card charge is approved (authorized) and passes the address verification check, but the credit card fails the card security identification check, the credit card pay type may be placed on hold (based on the value in the Hold reason field in the Vendor Response file). The order header is also placed on AT (declined credit card) hold. You must contact the customer to verify credit card ownership, then take the order header and credit card pay type off of hold through the Release Held Orders function and resend for authorization or cancel the order.
For more information: See Defining Vendor Response Codes and Customer Service Chapter 5: Establishing Cancel Reason Codes (WCNR).
Credit Card Authorization Reversal
Credit card authorization reversal allows the system to void an authorization against a credit card and reimburse the original authorization amount to the credit card. The system creates an authorization reversal for the original authorization amount, not the actual amount of the reversal.
When is a Credit Card Eligible for Authorization Reversal? The system performs credit card authorization reversal when the Process reversals field for the credit card pay type is selected and:
• You process a cancellation associated with a credit card payment or deactivate a credit card payment; see Credit Card Authorization Reversal during Credit Card Cancellation or Deactivation.
• You process a settlement for an amount that is greater than a single authorization transaction for the credit card pay type on the order; see Credit Card Authorization Reversal during Deposit Processing.
Credit Card Authorization Reversal during Credit Card Cancellation or Deactivation
1. |
You process a cancellation associated with a credit card payment or deactivate a credit card payment whose Process reversal field is selected. You can process a cancellation by: • Selecting Cancel for an order line or selecting Cancel to cancel the entire order in order maintenance. • Selecting Void All/Cancel Order to void the pick slip and cancel the order at the Reprinting/Voiding Pick Slips by Order Screen. • Selecting Cancel Group to cancel a group of order lines based on the cancellation date or item in the Working with Backorders Pending Cancellation (WBPC) menu option. • Processing soldout cancellations by submitting the job using the Processing Auto Soldout Cancellations (MASO) menu option or by selecting Sell Out for an order line in order maintenance. • Submitting a job to cancel orders flagged for cancellation due to credit card decline using the Working with Credit Card Cancellations (WCCC) menu option. • Submitting a job to cancel order lines for a given item and adding a substitute item to each order using the Processing Item Substitutions (PSUB) menu option. • Cancelling an order line or order on the web storefront using the Maintenance E-Commerce Process. You can deactivate a credit card payment by selecting Deactivate for the credit card payment at the Enter Payment Method Screen. |
2. |
The system determines if the order is eligible for credit card authorization reversal. For an order to be eligible for credit card authorization reversal during cancellation and credit card deactivation, the order must: • contain a credit card payment that is associated with a cancellation or deactivation. Credit card payments have a Pay Category of Credit Card and a Card type of Credit. • have an open, unused authorization remaining on the credit card that is not more than the number of hours defined in the Reversal time limit for the authorization service. Typically, this is set to no more than 72 hours old. An open, unused authorization is an authorization that is: • in an A Authorized or O Authorized, But Not Used status. • not associated with a printed pick slip for the order. • not partially confirmed or deposited. The system uses the Authorization date and Sent time defined for the Authorization History record to determine the age of the authorization. You can review the authorization date on the Authorization History Details Window. In addition, if you are using the Chase Paymentech Orbital Gateway Integration: • the original authorization must have been obtained through the Chase Paymentech Orbital Gateway integration. • the credit card authorization reversal request must contain the transaction reference number assigned to the original authorization. Authorizations in sent status: When you process a cancellation or deactivate a credit card payment and the authorization is in a S Sent, but not Received status, the system does NOT create a credit card authorization reversal for the payment even if you later receive an approved authorization response. |
|
Expired authorizations: If the original authorization for an order is expired and the order received a new authorization during batch authorization, the system will create an authorization reversal against the expired authorization when you process deposits. However, the service bureau will reject this authorization reversal since they have already expired the authorization and reimbursed the credit card. |
3. |
The system creates an authorization reversal for the original authorization amount, not the actual amount of the reversal. |
4. |
The system creates a record in the Auth History SVC Reversal file for the authorization amount to reimburse. Auth History SVC Reversal file: • Company: The company where you processed the credit card authorization reversal. • Order #: The order number associated with the credit card authorization reversal. • OPM Seq #: The order payment method sequence number associated with the credit card payment. • AUH Seq #: The authorization history sequence number associated with the credit card payment. • Seq #: The Auth History SVC Reversal sequence number. • Creation date: The date, in CYYMMDD format, the credit card authorization reversal was created. • Creation time: The time, in HHMMSS format, the credit card authorization reversal was created. • Approval date: The date, in CYYMMDD format, the credit card authorization reversal was approved by the service bureau. • Approval time: The time, in HHMMSS format, the credit card authorization reversal was approved by the service bureau. • Reversal amount: The amount to reimburse to the credit card. • Response: The response received from the service bureau, indicating the authorization reversal was approved or declined. |
5. |
The system looks at the Authorization service field defined for the credit card payment to determine the service bureau used to process the authorization reversal. |
6. |
The system generates an Authorization Request XML Message (CWAuthorizationRequest) with an actionCode of Reversal. If you are using the Chase Paymentech Orbital Gateway Integration, the system maps the CWDirect Credit Card Authorization Reversal Request to the Orbital Gateway Reversal Request XML Message and sends this message to Orbital Gateway. |
7. |
CWDirect processes the authorization reversal response accordingly. If you are using the Chase Paymentech Orbital Gateway Integration, the system receives the Orbital Gateway Reversal Response XML Message and maps it to the Authorization Response XML Message (CWAuthorizationResponse) with an actionCode of Reversal. If the authNumber contains VOIDOK, CWDirect considers the authorization reversal approved. See: • What Happens When the Authorization Reversal is Approved? |
Credit Card Authorization Reversal during Deposit Processing
1. |
You process a settlement for an amount that is greater than a single authorization transaction for the credit card pay type on the order. The Process reversal field is selected for the credit card pay type. Orbital Gateway: If you are using the Chase Paymentech Orbital Gateway Integration, the Immediate deposit field for the ORB service bureau defines when the system processes a settlement. If the Immediate deposit field is selected, the system: • during billing: sends a Mark For Capture transaction to indicate the associated authorization is ready for settlement. See Deposit > Mark For Capture Process. • during deposit processing: sends an End of Day transaction to settle the Mark For Capture transactions that were processed during the day. See Deposit > End Of Day Process. In the case of authorization reversals, the system: • during billing: sends a New Order Authorization and Capture transaction to process a new authorization against the card and mark it for capture. See Deposit > New Order Authorization and Mark For Capture Process. • during deposit processing: • sends a Reversal transaction to void the original authorization(s) on the card. See Credit Card Authorization Reversal > Reversal Process. • sends an End of Day transaction to settle the new authorization that was marked for capture earlier in the day. See Deposit > End Of Day Process. |
|
If the Immediate deposit field is unselected, the system: • does not send any transactions during billing. • during deposit processing: • sends a Mark For Capture transaction to indicate the associated authorization is ready for settlement. See Deposit > Mark For Capture Process. • sends an End of Day transaction to settle the Mark For Capture transactions. See Deposit > End Of Day Process. In the case of authorization reversals, the system: • does not send any transactions during billing. • during deposit processing: • sends a Reversal transaction to void the original authorization(s) on the card. See Credit Card Authorization Reversal > Reversal Process. • sends a New Order Authorization and Capture transaction to process a new authorization against the card and mark it for capture. See Deposit > New Order Authorization and Mark For Capture Process. • sends an End of Day transaction to settle the new authorization that was marked for capture. See Deposit > End Of Day Process. |
2. |
The system determines if the order is eligible for credit card authorization reversal. For an order to be eligible for credit card authorization reversal during settlement, the authorization to settle against cannot be more than the number of hours defined in the Reversal time limit for the authorization service. Typically, this is set to no more than 72 hours old. The system uses the Authorization date and Sent time defined for the Authorization History record to determine the age of the authorization. You can review the authorization date on the Authorization History Details Window. In addition, if you are using the Chase Paymentech Orbital Gateway Integration: • the original authorization must have been obtained through the Chase Paymentech Orbital Gateway integration. • the credit card authorization reversal request must contain the transaction reference number assigned to the original authorization. Note: If the Process reversal field is not selected for the credit card pay type, or if the authorization is greater than the number of hours defined in the Reversal time limit, the system will not void the original authorization(s) on the card. Instead, the original authorization(s) will expire based on the reauthorization days defined for the credit card pay type. |
3. |
The system creates an authorization reversal for the original authorization amount, not the actual amount of the reversal. |
4. |
The system creates a record in the Auth History SVC Reversal file for the authorization amount to reimburse. Auth History SVC Reversal file: • Company: The company where you processed the credit card authorization reversal. • Order #: The order number associated with the credit card authorization reversal. • OPM Seq #: The order payment method sequence number associated with the credit card payment. • AUH Seq #: The authorization history sequence number associated with the credit card payment. • Seq #: The Auth History SVC Reversal sequence number. • Creation date: The date, in CYYMMDD format, the credit card authorization reversal was created. • Creation time: The time, in HHMMSS format, the credit card authorization reversal was created. • Approval date: The date, in CYYMMDD format, the credit card authorization reversal was approved by the service bureau. • Approval time: The time, in HHMMSS format, the credit card authorization reversal was approved by the service bureau. • Reversal amount: The amount to reimburse to the credit card. • Response: The response received from the service bureau, indicating the authorization reversal was approved or declined. |
5. |
The system looks at the Authorization service field defined for the credit card payment to determine the service bureau used to process the authorization reversal. |
6. |
The system generates an Authorization Request XML Message (CWAuthorizationRequest) with an actionCode of Reversal. If you are using the Chase Paymentech Orbital Gateway Integration, the system maps the CWDirect Credit Card Authorization Reversal Request to the Orbital Gateway Reversal Request XML Message and sends this message to Orbital Gateway. |
7. |
CWDirect processes the authorization reversal response accordingly. If you are using the Chase Paymentech Orbital Gateway Integration, the system receives the Orbital Gateway Reversal Response XML Message and maps it to the Authorization Response XML Message (CWAuthorizationResponse) with an actionCode of Reversal. If the authNumber contains VOIDOK, CWDirect considers the authorization reversal approved. See: • What Happens When the Authorization Reversal is Approved? |
What Happens When the Authorization Reversal is Approved?
An authorization reversal is approved if the Authorization Reversal Response contains an authorization number. In this case, the system:
• Updates the associated record in the Auth History SVC Reversal file with an approval date, approval time, and reversal response.
• Creates an order transaction history message indicating the authorization reversal was approved: Auth Reversal Has Been Approved.
• Voids the authorization history record.
Note: If the Authorization Reversal Response contains an amount, the system ignores the amount sent back and continues to use the amount from the Auth History SVC Reversal file.
You can review the credit card authorization reversal at the Display Authorization Reversals Screen. The approved reversal will have an Approval date and time.
What Happens When the Authorization Reversal is Declined?
An authorization reversal is declined if the Authorization Reversal Response does not contain an authorization number. In this case, the system creates an order transaction history message indicating the authorization reversal was declined: Reversal Has Been Rejected.
You can review the declined credit card authorization reversal at the Display Authorization Reversals Screen. The declined reversal will have a blank Approval date and time. You cannot resend an authorization reversal request to a service bureau.
Note:
• Except for the order transaction history message, there is no other indication that the credit card authorization reversal request was declined.
• Because the cancellation or deactivation amount was not reimbursed to the card, the customer will not be able to use that amount on future purchases paid for against the card.
• The response received from the service bureau does not display in the Response field on the Display Authorization Reversals Screen unless it is set up as a vendor response for the service bureau in Defining Authorization Services (WASV).
When Communication Failures Occur
Communication failures can occur if the connection between CWDirect and the service bureau is down, or the system times out before a response is received. If communication failures occur and you do not receive a response from the service bureau, the system:
• Does not update the associated record in the Auth History SVC Reversal file.
• Does not create an order transaction history message.
You cannot resend an authorization reversal request to the service bureau.
Purpose: Batch Authorization is used to authorize credit card orders during pick slip generation. An authorization will be requested during pick slip generation if:
• the order is being paid by credit card and the credit card does not have an authorization, and
• the Batch/online field for the authorization service is set to B (batch only) or C (online or batch).
How the orders are authorized: The authorization information is captured in the Authorization file (CCAT00) as the orders are being allocated and the records are assigned a *RCVD status. The pick slip is placed in a pending status if an authorization is required.
Transmitting and Receiving Authorizations
After the orders are allocated, the Authorization file is transmitted to the authorization service.
If using CWIntegrate, an XML message is generated and sent to the CWIntegrate site for translation and forwarding to the service bureau. See Processing Authorizations and Deposits using CWIntegrate for additional setup and processing logic.
If using a leased line, the file is transmitted automatically. Set the Communication type field defined for the authorization service to L (leased line).
You must purchase a leased line in order to have a direct connection to the authorization service. The system uses the port number and provider network address defined for the authorization service.
If you perform online and batch authorizations and wish to use modem for batch authorizations and deposits, set the Communication type field defined for the authorization service to D (dial-up/modem connection) or blank. The system does not use the Communication type field for online credit card authorizations. The leased line used for online authorizations is defined in the Online Authorization Socket Server job. If you perform batch and online authorizations, make sure the port number you define for batch authorizations is different from the port number you define for online authorizations.
You can use a leased line for batch authorizations for transmission to Nabanco or Paymentech Batch Processing 96-Byte Revision 1.6.2. You can also send authorizations to First Data Merchant Services and Paymentech using CWIntegrate over a leased line; see Processing Authorizations and Deposits using CWIntegrate.
If using an autodial modem, the file is transmitted automatically. Set the Communication type field defined for the authorization service to D (dial-up/modem connection).
The modem type (autodial or manual dial) and telephone number are defined on the iSeries.
If using a manual-dial modem, a message will be sent to the SYSOPR message queue. Set the Communication type field defined for the authorization service to D (dial-up/modem connection).
The system operator must dial the modem telephone number (identified in the message) and answer the message to begin transmitting the Authorization file.
The communications line stays varied on in a *Connect Pending status for services that do not provide immediate turnaround (responses), such as AMEX. Also a message similar to the following is sent to the SYSOPR message queue:
Waiting to receive auths from __________________.s
Options: C or V.
You must wait to receive the authorizations. The amount of time you wait is based on the size of the authorization file plus a certain amount of time before and after transmitting the file.
For example, if transmitting to AMEX, you must figure on waiting 5 minutes before and after sending the file plus waiting a certain amount of time based on the size of the file itself. This means that, although the message to receive the file appears right away, you do not respond to the message with a V to receive the file until the appropriate amount of time has elapsed.
When are pick slips printed? Pick slips and pull sheets are printed after the authorizations are received from the authorization service.
What information is sent? The Batch Authorization program sends this information to the authorization service.
Value passed |
Description |
Company |
The company where you placed the order. |
Order number |
The order number that contains the credit card payment method requesting authorization. |
Authorization service record |
A code to identify the authorization service. |
Order payment sequence # |
The sequence number associated with this credit card payment method. |
Pay type |
The credit card pay type requesting authorization. |
Credit card number |
The credit card number defined for the credit card requesting authorization. Note: If you use credit card encryption, the system decrypts the credit card number before sending it to the service bureau. |
Expiration month |
The month this credit card is no longer valid. |
Expiration year |
The year this credit card is no longer valid. |
Card security presence |
Indicates to the authorization service whether a card security value (CID, CVV, CVC) is present on the credit card. If a card security presence exists for the credit card payment method, the authorization service performs card security identification. Valid values: 1 = card security value is present on the credit card. 2 = card security value is present on the credit card, but is illegible. 9 = card security value is not present on the credit card. |
Card security value |
The credit card’s security value. American Express: The card security value, or CID (card identification number), is a 4-digit number imprinted, not embossed, on an AmericanExpress credit card. The card security value displays above and to the right of the imprinted credit card number on the front of the card. Discover: The card security value, or CID (card identification number), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. VISA: The card security value, or CVV2 (card verification value), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. MasterCard: The card security value, or CVC2 (card validation code), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. Note: The card identification number is only available for online authorizations; once an order is accepted, the system removes the card identification number from the order, even if the order has not received an approved online authorization. Reducing fraud: Authorization services use card security identification to help reduce fraud by verifying that the credit card is present at the point of sale and to ensure that the credit card data from the transaction matches the data stored by the authorization service for that card. |
Amount to authorize |
The dollar amount associated with the credit card requesting authorization. Alternate currency pricing: If the Use Alternate Currency Pricing (H89) system control value is set to Y and a currency code and conversion rate are defined in the Order Header Extended file, the alternate currency displays; otherwise, the local currency displays. |
Billing customer number |
The number of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing customer last name |
The last name of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing customer first name |
The first name of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing address line 1 |
Address line 1 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing address line 2 |
Address line 2 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing city |
The city for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing state |
The state for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing zip |
The zip code for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing extra zip |
The zip code + 4 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing country |
The country for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Called by flag |
This flag indicates where the order was placed, for example, regular order entry or batch order entry. OE = order entry BI = batch invoice BR = batch regular EC = e-commerce (this is not currently implemented) |
CC Authorization Transaction file: When you send credit card information to the authorization service, the system also creates a record in the CC Authorization Transaction file.
Field |
Description |
Company |
The company where you placed the order. |
Vendor code |
The order number and ship to number that contains the credit card payment method requesting authorization. |
Order number |
The order number that contains the credit card payment method requesting authorization. |
Transaction type |
The type of transaction being sent to the authorization service. *PURCH = Purchase transaction, indicating a debit. * RETURN = Return transaction, indicating a credit. |
Credit card number |
The credit card number defined for the credit card requesting authorization. Note: If you use credit card encryption, the system encrypts the credit card number in this file to provide additional security of credit card data. |
Status |
The status of the transaction. *RDY = the transaction is ready to be sent to the authorization service. *SENT = the transaction has been sent to the authorization service, and a reply has not yet been received. *RCVD = the transaction has been sent to the authorization service and a response has been received. |
Vendor response 1 |
The authorization response for the credit card. This field remains blank until an authorization response is received. |
Vendor response 2 |
The card security identification (CID, CVV2, CVC2) response for the credit card. This field remains blank until a card security identification response is received. A card security response is not received unless a card security presence and optionally, card security value, were sent as part of the authorization request. |
Auth code |
The code used to authorize the credit card. This field remains blank until an authorization response is received. |
Auth date |
The date the credit card was authorized. This field remains blank until an authorization response is received. |
Paytype |
The credit card pay type requesting authorization. |
Expire month |
The month the credit card is no longer valid. |
Expire year |
The year the credit card is no longer valid. |
AVS response |
The AVS response for the credit card. This field remains blank until an AVS response is received. An AVS response is not received unless the authorization service performs address verification. |
Auth. $ amt |
The dollar amount associated with the credit card requesting authorization. |
Hold reason |
The hold reason assigned to the credit card payment method; this is the hold reason defined for the authorization response, AVS response, or CID response, in that order. This field remains blank until an authorization response is received and is only updated if a hold reason code has been defined for the authorization response, AVS response, or CID response. |
Customer number |
The number of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Last name |
The last name of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
First name |
The first name of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Address line 1 |
Address line 1 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Address line 2 |
Address line 2 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Bill to city |
The city for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Bill to state |
The state for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Bill to zip |
The zip code for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Bill to xtra zip |
The zip code + 4 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Bill to country |
The country for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Telephone number |
The telephone number for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Telephone type |
Indicates whether the telephone number is the customer’s day number or evening number. |
Trans. date |
The date the transaction is sent to the authorization service. |
Tran. time |
The time the transaction is sent to the authorization service. |
OPM seq number |
The sequence number associated with the credit card payment method. |
Auh seq number |
The sequence number associated with the authorization. |
Auth service code |
A code to identify the authorization service. |
Currency code |
A code for the currency associated with the amount requesting authorization. This value remains blank for the local currency. |
Determining the amount to authorize: When the Batch Authorization method is used, only the amount that is being shipped, that has not yet received an authorization, is authorized.
Additionally, the system determines if the authorization amount qualifies for automatic authorization.
• If the credit card amount to authorize is less than the dollar amount defined in the $ Threshold for Automatic Authorization # Assignment (K36) system control value and you have defined an authorization number in the Authorization Number for Authorizations Under $ Threshold (K37) system control value, the system does not send the credit card to the service bureau for authorization and instead assigns the authorization number defined in the Authorization Number for Authorizations Under $ Threshold (K37) to the credit card.
• If the $ Threshold for Automatic Authorization # Assignment (K36) or Authorization Number for Authorizations Under $ Threshold (K37) system control value is blank, the credit card amount to authorize is less than $1.00, and you have defined an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value, the system does not send the credit card to the service bureau for authorization and instead assigns the authorization number defined in the Authorization Number for Authorizations Under $1.00 (I08) system control value to the credit card.
• If an authorization number is not defined in the Authorization Number for Authorizations Under $ Threshold (K37) or Authorization Number for Authorizations Under $1.00 (I08) system control value, the system sends the credit card to the service bureau for authorization, regardless of the amount that requires authorization.
Note: You must obtain an authorization for each credit card used on an order for the pick slip to be printed.
If multiple pick slips are printed for the order, you can authorize the shipment amount of each pick slip separately, or you can request one authorization for the total order amount being shipped.
Multiple payment types: When there are multiple payment types on an order, the system will apply the amounts associated with each payment type in ascending order by payment sequence code. You define the payment sequence for each order when you enter it.
If an order is being paid by Visa and Mastercard, the Order Entry operator must indicate which credit card is to be used first, and the dollar amount to charge to that card.
Example:
If you specify that $50 is to be charged to Visa first, and the remainder of the order is to be charged to Mastercard, the first $50 will be applied to Visa.
The system authorizes only the amount that can be shipped. If only $40 is being shipped, an authorization request for $40 will be sent for the Visa card. If an additional $40 is shipped the following week, two authorizations will be requested: the remaining $10 for Visa and $30 for Mastercard.
If the Visa card is approved and the Mastercard is declined, the second shipment will not occur. The full shipment amount must be approved for the shipment to occur. The system will retain the authorization code, date, and amount for the Visa card. The authorization will be good for the number of days you specify in the Reauthorization days field in the Payment Type file.
Multiple pick slips: The Pick Slip Generation program will print pick slips for authorized credit card orders. If an authorization is received for only a portion of the amount being shipped, the pick slip will not be printed.
If the order is being shipped in more than one carton, a separate pick slip will be printed for each carton. When multiple pick slips are generated for an order, you can do one of the following:
• You can request a separate authorization for the shipment amount associated with each pick slip.
• You can use the Consolidate invoices feature, which allows you to obtain one authorization for the total amount being shipped, regardless of the number of picks slips printed for the order.
Separate authorizations: When you obtain a separate authorization for each pick slip, an authorization will be obtained for the amount being shipped in each carton.
Example: Order# 345 has a shipment amount of $100. Three pick slips are printed for the order because three cartons are required to ship the merchandise. A separate authorization will be obtained for each pick slip as follows:
Carton # |
Shipment Amount |
Authorization Code |
1 |
$25 |
56D |
2 |
$40 |
68H |
3 |
$35 |
90B |
An Authorization History record will be created for each authorization received.
Note: It is possible to receive an authorization for cartons 1 and 2, and a decline for carton 3 if the customer does not have enough available credit to authorize all three cartons.
When the order is billed, the system will attempt to match the invoice amount to the authorization. If carton 3 is billed first, the system will search the Authorization History file for a $35 authorization for the order. The deposit amount will be updated and the $35 authorization record will be exhausted.
If the system cannot find a match for the deposit in the Authorization History file, it will use the first available authorization code for the order. In the above example, the system would have used the authorization obtained for carton 1.
You will incur a separate transaction fee for each authorization and deposit processed for the order.
Consolidating invoices: When you use the Consolidated Invoice (B49) feature, the system will obtain one authorization and will create one deposit record for the total amount being shipped, regardless of the number of pick slips that are generated for an order. The full amount of the shipment must be authorized when this method is used.
Example: Order # 745 has a shipment amount of $100. Three pick slips are printed for the order because three cartons are required to ship the merchandise.
Carton |
Shipment Amount |
1 |
$25 |
2 |
$40 |
3 |
$35 |
One authorization will be obtained for the entire order. If the customer has an available balance of only $40, nothing will be shipped. All three pick slips associated with the order will be deleted from the Pick Control file.
This method allows you to limit the number of authorization and deposit transactions required for the order, and reduces your transaction fees to the authorization service.
If all pick slips for the order are billed on the same day, the authorization amount will match the deposit amount and no additional authorizations will be required at settlement.
If all pick slips for the order are not billed on the same day, the authorization amount will not match the deposit amount and the order will be re-authorized at settlement with each deposit.
Voiding pick slips: If you void a pick slip, the credit card is still authorized. The authorization does not expire until the number of days you specify in the Reauthorization days field in the Payment Type file have elapsed.
If the authorization is valid when the order is reallocated, the system will use the existing authorization. The authorization amount may not match the shipment amount when the deposit request is processed. If this occurs, the authorization service will reauthorize the order for the correct amount prior to accepting the deposit.
Authorization history: Once a response is received from the authorization service, the system creates a record in the Authorization History file. You can review authorization history on the Display Authorization History Screen and Authorization History Details Window.
Field |
Description |
Company |
The company where you placed the order. |
Order number |
The order number that contains the credit card payment method requesting authorization. |
Sequence number |
The next available number defined in the Transaction sequence # number assignment value. |
Status |
A = Authorization approved D = Authorization declined |
Amount authorized |
The dollar amount associated with the credit card that has been authorized. |
Amount deposited |
The dollar amount associated with the credit card that has been deposited. This field should display blank. |
Auth date |
The date the credit card was authorized. |
Sent date |
The date you sent the credit card information to the authorization service for authorization. |
Auth number |
The number used to authorize the credit card. |
Vendor response |
The authorization response for the credit card from the authorization service. The system looks at the Credit Card Vendor Response file to find a match to the vendor response code from the authorization service. |
Vendor response 2 |
The card security identification response for this credit card from the authorization service. The system looks at the Credit Card Vendor Response file to find a match to the card security response code from the authorization service. If the card security response is associated with a hold reason, the system places the order on AT hold and places the credit card payment method on hold. |
AVS response |
The address verification response for this credit card from the authorization service. The system looks at the Credit Card Vendor Response file to find a match to the AVS response code from the authorization service. If the AVS response is associated with a hold reason, the system places the order on AT hold and places the credit card payment method on hold. |
Transaction ID |
The transaction ID returned by the service bureau for an approved authorization. If a transaction ID is defined for an authorization transaction, the system includes the transaction ID in the deposit transaction when you process deposits to provide a link between the authorization and deposit transactions. |
Errors During Transmission
If an error occurs during authorization transmission between CWDirect and the authorization service, the system places the batch authorization job in a message wait status and waits for you to respond to the error.
The transmit error message includes the Charge description for the service bureau that caused the batch authorization job to go on message wait so that you can identify which authorization service failed. For example, if the Charge description is PAYMENTECH, the error message displays as:
Errors occurred during the PAYMENTECH data transmission.
See Verifying Transaction Flow between CWDirect and the Service Bureau and Resolving Errors During Batch Transmission for more information on troubleshooting errors that may occur during authorization transmission.
When credit card charges are approved (authorized):
• pick slips print (because the items can be shipped)
• the status of the records in the Authorization file is set to *RCVD
• the system updates the Authorization History file with the authorization code, authorization date, and amount authorized
• the order appears on the "Authorized" version of the Credit Card Authorization Listing
When credit card charges are declined:
• no pick slips print
• the system deletes the pick control header and detail records since the items cannot ship
• the order appears on the "Declined" version of the Credit Card Authorization Listing
• the system updates the Authorization History file with the decline code and reason.
Optionally, you can also set up a vendor response code so that any of the following can take place:
• the order is held (with or without a Hold until date, which indicates when the order is eligible for release through the Time Release Held Orders periodic function)
• the order is flagged for cancellation
You can define the number of times to attempt authorization for each vendor response. Also, you can use the Maximum Number of Retries on Credit Card Orders (E74) system control value to specify the total number of authorization attempts for an order across all vendor responses.
If there is a problem with the transmission or if the authorization service cannot process the Authorization file, pick control records for the credit card orders requiring authorization will remain in a pending status. Pick slips will not be printed for these orders until an authorization is received. It is possible to allocate several hundred credit card orders during Pick Slip Generation without printing any pick slips for them.
See Customer Service Chapter 78: Working with Credit Card Cancellations (WCCC) for information on how to cancel credit card orders based on declined authorization.
Address Verification Service (AVS)
Address verification services help to reduce the fraudulent use of credit cards by verifying that the billing address on the credit card is legitimate.
To use this feature, set Address verification to Y in the Authorization Services file, define each possible response in the Vendor Response file, and define the hold codes in the Order Hold Reason file (for AVS responses that require the order to be held). See Defining Authorization Services (WASV), and Defining Vendor Response Codes. Also, see Customer Service Chapter 5: Establishing Cancel Reason Codes (WCNR).
Note: Address verification processing is not available for international transactions.
If the credit card charge is approved (authorized) but the order fails the address verification check, the order may be placed on hold (based on the value in the Hold reason field in the Vendor Response file). If so, the pick control header and pick control detail records are deleted. You must contact the customer and obtain correct address information, then take the order off of hold through the Release Held Orders function.
Entity dollar limits: Additionally, you can set up the following instructions for an AVS response code for each entity in your company:
• Whether a dollar limit is applied to the ship via on the order. If the authorization amount is less than the ship via dollar limit, the system releases the order from any AVS hold. If the authorization is greater than the ship via dollar limit, the system places the order on hold using the hold reason defined for the ship via dollar limit. See Entity ship via dollar limits for additional processing logic.
• Whether a dollar limit is applied to the item class associated with an item on the order. If the authorization amount is less than the item class dollar limit, the system releases the order from any AVS hold. If the authorization is greater than the item class dollar limit, the system places the order on hold using the hold reason defined for the item class dollar limit. See Entity item class dollar limits for additional processing logic.
• Whether a dollar limit is applied to the postal code defined for the bill to or sold to customer on the order. If the authorization amount is less than the postal code dollar limit, the system releases the order from any AVS hold. If the authorization is greater than the postal code dollar limit, the system places the order on hold using the hold reason defined for the postal code dollar limit. See Entity postal code dollar limits for additional processing logic.
AVS hold bypass: The Credit Card Authorization AVS Hold Exemption/Bypass (E61) system control value specifies how to handle orders put on the same type of AVS hold a second time after you have released them. If you set this field to Y, the system will not hold an order more than once for the same AVS response code if, for example, you need to reauthorize the order again because a backordered item is now available for shipment.
Unrecognized responses: Additionally, the system puts an order on AVS hold if the service bureau returns a response code that you have not defined. The order appears on the Credit Card Authorization Listing (not the Address Verification Response List) as a declined order, but with no description. You will need to use the Release Held Orders function once you have resolved the question.
Reviewing the AVS response: The AVS response received for the authorization is stored in the AVS response field in the Authorization History file. You can review the AVS response on the Display Authorization History Screen and Authorization History Details Window.
Address Verification Response List
The Address Verification Response List, which prints when you receive the Authorization file, identifies the service bureau, order number, billing batch number, transmission date, customer name and address, customer number, credit card number, credit card expiration date, authorization number, amount authorized, and AVS response. Refer to this report when you contact the customer to correct the address problem.
Credit Card Security Service (CID, CVV2, CVC2)
Credit card security services (CID, CVV2, CVC2) help to reduce the fraudulent use of credit cards by verifying that the credit card is present at the point of sale and to ensure that the credit card security value from the transaction matches the security value stored by the authorization service for that card.
The credit card identification service uses the card security value provided by the customer to determine if the credit card is present at the point of sale or if the card is possibly a fraud.
• American Express: The card security value, or CID (card identification number), is a 4-digit number imprinted, not embossed, on an American Express credit card. The card security value displays above and to the right of the imprinted credit card number on the front of the card.
• Discover: The card security value, or CID (card identification number), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number.
• VISA: The card security value, or CVV2 (card verification value), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number.
• MasterCard: The card security value, or CVC2 (card validation code), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number.
• Stored Value Card: The card security value, or CVD2 (card verification data 2) is a 4-digit value imprinted on the back of the stored value card.
• Debit (Switch) card: Depending on your debit card provider, the card security value is a 3 or 4-digit number imprinted on the back of the card.
Example: An example of where the card security value is located on Visa, Discover, Mastercard, and American Express credit cards is displayed below.
To perform card security identification, enter a number in the Card security value field and a valid number in the Card security presence field when you take the customer’s credit card information.
The Card security presence field indicates to the authorization service whether a card security value is present on the credit card.
• 1 indicates the card security value is present on the credit card. You enter the card security value in the Card security value field for the credit card payment method.
• 2 indicates the card security value is present on the credit card, but is illegible. In this transaction, the card security value is blank.
• 9 indicates the card security value is not present on the credit card. In this transaction, the card security value is blank.
Note: The system removes the card security value from an order when the order is accepted, even if an approved online authorization has not been received on the order. Card security processing is not available during batch authorization or deposit processing.
If you do not wish to use credit card security identification, leave the Card security value and Card security presence fields blank for the credit card payment method.
Determining which cards require a card security value: You can use the CC Deposit Level II Bin file (CCBINR) to indicate which cards require a card security value. Indicating which cards require a card security value allows you to eliminate the need for order entry operators to ask a customer for the number; instead, during order entry the system prompts for a card security value if it is required for the card. To populate this file for card security, complete the following fields:
Field |
Description |
Company |
The code for the company associated with the card bin range. Company codes are defined in and validated against the Company file; see Setting Up Companies (WCMP). Numeric, 3 positions; required. |
CC BIN Low Range |
The beginning number in a card bin range. Note: You must enter the full number of positions in the card number. For example, if the card number is 16 positions, the beginning number in the card bin range must be 16 positions, such as 6055000000000000. Alphanumeric, 20 positions; required. |
CC BIN High Range |
The ending number in a card bin range. Note: You must enter the full number of positions in the card number. For example, if the card number is 16 positions, the ending number in the card bin range must be 16 positions, such as 6055000000000000. Alphanumeric, 20 positions; required. |
Require card security |
Defines whether a card security value is required for a card number that falls within this card bin range. Y = A card security value is required for a card number that falls within this card bin range. When you enter a number in the Card security value field, the system defaults 1 (Value is present) to the Card security presence field. An error message displays in order entry if you do not define a card security value for a card number that requires a card security value: Card security value is required. This error message continues to display until you enter a card security value or enter 2 (Value on card, illegible) in the Card security presence field. N or blank = A card security value is not required for a card number that falls within this card bin range. You can leave the Card security value field blank; in this situation, the system defaults 9 (Value not on card) to the Card security presence field. Alphanumeric, 1 position; optional. |
Ecommerce and phone interface orders: If the card security value and card security presence are passed for an e-commerce or phone interface order, the system clears the values and does not pass them to the order. See Chapter 77: E-Commerce Order Creation, Order Entry Chapter 34: Loading Remote Orders (LPHO), and Chapter 41: Generic Order Interface (Order API).
Card security hold: If the credit card charge is approved (authorized) but the order fails the credit card security identification check, the order may be placed on hold (based on the value in the Hold reason field in the Vendor Response file). If so, the pick control header and pick control detail records are deleted. You must contact the customer to confirm credit card ownership, then take the order off of hold through the Release Held Orders function. See Hierarchy for Placing the Credit Card On Hold.
Reviewing the card security response: The card security identification response received for the Paymentech authorization is stored in the Vendor response 2 field in the Authorization History file. You can review the card security identification response on the Display Authorization History Screen and Authorization History Details Window.
Possible card security identification responses are:
• M (match) = The card security value indicated on the card matches the card security value in the secured database.
• N (no match) = The card security value indicated on the card does not match the card security value in the secured database. You should be cautious in processing credit cards with a card security response of N; the transaction is possibly a fraud.
• P (not processed) = The card security value was not processed due to communication errors.
• S (should be on card) = The card security value should be present on the card (this response applies to card security presence 9).
• I (invalid) = The card security value is invalid. Do not process credit cards with a card security response of I; the transaction is possibly a fraud.
• U (Unsupported by issuer) = The issuer of the credit card does not support card security identification.
Note: The card security identification response is separate from the authorization response. It is possible to receive an approved authorization, but a no match on the card security data. Once you accept an order, the system removes the Card security value and Card security presence from the order payment method record.
Set-up: To use this feature:
• Define each possible response in the Vendor Response file; see Defining Authorization Services (WASV) and Defining Vendor Response Codes.
• Define the hold codes in the Order Hold Reason file (for card security identification responses that require the order to be held); see Chapter 5: Establishing Cancel Reason Codes (WCNR).
• Optionally, define which cards require a card security value in the CC Deposit Level II Bin file (CCBINR).
• Use the Send card security value and Send card security presence fields in the Pay Type file to indicate whether the card security value and presence are passed to the service bureau in the online authorization request.
Credit Card Authentication Service
Credit card authentication services help to reduce fraud and chargeback volume on card not present transactions by requiring the cardholder to enter a card authentication password on the web storefront. The authentication password is sent to an authentication service, such as Visa’s Verified by Visa program or MasterCard’s SecureCode program, to verify the cardholder’s identify and ownership of the credit card during the online purchase.
Which credit cards? Authentication processing is available for the following credit cards:
• Visa, using the Verified by Visa (CAVV) program.
• MasterCard, using the SecureCode (AAV) program.
• Switch (Debit) card
Credit card authentication process:
1. At the payment screen on a web storefront, the customer is prompted to enter a card authentication password.
2. The web storefront sends the card authentication password to the authentication service.
3. The authentication service validates the password and sends back an electronic commerce indicator (ECI) and an authentication verification value.
• The electronic commerce indicator (ECI) indicates the level of security provided for a credit card transaction placed over the internet.
• The authentication verification value (CAVV for Visa or AAV for MasterCard) indicates whether the password the cardholder provided was approved for the credit card.
4. The web storefront sends the order to CWDirect in the E-Commerce New Order Message (CWCreateOrder), E-Commerce Payment Message (CWPayment), or Inbound Order XML Message (CWORDERIN).
5. CWDirect creates the order and:
• updates the E-Commerce indicator field in the Order Payment Method file with the electronic commerce indicator.
• updates the Authentication value field in the Order Payment Method file with the authentication value.
6. During authorization and deposit processing, CWDirect sends the e-commerce indicator and authentication value associated with the credit card to the service bureau in the Authorization Request XML Message (CWAuthorizationRequest) and Deposit Request XML Message (CWDepositRequest).
Authentication verification value format: In order for the service bureau to process the authentication value correctly, the authentication verification value returned from the web storefront must be in the correct format.
• The Paymentech service bureau requires the authentication value to be Base 64 encoded. Base 64 is a cryptographic value derived with an algorithm that encrypts the credit card authentication data for security.
• The FDMS Chase service bureau requires the authentication value to be Base 16 encoded. Base 16 is a hexidecimal cryptographic value derived with an algorithm that encrypts the credit card authentication data for security.
CWDirect will not format the authentication verification value it receives from the web storefront.
7. The service bureau sends an authentication response back to CWDirect in the Authorization Response XML Message (CWAuthorizationResponse) and Deposit Response XML Message (CWDepositResponse). However, the response is not stored in any CWDirect file.
Credit card authentication illustration:
When you process deposits, the system sends level II and level III discounting information to the service bureau if the Send Data for Level II/III Discounting (I12) system control value is set to Y.
Populating the CC Deposit Level II Bin file: The CC Deposit Level II Bin file (CCBINR) identifies those credit cards that are eligible for level II and level III discounting. When populating this file, make sure the number of digits defined for a level II bin range matches the number of digits in the credit cards you wish to discount. The system does not evaluate the leading digits of the credit card number against the level II bin range level. If the number of digits defined for the level II bin range does not match the number of digits defined for the credit card numbers, the credit cards are not eligible for level II or level III discounting.
Field |
Description |
Company |
The code for the company associated with the card bin range. Company codes are defined in and validated against the Company table; see WCMP. Numeric, 3 positions; required. |
CC BIN Low Range |
The beginning number in a card bin range. Note: You must enter the full number of positions in the card number. For example, if the card number is 16 positions, the beginning number in the card bin range must be 16 positions, such as 6055000000000000. Alphanumeric, 20 positions; required. |
CC BIN High Range |
The ending number in a card bin range. Note: You must enter the full number of positions in the card number. For example, if the card number is 16 positions, the ending number in the card bin range must be 16 positions, such as 6055000000000000. Alphanumeric, 20 positions; required. |
CC BIN Type Business |
B indicates the card is a business card. This value is used to determine whether a VISA card is eligible for discounting. Alphanumeric, 1 position; optional. |
CC BIN Type Purchase |
P indicates the card is a purchase card. This value is used to determine whether a VISA card is eligible for discounting. Alphanumeric, 1 position; optional. |
CC BIN Type Corporate |
C indicates the card is a corporate card. This value is used to determine whether a VISA card is eligible for discounting. Alphanumeric, 1 position; optional. |
CC BIN Type Fleet |
F indicates the card is a fleet card. This value is used to determine whether a VISA card is eligible for discounting. Alphanumeric, 1 position; optional. |
Last Update Date |
The date when the card bin range record was last updated, in CYYMMDD format. Numeric, 7 positions; optional. |
Last Update Time |
The time when the card bin range record was last updated, in HHMMSS format. Numeric, 6 positions; optional. |
Require card security |
Defines whether a card security value is required for a card number that falls within this card bin range. See Credit Card Security Service (CID, CVV2, CVC2) for more information. Alphanumeric, 1 position; optional. |
The table below indicates the number of positions for the level II bin range, based on the type of credit card you wish discount.
For Credit Card: |
Level II Bin Range must be: |
Example |
VISA |
16 positions |
Create a level II bin range where the beginning number and ending number in the range is 16 positions. For example, if the level II bin range is 4788250000000000 - 4788260000000000. • If the VISA credit card is a business card (the CC bin type business field is set to B) or corporate card (the CC bin type corporate field is set to C) that falls within this range, it will receive the level II discount. • If the VISA credit card is a purchase card (the CC bin type purchase field is set to P) or fleet card (the CC bin type fleet field is set to F) that falls within this range, it will receive the level II and level III discount. |
MasterCard |
16 positions |
Create a level II bin range where the beginning number and ending number in the range is 16 positions. For example, if the level II bin range is 553150000000000 - 553160000000000. Any MasterCard credit card that falls within this range will receive the level II and III discount. |
American Express |
15 positions |
Create a level II bin range where the beginning number and ending number in the range is 16 positions. For example, if the level II bin range is 34333000000000 - 34334000000000. Any American Express credit card that falls within this range, will receive the level II discount. |
Credit card encryption: If you use credit card encryption, the credit card numbers in the Level II Bin Range file are not encrypted because the credit card information comes from an outside system.
Sending level II and III discounting information to the service bureau: When you process deposits, the system sends level II and level III discounting information to the service bureau if:
• the action code is:
• B: conditional deposit
• D: deposit
• R: refund
• the method of payment is:
• MC: Mastercard
• VI: Visa (Note: If the card type is a business or corporate card, the system sends level II discounting information only; if the card type is a purchase card, the system sends both level II and level III discounting information)
• AX: American Express
• the credit card number falls within a range of credit card numbers in the Level II Bin Range file. The Level II Bin Range file identifies those credit cards that are eligible for level II and level III discounting. It is your responsibility to populate this file with data from the service bureau.
Deposit Request message: For Batch Deposit Processing using CWIntegrate, the system sends level II and level III discounting information in the discountQualified XML tag in the Deposit Request XML Message (CWDepositRequest) sent to the service bureau.
Valid values are:
• LV2 = The deposit is eligible for level II discounting.
• YES = The deposit is eligible for level II and III discounting.
• NO = The deposit is not eligible for level II and III discounting.
Paymentech: Level III discounting with Paymentech is supported with the CWIntegrate version 3.0 Paymentech site.
• For Paymentech Batch Processing using a leased line or dial up/modem: the system sends level II discounting information in the Transaction File Product Record: Procurement Level 2. Additionally, if the method of payment in the Transaction File Detail Record is AX (American Express), the system sends the Transaction File Address Record to Paymentech.
• For Paymentech Batch Processing using CWIntegrate, the system sends level II and level III discounting information in the discountQualified XML tag in the Deposit Request XML Message (CWDepositRequest) sent to Paymentech.
Depending on the version of Paymentech you are using, you can:
• Process Paymentech Transactions Using CWIntegrate
• Process Paymentech Transactions Without CWIntegrate
Process Paymentech Transactions Using CWIntegrate
To process transactions between CWDirect and Paymentech using CWIntegrate:
• You must use Paymentech Online Processing Revision 6.0.
• You must use Paymentech Batch Processing 96-Byte Revision 1.7.1.
Transaction types: You can send the following transactions to Paymentech:
• online authorizations for credit card, debit (Switch) card, stored value card, or Bill Me Later transaction.
• batch authorizations for credit card, debit (Switch) card, stored value card, or Bill Me Later transaction.
• batch deposits for credit card, debit (Switch) card, stored value card, electronic check, or Bill Me Later transaction.
• batch stored value card activation
• batch stored value card authorization reversal
• interactive stored value card balance inquiry
For more information: See:
• Processing Authorizations and Deposits using CWIntegrate for more information on how to set up and process a transaction using CWIntegrate.
• CWIntegrate CWDirect/Paymentech Integration Reference for more information on the CWIntegrate site used to process online and batch transactions between CWDirect and Paymentech. This reference provides processing logic specifically for the CWDirect/Paymentech integration, setup information, and a layout of the messages and record formats.
• Stored Value Card Purchase and Activation for more information on activating a stored value card.
• Stored Value Card Balance Inquiry for more information on determining the remaining balance on a stored value card.
• Stored Value Card Authorization Reversal for more information on reimbursing a stored value card an unused authorization amount.
Process Paymentech Transactions Without CWIntegrate
To process transactions between CWDirect and Paymentech NOT using CWIntegrate:
• You must use Paymentech Online Processing Revision 4.0, using a leased line. The leased line for online authorizations is defined in the Online Authorization Socket Server job (SOCK).
• You must use Paymentech Batch Processing 96-Byte Revision 1.6.2, using a leased line or dial up/modem. You define the communication method in the Communication type field for the Paymentech service bureau.
Transaction types: You can send the following transactions to Paymentech:
• online authorizations for credit card.
• batch authorizations for credit card.
• batch deposits for credit card.
For more information: See:
• Paymentech Batch Processing 96-Byte Revision 1.6.2 Layouts for a file layout of data sent to and received from Paymentech for batch authorizations.
• Paymentech Online Processing Revision 4.0 Record Layouts for a file layout of data sent to and received from Paymentech for online authorizations.
• Working with Socket Server Jobs (SOCK) for more information on processing online authorizations using the socket server and async.
Additional Paymentech Processing
Regardless of the processing method you use to communicate with Paymentech, the following processing logic occurs for Paymentech.
Alternate Currency Pricing
When you send credit card authorization transactions to Paymentech for authorization, the system converts the local authorization amount into the alternate (foreign) amount if a currency code and conversion rate are defined in the Order Header Extended file and the Use Alternate Currency Pricing (H89) system control value is set to Y.
The authorization and deposit amounts in the Paymentech record layouts display in the alternate currency if the order is associated with an alternate currency.
When you are setting up Paymentech as an authorization and deposit service, please note these required settings for alternate currency pricing:
• Paytype cross reference (option 8 at the Work with Authorization Services Screen): Create a cross-reference for each pay type code for which you wish to receive credit card authorization and deposit, using the vendor pay code information supplied by Paymentech.
• Currency cross reference (option 12 at the Work with Authorization Services Screen): Create a cross-reference for each currency code you will use on orders receiving credit card authorizations and deposits, using the vendor currency code information supplied by Paymentech.
Deposit Authorization Number
During deposit processing:
• the authorization number may be returned as NOTDEP or notdep when you submit a previously authorized order (an order with an action code of D or a refund (a deposit with an action code of R) for deposit processing. In this case, the deposit is rejected and displays on the Resubmit Rejected Deposits Screen and the Unconfirmed Deposits Listing.
• the system may assign a new authorization number if the credit card was sent with an action code of B (authorization and deposit) during deposit processing.
You can review this authorization number in order inquiry at the following screens:
• Display Invoice Pay Method Screen (Reviewing Deposit Information): select F14, select F7, enter 5 next to an invoice
• Display Authorization History Screen: select F15, enter 8 next to the credit card payment method
Identifying Internet Orders
An internet order is determined in one of two ways:
• If you are using the MICROS e-commerce interface, the system loads an I in the Internet field on the order header when the order is created in CWDirect.
• An order is considered an internet order if the order type on the order matches the order type defined in the E-Commerce Order Type (G42) system control value.
The Transaction type field in the Paymentech transmission record indicates where the transaction originated. During authorization and deposit transmission to Paymentech, the system determines whether the transaction is for an internet order.
If the order is an internet order, the system updates the Transaction type field with 7 (indicating the order was placed over the web storefront) when transmitting the authorization to Paymentech for processing; otherwise the Transaction type field is updated with 1 (indicating the order was not placed over the web storefront).
Deferred/Installment Billing
Deferred or installment pay plans allow you to process deposits against orders at various intervals after you bill the order shipment. For example, you could offer "no payment for 60 days" or "four easy payments" to your customers.
Paymentech supports deferred or installment billing for credit card transactions. When you setup this service bureau, make sure the Exclude from FPO field is set to N. Optionally, the Force deposit for FPO field at the vendor response level can be set to Y. See Deferred/Installment Billing Setup for more information on deferred and installment billing processing.
Merchant ID: The merchant ID represents a division number to the Paymentech service bureau. The system uses the following hierarchy to determine the merchant ID number to send to Paymentech:
• Merchant # from the CC Paytype Cross Ref file.
• Merchant ID override from the Merchant ID Override file.
• Merchant ID from the Authorization Service file.
Transmitting and Receiving Deposits
Purpose: After you obtain an authorization for a credit card charge, you can ship the order to the customer and charge the credit card for the shipment. At this point, you use Processing Auto Deposits (SDEP) to transmit the deposit information to a deposit service for settlement.
Reprocess Authorizations Screen (RPAA)
Purpose: Run this recovery program if an error occurs when transmitting an Authorization file (either sending or receiving) or if you responded to an error with a C (to cancel the transmission) and there are stranded records in the Credit Card Authorization Transaction file (CCAT00).
This procedure enables you to resend all records that have not been sent or received and process the authorizations.
Note: When you reprocess authorizations, the system sends all authorization transactions that exist in the CC Authorization Transaction file to the authorization service, regardless if the order is a drop ship order or regular order.
Reprocessing authorizations or deposits: Before you use the Reprocess Authorizations screen (RPAA), Reprocess Drop Ship Authorizations Screen (RPDS), or Auto Deposit Screen (Send or Receive Deposits) to recover failed authorization or deposit transactions, you should first review the status of the records on the Work with Integration Process Control Screen and verify that the only records that are in a status other than Complete are the records that require reprocessing.
Selecting this option: Enter RPAA in the Fast path field at the top of any menu screen or select the Reprocess Authorizations option from a menu.
AAR0079 ENTER Reprocess Authorizations 10/31/95 10:17:48 Mail Order Company
Choose one of the following:
1. Transmit/Receive/Process Authorizations 2. Receive/Process Authorizations
Option
F3=Exit F12=Cancel
|
Retransmitting the Authorization File
Enter 1 in the Option field if you need to retransmit an Authorization file.
This option resends all records in the Authorization file (CCAT00) that have not been sent, regardless if the order is a regular order or drop ship order. These records have a status of *RDY in this file.
Records successfully sent have a status of *SENT.
The Enter Pick Options pop-up window appears when you select this option.
Enter Pick Options
Combine Customer Picks (Y/N) Complete Orders Only? (Y/N) Perform Best Way . . (Y/N) Override Ship via . .
|
This pop-up window gives you the same options you can select at Pick Slip Generation run-time.
Field |
Description |
Combine customer picks |
This value indicates whether the system will combine multiple orders for a single customer. For example, if the customer has two 1-item orders that can fit into one box, under normal cubing rules, the system would split them into two pick slips because they belong to different orders. Using this feature, however, the system combines them into a single pick slip. Valid values are: Y = Combine pick slips. N = Do not combine pick slips. Alphanumeric, 1 position; required. |
Complete orders only? |
This value indicates whether the system will ship orders that have been completely filled. Valid values are: Y = Ship orders that have been completely filled; do not ship orders with backordered items N = (Default): Ship full and partially filled (backordered) orders. Alphanumeric, 1 position; optional. |
Perform best way |
This value indicates whether the system should compare shipping rates and use the cheapest method of shipment for an order. The best shipper is the less expensive alternative to the designated shipper on the order. This value is based on the value in the Perform Best Way Shipping (C47) field in the System Control file. Valid values are: Y = Best way shipping will be used. The system determines which shipping method is best by calculating the lead time and freight charges for the shipper entered on the order/ shipping address and comparing this information to other shippers. Note: As pick slips are created during Pick Slip Generation, the cube of the pick is used to determine the extra weight (dunnage) to be added to the pick slip for packing materials. The extra weight is added to the weight of the pick and the total weight is rounded up to the next pound, before running best way shipping. N = Do not use best way shipping. Alphanumeric, 1 position; required. |
Override ship via |
This field allows you to replace the ship via code on the pick slip and ship all orders with this shipper. Enter a valid shipper code here, if you want all shippable orders being authorized by this service bureau to ship by this carrier. Ship via codes are defined in and validated against the Ship Via file. Numeric, 2 positions; optional. |
Receiving the Authorization File
Enter 2 in the Option field at the Reprocess Authorizations Screen (RPAA) if you need to receive the Authorization file from the service bureau and process the authorizations.
Records successfully received have a status of *RCVD and have pick slips if authorized or no AVS hold or card identification hold. Also, an Authorization History record is created when creating the Pick Control Header and Detail records and is updated when the authorization or decline is received. When an authorization is received, the Authorization History record is updated with the authorization code, authorization date, and authorization amount.
If an authorization is declined, no pick slips print and the Authorization History record is updated with the decline code.
The Enter Pick Options pop-up window appears when you select this option.
Complete this window as needed.
The Select Authorization Service pop-up window appears:
Select Auth Service
Opt Code Description
1=Select request
AMX AMERICAN EXPRESS DMG DMGT FDR FIRST DATA RESOURCES +
F3=Exit F6=Create |
Enter 1 next to the service bureau that you are receiving an authorization file from. The REPROCESS job is submitted and the following reports are produced:
• Credit Card Authorization Listing (AAR0063$)
• Address Verification Response List (if the service bureau provides AVS) (AAR0072$)
• Declined Drop Ships (AAR0065$)
• Pick/Authorization Listing (AAR0008$)
Address verification: If the service bureau provides AVS (address verification service), it evaluates the billing address on the credit card to ensure that it is valid. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the authorization service. This gives you the opportunity to contact the customer and obtain the correct address. For example, the order is placed on hold if the customer's address is correct, but the zip code is incorrect. Once you contact the customer and update the zip code, you may take the order off of hold through the Release Held Orders function.
Credit card identification: If the service bureaus also provides credit card identification (CID, CVV2, or CVC2), it evaluates the card identification number on the credit card to ensure that the credit card data from the transaction matches the data stored by the authorization service for that card. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the authorization service. Once you verify credit card ownership, you can take the order off of hold through Release Held Orders. See Credit Card Security Service (CID, CVV2, CVC2).
The credit card authorization is captured in the Authorization History file. The order will not be resent for authorization as long as the authorization is valid (based on the number of days in the Reauthorization days field in the Pay Type file).
Reprocess Drop Ship Authorizations Screen (RPDS)
Purpose: Run this recovery program if an error occurs when transmitting an Authorization file (either sending or receiving) for a drop ship order or if you responded to an error with a C (to cancel the transmission) and there are stranded records in the Credit Card Authorization Transaction file (CCAT00) for drop ship orders.
This procedure enables you to resend all records that have not been sent or received and process the authorizations.
Note: When you reprocess drop ship authorizations, the system sends all authorization transactions that exist in the CC Authorization Transaction file to the authorization service, regardless if the order is a drop ship order or regular order.
Reprocessing authorizations or deposits: Before you use the Reprocess Authorizations Screen (RPAA), Reprocess Drop Ship Authorizations screen (RPDS), or Auto Deposit Screen (Send or Receive Deposits) to recover failed authorization or deposit transactions, you should first review the status of the records on the Work with Integration Process Control Screen and verify that the only records that are in a status other than Complete are the records that require reprocessing.
Selecting this option: Enter RPDS in the Fast path field at the top of any menu screen or select the Reprocess Drop Ship Authorizations option from a menu.
AAR0157 ENTER Reprocess Drop Ship Authorizations 3/19/02 12:45:40 KAB Co.
Choose one of the following:
1. Transmit/Receive/Process Authorizations 2. Receive /Process Authorizations
Option
F3=Exit F12=Cancel |
Retransmitting the Authorization File
Enter 1 in the Option field if you need to retransmit an Authorization file.
This option resends all records in the Authorization file (CCAT00) that have not been sent, regardless if the order is a drop ship order or regular order. These records have a status of *RDY in this file.
Records successfully sent have a status of *SENT.
The Enter Drop Ship Options pop-up window displays when you select this option.
Enter Drop Ship Options
Print Drop Ship Purchase Orders Y (V/P/N)
Fax Picks to Vendors . . . . . N (Y/N)
|
This pop-up window gives you the same options you can select during Drop Ship Processing.
Field |
Description |
Print drop ship purchase orders |
Indicates whether or not drop ship purchase orders should be printed. However, drop ship purchase orders can be printed only for vendors whose Drop ship output field on the second Vendor screen is set to O = Purchase Orders. For vendors whose Drop ship output field is set to P (Picks) drop ship purchase orders will not be printed, regardless of the setting of the Print drop ship purchase orders field. N = The system will not print drop ship purchase orders. P = The system prints drop ship purchase orders in purchase order number sequence. The system uses the PO Print Program for PO Print in PO Sequence (C76) system control value to print drop ship purchase orders in purchase order number sequence. V = The system prints drop ship purchase orders in vendor number sequence. The system uses the PO Print Program (C64) system control value to print drop ship purchase orders in vendor number sequence. Note: The system also prints a drop ship invoice when you print a drop ship purchase order if the Print Drop Ship Invoice with PO (C85) system control value is set to Y. Alphanumeric, 1 position; required. |
Fax picks to vendors |
Indicates whether the drop ship pick slips or invoices should be faxed to the vendor instead of printed. If the FAX Available (B53) system control value is not set to Y, an error message displays at this screen; also, the Vendor's fax number is required in the Vendor file, or the fax will not be generated. Y = Drop ship pick slips should be faxed to the vendor. N or blank = Drop ship pick slips should not be faxed to the vendor; however, drop ship pick slips should be printed. Alphanumeric, 1 position; optional. |
Receiving the Authorization File
Enter 2 in the Option field at the Reprocess Drop Ship Authorizations Screen (RPDS) if you need to receive the Authorization file from the service bureau and process the authorizations.
The Select Auth Service pop-up window displays:
Select Auth Service
Opt Code Description
1=Select request
AMX AMERICAN EXPRESS DMG DMGT FDR FIRST DATA RESOURCES +
F3=Exit F6=Create |
Records successfully received have a status of *RCVD and have drop ship output (pick slip or purchase order) if authorized or no AVS hold or card identification hold. When an authorization is approved, the Authorization History record is updated with the authorization code, authorization date, and authorization amount.
If an authorization is declined, no drop ship output (pick slip or purchase order) prints and the Authorization History record is updated with the decline code.
Enter 1 next to the service bureau that you are receiving an authorization file from. The REPROCESS job is submitted and the following reports are produced:
• Credit Card Authorization Listing
• Address Verification Response List (if the service bureau provides AVS)
• Drop Ship Purchase Order List (if the drop ship output is purchase orders)
• Drop Ship Invoice/Pick Slip (if the drop ship output is pick slips or the drop ship output is purchase orders and the Print Drop Ship Invoice with PO (C85) system control value is set to Y)
• Drop Ship Purchase Order (if the drop ship output is purchase orders)
Address verification: If the service bureau provides AVS (address verification service), it evaluates the billing address on the credit card to ensure that it is valid. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the authorization service. This gives you the opportunity to contact the customer and obtain the correct address. For example, the order is placed on hold if the customer's address is correct, but the zip code is incorrect. Once you contact the customer and update the zip code, you may take the order off of hold through Release Held Orders. See Address Verification Service (AVS).
Credit card identification: If the service bureaus also provides credit card identification (CID, CVV2, or CVC2), it evaluates the card identification number on the credit card to ensure that the credit card data from the transaction matches the data stored by the authorization service for that card. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the authorization service. Once you verify credit card ownership, you can take the order off of hold through Release Held Orders. See Credit Card Security Service (CID, CVV2, CVC2).
The credit card authorization is captured in the Authorization History file. The order will not be resent for authorization as long as the authorization is valid (based on the number of days in the Reauthorization days field in the Pay Type file).
| Part D: Setting Up Authorization Services | Contents | SCVs | Search | Glossary | Reports | XML | Index | Credit Card Authorization Listing |
SO04_01 CWDirect 18.0 August 2015 OTN