Using the Credit Card Authorization Interface
Purpose: The Credit Card Authorization Interface allows you to transmit and receive the information required to authorize your credit card orders and deposit amounts charged to the credit cards.
Note: In this topic, 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 Cards 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
• Transmitting and Receiving Deposits
For more information: See:
• Reprocess Authorizations Screen (RPAA)
- Retransmitting Authorizations
• Reprocess Drop Ship Authorizations Screen (RPDS)
- Retransmitting Authorizations
• Working with Required Responses (WREQ)
- Required Response Processing
- RESP.log
- Work with Required Responses Screen
Order Management System integrates with the following service bureaus.
Service Bureau |
Transactions Processed |
Cybersource using Point-to-Point integration |
• Token request for credit cards and debit (switch) cards. • Authorization request for credit cards and debit (switch) cards. Types of authorization are online, batch, and token and authorization. • Deposit request for credit cards and debit (switch) cards. Types of deposit are debit, credit, and authorization and debit. • Authorization reversal request for credit cards and debit (switch) cards. The integration also supports: • Level II and level III processing • Multicurrency • Card identification (CSV/CSP) for online transactions • Verified by Visa and MasterCard Secure Code programs • Full address verification (AVS) • Deferred and installment billing |
Oracle Retail Customer Engagement using Point-to-Point integration |
• Activation request for stored value cards. • Authorization request for stored value cards. Types of authorization are online and batch. • Deposit request for stored value cards. • Credit (return) request for stored value cards. • Balance inquiry request for stored value cards. • Authorization reversal request for stored value cards. |
PayPal integration using a direct connection |
Deposit request for PayPal payment. Types of deposit are debit and credit. |
Purpose: 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 an Integration Layer Process for more information on processing transactions between Order Management System and a service bureau via an integration layer process.
• Processing Authorizations and Deposits Using Point-to-Point Communication for more information on processing transactions between Order Management System and a service bureau via point-to-point communication. Specifically:
- Customer Engagement Stored Value Card Integration for more information on the Oracle Retail Customer Engagement messages used to process stored value card transactions between Order Management System and the Oracle Retail Customer Engagement system using point-to-point communication.
- Cybersource Point-to-Point Integration for more information on the Cybersource messages used to process token, authorization, authorization reversal, and deposit transactions between Order Management System and the Cybersource system using 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. |
|
The setting of this system control value and the Invoice Consolidation Method (E29) system control value controls the number of authorizations processed for an order during batch authorization. • If Consolidated Invoice (B49) is unselected, the system generates a separate authorization request for each pick associated with the order. • If Consolidated Invoice (B49) is selected, the system: - If the Invoice Consolidation Method (E29) is set to ORDER, generates an authorization request across all picks for the order (across all ship tos on the order). - If the Invoice Consolidation Method (E29) is set to ORDER SHIP, generates an authorization request across all picks for each order ship to on the order. See Authorizations When Consolidating Invoices for more information. |
|
Defines whether the system performs online credit card authorization during order entry. See 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 select this field, 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. |
Number Assignment |
Description |
Assigns the next available number to the credit card authorization. |
|
Assigns the next available number to the merchantFileTrace value in the Authorization Request XML Message (CWAuthorizationRequest) and Deposit Request XML Message (CWDepositRequest) sent to the service bureau. Order Management System updates the Reference ID field in the Integration Process Control table with this value. Note: • 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 Order Management System 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: Integration Layer (via an integration layer process) or Payment Link (point-to-point)
- if the communication type is Integration Layer, the integration process control job used to transmit data between Order Management System and the service bureau via an integration layer process
- valid pay types
- response codes (vendor responses, AVS responses, and CID responses)
- currency codes
- merchant IDs for individual entities within your company
- whether the order originated as an internet order
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.
Communication Method
The Communication type field for the service bureau indicates how you send transactions between Order Management System and the service bureau.
• Integration Layer = Transactions are sent between Order Management System and the service bureau using an integration layer process. Integration layer jobs provide the settings required to send transactions between Order Management System and the service bureau. See Integration Layer Jobs and Processing Authorizations and Deposits using an Integration Layer Process.
• Payment Link = Transactions are processed between Order Management System and the service bureau using a point-to-point integration. Settings in the Interface Properties provide the point-to-point service that is executed and the settings used to connect to the service bureau. See Processing Authorizations and Deposits Using Point-to-Point Communication.
.IL service bureau: To send transactions to the service bureau using an integration layer process or Point-to-Point communication, create a service bureau using the service code.IL and enter a value in the following fields:
• Application: ATDP (authorization and deposit)
• Merchant ID: INTEGRATION LAYER
• Charge description: .IL
• Media type: C (communications)
Enter the .IL service bureau in the Primary authorization service field for each service bureau that you create.
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.
If you wish to generate pick slips only for orders that contain pre-paid payment methods and/or credit cards that have received an authorization, you can create a pick slip generation template with the Preauthorized orders only field selected.
The following integration layer jobs are used to send authorizations and deposits to a service bureau via an integration layer process. The system uses these integration layer jobs when the Communication type field for the service bureau is Integration Layer.
Integration Layer Job |
Description |
Online Authorization |
When active, the Online Authorization integration layer job generates an Authorization Request XML Message (CWAuthorizationRequest) in online format and sends the message to the service bureau. The service bureau sends an Authorization Response XML Message (CWAuthorizationResponse) back to the integration layer job. |
Batch Authorization |
When active, the Batch Authorization integration layer job generates an Authorization Request XML Message (CWAuthorizationRequest) in batch format and sends the message to the service bureau. The service bureau sends an Authorization Response XML Message (CWAuthorizationResponse) back to the integration layer job. |
Deposit |
When active, the Batch Authorization integration layer job generates a Deposit Request XML Message (CWDepositRequest) in batch format and sends the message to the service bureau. The service bureau sends a Deposit Response XML Message (CWDepositResponse) back to the integration layer job. |
For each integration layer process, make sure you define:
• an outbound queue manager and queue (if using advanced queuing) to send the request to the service bureau.
• an inbound queue manager and queue (if using advanced queuing) to receive the response from the service bureau.
Note: You can only define one outbound and inbound queue for each integration layer process. If you create multiple queues, the system sends and receives data in the queue whose Sequence number is 1; all other queues are ignored.
For more information:
• See Working with Integration Layer Processes (IJCT) for more information on setting up an integration layer process.
• See Processing Authorizations and Deposits using an Integration Layer Process for more information on communicating with a service bureau via an integration layer job.
• See Stored Value Card Overview and Setup for more information on the additional integration layer jobs required for a stored value card pay type.
When processing payment transactions, you can define a proxy server to act as an intermediary in order to increase security. Order Management System sends transactions to the proxy server and the proxy server sends the transactions along to the payment processor. You can define the proxy server properties in Working with Admin Properties (CPRP).
Property Name |
Description |
PROXY_HOST |
The IP address and port number used to connect to the proxy server during payment processing. Note: If these properties are blank, the system does not route payment transactions through a proxy server and instead calls the payment processor directly. |
PROXY_PORT |
In order to respond to Order Management System jobs that may require user intervention to proceed, you must set up the notify properties in Working with Admin Properties (CPRP).
Why would a job require user intervention?
• An error occurred during processing
• The job is used to send transactions to another system and communication failures occur before the transmission completes
Which types of job require user intervention?
• Stored Value Card (activation, balance inquiry or authorization reversal)
• Authorization (batch only, for all card types)
• Deposit
Property Name |
Description |
RESPONSE_RETRIES |
The number of times Order Management System looks for a response to a job that requires user intervention before using the default response in order to proceed with the job. For example, if this setting is 5, Order Management System will look for a user response five times, waiting 60 seconds between each time. |
RESPONSE_EMAILS |
The list of email addresses that receive the Response Required email when a job requires user intervention. Each email address entered must be separated by a semi-colon (;). For example: email1@add.com;email2@add.com. |
For more information: See Working with Required Responses (WREQ) for more information on the steps performed when a job requires user intervention.
Logging Properties
Order Management System writes messages to the RESP.log file when a job requires user intervention. The Logging Properties in Working with Admin Properties (CPRP) contain settings for the RESP.log.
Property Name |
Description |
RESP_LOG_LEVEL |
The level of logging for the RESP.log. Valid values are: • DEBUG = Generates fine-grained informational events. • INFO = Generates informational messages. • WARN = Generates warning messages. • ERROR = Generates messages that indicate a serious issue. • FATAL = Only generates messages that will cause the application to abort. The delivered logging level is INFO. |
RESP_MAXBACKUP_ DAYS |
The number of days to store an archived RESP.log before it is deleted. The delivered number of days is 30, indicates the system stores one month of RESP.log files. Order Management System stores one RESP.log per day. Files older than the current day are stored in zip format with the name: RESP.YYYY-MM-DD.log.zip. |
How Credit Cards are Authorized
Purpose: The information required to authorize a credit card is transmitted 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 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 Batch or On-line or Batch. See Using Batch Authorization.
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 table, which can be viewed through standard Order Inquiry (select Payments, then select Pay Plan Summary for 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 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 table). 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 (ERHO) menu option and resend for authorization or cancel the order. In this situation, you can also generate an email to the customer if the Credit Card Decline Email Program (K53) specifies a value.
• 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 table). 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 (ERHO) menu option 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 table). 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 (ERHO) menu option and resend for authorization or cancel the order.
For more information: See Defining Vendor Response Codes and Establishing Cancel Reason Codes (WCNR).
Credit Card Authorization Reversal
Overview: When you process a cancellation associated with a credit card payment or deactivate a credit card payment, the system looks at the setting of the Send reversal field for the service bureau defined for the credit card pay type.
If the Send reversal field is selected, the system voids that authorization and reimburses the original authorization amount to the credit card.
Note: You can also process credit card authorization reversals for eligible open Authorization History records by running the REVERSE Send Reversals for Expired Authorizations periodic function.
Credit Card Authorization Reversal Process
1. |
You process a cancellation associated with a credit card payment or deactivate a credit card payment associated with a service bureau whose Send 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 Reprint/Void 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. • receiving a REJECT response from Cybersource Decision Manager; see Cybersource Decision Manager Fraud Scoring, specifically, Cybersource Decision Manager Reject 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, 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 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 time defined for the Authorization History record to determine the age of the authorization. You can review the authorization time on the Authorization History Details Window. Mutliple payment methods: If the order contains one or more stored value card and/or credit card payments, the system performs authorization reversal for each eligible payment method. 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 table for the authorization amount to reimburse. Auth History SVC Reversal table: • 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 creates an authorization reversal download trigger for the credit card reversal. You can view all download triggers in the IL Outbound Trigger table in the Working with Outbound Interface Transactions (WOIT) menu option. Each authorization reversal download trigger in the IL Outbound Trigger table contains a: • File code: indicating the type of information to download and which IL process job processes the trigger. For authorization reversal download triggers, the File code is AHR. • Key: indicating the specific record to download. For AHR download triggers, the Key identifies the specific company, order number, order payment method sequence number, authorization sequence number, and authorization reversal sequence number in the SVC Authorization Reversal table. For example, the Key 00700003595001001001 indicates the authorization reversal information is located in company 7 for order number 3595, order payment method sequence number 1, authorization sequence number 1, and authorization reversal sequence number 1. • Capture type: indicating the type of activity performed against the record. AHR download triggers are always capture type A indicating the authorization reversal was created. Note: If the credit card authorization reversal was created because the system received a REJECT response from Cybersource Decision Manager, the system does not create an authorization reversal download trigger and instead generates a Credit Card Authorization Reversal Request immediately as defined in step 8. |
6. |
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. |
7. |
The system looks for unprocessed AHR download triggers to process, based on the setting of the Use Activation / Reversal Batch Processing (I50) system control value. • If this system control value is selected, the system does not process the AHR download triggers until you submit the batch process using the Transmitting Activation and Reversal Transactions (SSVC) menu option or the SVCREV periodic function (program name PFR0077). • If this system control value is unselected, the SVC Reversal integration layer job monitors for AHR download triggers to process at defined intervals, based on the Outbound delay time. The system: • looks for AHR download triggers with the File code AHR and a status of R Ready. • determines which credit card authorization reversal to process, based on the Key field for the authorization reversal download trigger. |
8. |
For each authorization reversal download trigger, the system generates a Credit Card Authorization Reversal Request. If you are using the Cybersource Point-to-Point Integration, the system generates the Cybersource Authorization Reversal Request (ccAuthReversalService) XML Message. |
9. |
Order Management System processes the authorization reversal response accordingly. If you are using the Cybersource Point-to-Point Integration, the system receives the Cybersource Authorization Reversal Response (ccAuthReversalService) XML Message. |
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 SVC Authorization Reversal table 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 table.
You can review the credit card authorization reversal at the Display Authorization Reversals Screen. The approved reversal will have a Response and 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 approved reversal will have a blank Response and an 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 Order Management System 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 SVC Authorization Reversal table.
• Does not create an order transaction history message.
You cannot resent an authorization reversal request to the service bureau.
Purpose: Batch Authorization is used to authorize credit cards 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 Batch or Online or Batch.
Online authorization grace period: The system allows a 2 day grace period to receive a response from the service bureau if the status of an online authorization for an order is *RDY, *SENT, or *RCVD. To determine the grace period, the system takes the current date - the authorization sent date to determine the number of days. Once the 2 day grace period is passed, the system declines the transmission and you can resend the credit card for authorization during order maintenance or pick slip generation.
How the orders are authorized: The authorization information is captured in the CC Authorization Transaction (CCAT00) table 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 data for the records in the CC Authorization Transaction table is transmitted to the service bureau.
• If the Communication type field for the service bureau is Integration Layer, the system sends authorization transactions to the service bureau using the queues defined for the Authorization integration layer job. See Processing Authorizations and Deposits using an Integration Layer Process.
• If the Communication type field for the service bureau is Payment Link, the system sends authorization transactions to the service bureau using a point-to-point integration. You must define communication settings in the Interface Properties. See Processing Authorizations and Deposits Using Point-to-Point Communication.
When are pick slips printed? Pick slips and pull sheets are printed after the authorizations are received from the authorization service.
CC Authorization Transaction table: When you send credit card information to the service bureau, the system also creates a record in the CC Authorization Transaction table.
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 service bureau. Valid values are: • *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. See the Data Security and Encryption Guide for an overview. |
Status |
The status of the transaction. Valid values are: • *RDY = the transaction is ready to be sent to the service bureau. • *SENT = the transaction has been sent to the service bureau and a reply has not yet been received. • *RCVD = the transaction has been sent to the service bureau 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. |
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. 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, if 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 from the system control value to the credit card. If an authorization number is not defined in this 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 table.
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 pick 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 table 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 table, 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 printed 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 table.
This method allows you to limit the number of authorization and deposit transactions required for the order, and reduces your transaction fees to the service bureau.
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 table 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 service bureau will reauthorize the order for the correct amount prior to accepting the deposit.
Authorization history: Once a response is received from the service bureau, the system creates a record in the Authorization History table. 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 from 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 be blank. |
Auth date |
The date the credit card was authorized. |
Sent date |
The date you sent the credit card information to the service bureau for authorization. |
Auth number |
The number used to authorize the credit card. |
Vendor response |
The authorization response for the credit card from the service bureau. The system looks at the Credit Card Vendor Response table 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 service bureau. The system looks at the Credit Card Vendor Response table to find a match to the card security response code from the service bureau. 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 service bureau. The system looks at the Credit Card Vendor Response table to find a match to the AVS response code from the service bureau. 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. |
When credit card charges are approved (authorized):
• pick slips print (because the items can be shipped)
• the status of the records in the Authorization table is set to *RCVD
• the system updates the Authorization History table 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 removes any pick slip preparation from the order and reevaluates the order for pick slip preparation since the items cannot ship
• the order appears on the “Declined” version of the Credit Card Authorization Listing
• the system updates the Authorization History table 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 service bureau cannot process the authorization, pick control records for the credit card orders requiring authorization will remain in a pending status. Pick slips will not print 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 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, select Address verification in the Authorization Service table, define each possible response in the Vendor Response table, and define the hold codes in the Order Hold Reason table (for AVS responses that require the order to be held). See Defining Authorization Services (WASV), and Defining Vendor Response Codes. Also, see 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 table). If so, the system removes pick slip preparation from the order. 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 select this field, 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 (ERHO) menu option 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 table. 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 table, 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 service bureau 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.
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 service bureau whether a card security value is present on the credit card.
• 1 (Value present) = 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 (Value illegible) = the card security value is present on the credit card, but is illegible. In this transaction, the card security value is blank.
• 9 (No value) = 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; no message is written to Order History. 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.
E-Commerce orders: If the card security value and card security presence are passed for an e-commerce order, the system clears the values and does not pass them to the order. See 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 table). If so, the system removes pick slip preparation from the order. You must contact the customer to confirm credit card ownership, then take the order off of hold through the Release Held Orders (ERHO) menu option. See Hierarchy for Placing the Credit Card On Hold.
Reviewing the card security response: The card security identification response received for the authorization is stored in the Vendor response 2 field in the Authorization History table. 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 table, and define the hold codes in the Order Hold Reason table (for card security identification responses that require the order to be held). See Defining Authorization Services (WASV) and Defining Vendor Response Codes. Also, see Establishing Cancel Reason Codes (WCNR).
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.
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 Order Management System in the Inbound Order XML Message (CWORDERIN). |
5. |
Order Management System creates the order and: • updates the E-Commerce indicator field in the Order Payment Method table with the electronic commerce indicator. • updates the Authentication value field in the Order Payment Method table with the authentication value. |
6. |
During authorization and deposit processing, Order Management System 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. Order Management System will not format the authentication verification value it receives from the web storefront. |
7. |
The service bureau sends an authentication response back to Order Management System in the Authorization Response XML Message (CWAuthorizationResponse) and Deposit Response XML Message (CWDepositResponse). However, the response is not stored in any Order Management System table. |
Credit card authentication process:
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.
| Setting Up Authorization Services | Contents | SCVs | Search | Glossary | Reports | Solutions | XML | Index | Reprocess Authorizations Screen (RPAA) |
SO04_01 OROMS 17.0 2018 OTN