Setting Up Authorization Services

Topics in this part: The following topics describe the functions available to define the credit card authorization services that your company uses.

• Reprocess Authorizations Screen (RPAA)

•  Reprocess Drop Ship Authorizations Screen (RPDS)

•  Working with Required Responses (WREQ)

• Reset Authorizations (RSAA) describes how to reset records in the Credit Card Authorization Transaction table from a *SENT status to a *RDY status so that they can be resent to the authorization service.

• Defining Authorization Services (WASV) shows you how to define the authorization services that your company uses.

• Defining Authorization Service Countries shows you how to cross-reference your country codes to the country codes used by the service bureau. You can also indicate whether the service bureau performs address verification for the country.

• Defining Vendor Paytype Codes shows you how to cross-reference your payment codes to the payment codes used by the service bureau.

• Defining Vendor Response Codes shows you how to define the codes your service bureau uses to identify whether a credit card is approved or declined, and how to have the system place orders on hold based upon the vendor response code.

• Defining Merchant ID Overrides describes how to set up merchant ID overrides for different entities within your company.

• Defining Authorization Service Currencies describes how to set up cross references for your company's currency codes and the codes used by a service bureau.

• Performing Online Credit Card Authorizations provides an overview on online credit card authorization and required setup.

• Performing Batch Authorization (SATH) describes how to send credit cards up for batch authorization by the associated ship via.

• Printing the Online Credit Card Authorization List (PATL) describes how to print the Online Authorization Listing.

Defining Authorization Services (WASV)

Purpose: Use the Work with Authorization Services 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:

  • country codes

  • 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.

You can use the same service bureau to process your authorizations and deposits, or you can use one service for authorizations and another for deposits.

Important:

Use the Payment Configurations option in Modern View to configure or work with any payment processing through EFTConnect. You would use Work with Authorization Services in Classic View only for other authorization services, such as for stored value cards (gift cards). You cannot create, change, or delete an authorization service that uses EFTConnect through the Work with Authorization Services option in Classic View.

In this topic:

• Deferred/Installment Pay Plans

• Identifying Internet Orders

• Work with Authorization Services Screen

• First Create Authorization Services Screen

• Second Create Authorization Service Screen

• Work with External Authorization Service Screen

Deferred/Installment Pay Plans

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.

In order to set up deferred or installment pay plans, you must have the Deferred and Installment Billing (F51) system control value must be selected. See Deferred/Installment Billing Overview for more information on deferred and installment pay plans and how to set them up in Order Administration.

Identifying Internet Orders

An internet order is determined in one of two ways:

• If using the E-Commerce Interface the system loads an I in the Internet field on the order header when the order is created in Order Administration.

• An order is considered an internet order if the order type on the order matches the E-Commerce Order Type (G42) system control value.

• Mail = Mail order.

• Phone = Telephone order.

• Internet = Web order.

To determine where the order originated, the system:

• looks at the value in the Internet order field in the Order Header table. If this field is set to I, the order is a web order.

• determines if the order type for the order matches the E-Commerce Order Type (G42) system control value. If the order type matches, the order is a web order.

• looks at the Forecasting order category field in the Order Type table. If this value is 1, the order is a mail order. If this value is 2, the order is a phone order.

Work with Authorization Services Screen

How to display this screen: Enter WASV in the Fast path field at the top of any menu screen or select Work with Authorization Services from a menu.

Field	Description
Code	The code to identify the service bureau. Enter a full or partial code and select OK to display service codes in alphanumeric order, starting with your entry. Alphanumeric, 3 positions; optional.
Application	The type of activity performed by the service bureau. Valid values are: Auth/Deposit = The service bureau authorizes card charges and deposits dollar amounts billed to cards Authorization = The service bureau only authorizes card charges. Deposit = The service bureau only deposits dollar amounts billed to cards. Optional.
Description	The name of the service bureau. Alphanumeric, 30 positions; optional.
Merchant	The account number assigned by the service bureau to identify transmissions to/from your company.  This is the default ID number; you can also specify separate ID numbers for each entity in your company, and/or to use for orders using deferred or installment billing. Alphanumeric, 20 positions; optional.

Screen Option	Procedure
Change an authorization service record	Select Change for a service to advance to the Change Authorization Services Screen. At this screen you can change any information except the Service code. See the First Create Authorization Services Screen for field descriptions. Important: You cannot use this option to change an existing authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.
Delete an authorization service record	Select Delete for a service to delete it. Important: You cannot use this option to delete an existing authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.
Display an authorization service record	Select Display for a service to advance to the Display Authorization Services Screen. You cannot change any information at this screen. See the First Create Authorization Services Screen for field descriptions.
Work with country codes	Select Country for a service to add, change or delete the country codes recognized by the service bureau; see Defining Authorization Service Countries.
Work with vendor paytype codes	Select Paytypes for a service to add, change, delete or display the pay type codes recognized by the authorization service. See Defining Vendor Paytype Codes.
Work with vendor responses	Select Responses for a service to add, change, display or delete the response codes you receive from the service and the actions to take for each. See Defining Vendor Response Codes.
Work with merchant ID overrides based on entity	Select Merchant ID Override for a service to add, change, or delete merchant ID overrides by entity. See Defining Merchant ID Overrides.
Work with currency codes	Select Currency for a service to add, change, or delete cross-references between the currency codes used in your company and by the authorization service. See Defining Authorization Service Currencies.
Work with external authorization service settings	Select External Service to advance to the Work with External Authorization Service Screen. External Authorization Service Access (B25) authority is required.
Create an authorization service	Select Create to advance to the First Create Authorization Services Screen. Important: You cannot use this option to create an existing authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.

First Create Authorization Services Screen

Purpose: Use this screen to define a service bureau on your system. The Authorization Service record contains information that identifies your company to the service bureau and the parameters that you must include in the transmission to the service bureau.

Each service bureau requires its own information. Not all fields are applicable for each service.

Important:

You cannot use this screen to create a new authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.

How to display this screen: Select Create at the Work with Authorization Services Screen.

Field	Description
Service Code	The code to identify the service bureau. Foreign credit cards: In order to process foreign credit cards separately at billing, you must define a deposit service with a code of PRE, and then define PRE as the deposit service in the Pay Type table. See Processing Auto Deposits (SDEP) for more information on setting up a different process for foreign credit cards. Point-to-Point communication: If you are using point-to-point communication, the Service code must be a specific value for the integration: Oracle Retail Customer Engagement integration: To use the Customer Engagement Stored Value Card Integration, enter RLT. Alphanumeric, 3 positions. Create screen: required. Change screen: display-only.
Application	The type of activity performed by the service bureau. Valid values are: Auth/Deposit = The service bureau authorizes card charges and deposits dollar amounts billed to the cards. Authorization = The service bureau only authorizes card charges. Deposit = The service bureau only deposits dollar amounts billed to cards. Note:  PayPal should have the Application type set to Auth/Deposit. Required.
Merchant ID	The account number assigned by the service bureau to identify transmissions to/from your company. This ID is a default. You can also identify merchant IDs to use for depositing deferred or installment pay plans (as opposed to regular deposits) below. Similarly, you can set up overrides for different entities in your company, including deferred or installment overrides. See Defining Merchant ID Overrides. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 positions; optional.
Charge description	A description that identifies your company's product line or the type of service performed. Alphanumeric, 20 positions; optional.
Deferred merchant ID	The account number assigned by the service to identify transmission of deferred pay plan transactions for deposit. See Deferred/Installment Billing Overview for more information on deferred and installment billing, and see Processing Auto Deposits (SDEP) for more information on processing deposits. You can also set up overrides for different entities in your company, including deferred or installment overrides. See Defining Merchant ID Overrides. Alphanumeric, 20 positions; optional.
Installment merchant ID	The account number assigned by the service to identify transmission of installment pay plan transactions for deposit. See Deferred/Installment Billing Overview, and see Processing Auto Deposits (SDEP). You can also set up overrides for different entities in your company, including deferred or installment overrides. See Defining Merchant ID Overrides. Alphanumeric, 20 positions; optional.
	The service bureau assigns values to the following fields:
Signon	A code required to sign on to the service bureau. Case-sensitive. Alphanumeric, 10 positions; optional.
Receiving code	A code that identifies your company to the service bureau. Alphanumeric, 10 positions; optional.
Password	A password required by the service bureau. Case-sensitive. Alphanumeric, 10 positions; optional.
Start up information	Startup text that identifies your company to the service bureau. Alphanumeric, 10 positions; optional.
Presenter's ID Auth / Deposit	A code required to sign on to the service bureau. Separate fields allow you to define a presenter’s ID for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the presenter’s ID in the first field. Alphanumeric, 10 positions; optional.
PID password Auth / Deposit	A password required to sign on to the service bureau. Separate fields allow you to define a PID password for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the PID password in the first field. Alphanumeric, 10 positions; optional.
Submitter's ID Auth / Deposit	A code required to sign on to the service bureau. Separate fields allow you to define a submitter’s ID for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the submitter’s ID in the first field. Alphanumeric, 10 positions; optional.
SID password Auth / Deposit	A password required to sign on to the service bureau. Separate fields allow you to define a SID password for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the SID password in the first field. Alphanumeric, 10 positions; optional.
Sub code	A code required to sign on to the service bureau. Alphanumeric, 10 positions; optional.
Exclude from FPO (Exclude from flexible payment option)	Indicates whether to exclude orders associated with this service bureau from a deferred or installment pay plan. If an order includes any pay type whose authorization service has this field selected, the order is not eligible for a pay plan. Valid values are: Selected = exclude from pay plan Unselected = do not exclude from pay plan See Deferred/Installment Billing Overview for information on how the system determines whether an order is eligible for a pay plan in order entry.
Void auth at deposit	Defines whether any unused portion of an authorization should be voided at deposit time for: A credit card pay type, or A stored value card, when the External Payment Service is used. Valid values are: Selected = The system voids any unused portion of an authorization for a credit card pay type at deposit time. Order Administration will need to obtain an additional authorization for any subsequent deposits for the order. Unselected = The system retains any unused portion of an authorization for a credit card pay type at deposit time. See Void Unused Authorization After Initial Deposit for processing details. Important: Your end payment processor must support split shipments for you to set this flag to N.  Stored value card pay types when not using the External Payment Service: The setting of the Retain Unused Stored Value Card Authorization After Deposit (J21) system control value defines whether the system automatically voids a partially deposited stored value card authorization when the External Payment Service is not in use. See Stored Value Card Deposits for processing details.
Send reversal	Defines whether the service bureau supports authorization reversals for credit card and stored value card payments. Valid values are: Selected = The service bureau supports authorization reversal processing for credit card and stored value card pay types. Unselected = The service bureau does not support authorization reversal processing for credit card or stored value card pay types. Regardless of the setting of this field, you can still perform stored value card authorization reversals when the card is deactivated; see Stored Value Card Authorization Reversal.
Supports Auth Resubmission	Indicates whether to resubmit failed authorization and deposit requests for credit cards through the External Payment Service. When the request is for authorization and deposit of a failed deposit request: CyberSource: The subsequentAuthReason in the authorization and deposit request is set to 1 if the Supports Auth Resubmission flag is selected; otherwise it is set to 3. Note:  If the credit card number changes since the initial deposit request, then the subsequentAuthReason is set to 3, since it is not considered a subsequent authorization and deposit request. External Payment Service: The subsequentAuthReason is set to RESUBMIT; otherwise, if the Supports Auth Resubmission flag is not selected, the subsequentAuthReason is set to REAUTH. Important: Select this flag only if your payment processor supports merchant-initiated resubmission of failed deposits.

Second Create Authorization Service Screen

Important:

You cannot use this screen to create a new existing authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.

How to display this screen: Select OK at the First Create Authorization Services Screen.

Field	Description
Media type	The method by which the data is transmitted to the service bureau. Valid value is Communication. Optional.
Batch/Online	A code that indicates whether transactions are transmitted to/received from the service bureau immediately (online) as each order is entered, or whether groups of transactions are transmitted to/received from the service bureau at predefined times during the day (in batch). Valid values are: Batch = Transactions are grouped and transmitted to/received from the service bureau at predefined times throughout the day. On-line = Transactions are transmitted to/received from the service bureau immediately for each order. On-line or Batch = Transactions are transmitted to/received from the service bureau immediately if the order is eligible for online authorization. Any order that does not receive an authorization immediately is grouped and transmitted to/received from the service bureau at predefined times. Optional.
Active production system	Indicates whether you are processing in a live environment (production) or in a testing environment.    Valid values are: Selected = Transactions are being processed in a live environment. Unselected = Transactions are being processed in a testing environment.
Installment billing?	Indicates if the service bureau supports installment billing of credit cards. Installment billing plans are typically established for high cost items. Note:  This field is informational only and is not used to set up an installment pay plan in Order Administration. Valid values are: Selected = The service bureau supports installment billing. Unselected = The service bureau does not support installment billing.
Immediate response	Indicates whether a response from the service bureau is received immediately for each authorization transaction. Valid values are: Selected = Responses from the service bureau are received immediately for each transaction. Unselected = Responses from the service bureau are not received immediately (delayed turnaround).
Immediate deposit	Indicates whether the service bureau sends a detailed response to Order Administration. Valid values are: Selected = The service bureau does not send a detailed response to Order Administration; Order Administration marks the transaction as received and subsequently confirmed. Unselected = The service bureau sends a detailed response to Order Administration; Order Administration waits for the response based on the Wait time defined for the associated integration layer job.
Keep history information?	Indicates whether transactions sent to the service bureau will be kept online. Typically, this feature is used in test environments. Valid values are: Selected = Keep the transaction records on-line. Unselected = Do not keep the transaction records on-line.
Selected for deposit	Indicates whether the service bureau is included in the next deposit run. By default, all service bureaus are selected for deposit; however, you can remove a service bureau from the next deposit run at the Select Auth Service for Deposit Screen in Processing Auto Deposits (SDEP). Once you submit the deposit run, the system reselects all service bureaus for the next deposit run. Valid values are: Selected (default) = The system includes the service bureau in the next deposit run. Unselected = The system does not include the service bureau in the next deposit run. This field displays as unselected only if you are reviewing this screen at the same time a deposit run is submitted that does not include this service bureau. Display-only.
Address verification	Indicates whether you will be using the Address Verification Service provided by the service bureau to verify the customer's address and credit card number. Valid values are: Selected = Perform address verification Unselected = Do not perform address verification
Decline days	The number of days to hold a declined credit card charge on the system before sending it for an authorization again. This field is not implemented. See Defining Vendor Response Codes for setup information. Numeric, 3 positions; optional.
Industry format code	A code that is assigned by the service bureau to identify your company type. Use this field to enter your DBA number. Alphanumeric, 5 positions; optional.
Primary authorization service	The primary service bureau that the service bureau uses for its transmission setup. Orders sent to this service bureau are redirected to the primary service bureau defined in this field. If this field is left blank, the data created for this service bureau will be used. Alphanumeric, 3 positions; optional.
Deposit phone #	The telephone number associated with the deposit service bureau. Informational only. Numeric, 11 positions; optional.
Authorization phone #	The telephone number associated with the authorization service bureau. Informational only. Numeric, 11 positions; optional.
Communication type	Indicates the method of communication used to transmit transactions between Order Administration and the service bureau. The only valid value is Payment Link, in which the system sends transactions to the service bureau using a point-to-point integration. You must define communication settings in Working with Customer Properties (PROP). The system also uses the Activation and Authorization Reversal integration layer jobs to process stored value card triggers. Optional.
Response check frequency	Indicates the multiple to apply to the Response time to determine how long to wait for a response after a connection when you are using an external payment service. For example, if the Response check frequency is 6 and the Response time is 10,000, the system waits 60,000 milliseconds (60 seconds or 1 minute) for a response after connection. Note:  If the total response interval is exceeded for an authorization record, the record goes into *RCVD status with a response type of SU, and is then removed from the Credit Card Authorization Transaction table (CCAT00). To avoid potential timeout issues, Oracle recommends that you set the Response Time high enough for the authorization service to prevent issues that could potentially occur if the authorization process times out while processing multiple authorizations for an order. Numeric, 3 positions; optional.
Test mode?	Indicates whether you are transmitting in test mode. Valid values are: Selected = Test mode. The system inserts the word TEST in the transmission. Unselected (default) = Live mode. This field is not implemented.
Response time	Indicates the number of milliseconds to wait for a connection to the service bureau when you are using an external payment service. For example, set this field to 10,000 milliseconds to wait 10 seconds for a connection. Numeric, 5 positions; optional.
Merchant division	Assigned by the authorization service. Numeric, 5 positions; optional.
Authorization service provider	This field is not implemented. Alphanumeric, 10 positions; optional.
API User name	The user name, provided by the service bureau, used to establish a direct connection to the service bureau. Alphanumeric, 64 positions; optional.
API Password	The password, provided by the service bureau, used to establish a direct connection to the service bureau. Alphanumeric, 64 positions; optional.
API Signature	The encrypted signature, provided by the service bureau, used to establish a direct connection to the service bureau. You can also define API credential information at the entity level using the Create Merchant ID by Entity Screen. Alphanumeric, 128 positions; optional.
Override Reconciliation Id	Note:  This field is available only for the CyberSource integration (if the Service Code is set to CYB). Indicates the value to pass as the reconciliationID in a debit deposit, credit deposit, or authorization and deposit request to CyberSource. Available settings are: blank (default) = Do not send the invoice number or the alternate order number as the reconciliation ID. Invoice Number = Send the invoice number as the reconciliation ID. The invoice number is assigned at billing. Alternate Order Number = Send the alternate order number, if it exists, as the reconciliationID. For an e-commerce order, the alternate order number is the order_number passed in the Inbound Order XML Message (CWORDERIN) message to identify the order in the originating system or on the web storefront. The alternate order number is labeled the Alt ord at the Display Order Properties Screen. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). If the reconciliationID in the request message does not specify an invoice number or alternate order number, then CyberSource assigns a reconciliationID as a reference number for the transaction, and passes it in the response message. Note:   If the Alternate Order Number is passed as the reconciliationID, it must be alphanumeric. If the reconciliationID includes any special characters, depending on the rules or requirements of the back-end processor, CyberSource may ignore the ID provided in the request and assign its own reconciliationID, to be passed in the response. Only the debit deposit, credit deposit, and authorization and deposit messages support sending the reconciliationID. CyberSource generates a reconciliationID during authorization, so as a result, there can be more than one reconciliationID associated with the deposit. The supported size of the reconciliationID varies based on the credit card processor. You need to confirm that the credit card processor used supports the length and attributes of the invoice number or alternate order number. It is possible that the reconciliationID from Order Administration may not be unique in CyberSource if, for example, you have multiple companies. In the case of an authorization + deposit request, the reconciliationID is included in both the ccAuthService node as well as the ccCaptureService node. Otherwise, it is included only in the ccCaptureService node.

Instructions:

1. At the First Create Authorization Services Screen, enter the Service Code, Application, Merchant ID, Charge description and any other information required by the service bureau.

2. Select OK to advance to the Second Create Authorization Service Screen.

3. Continue entering all necessary information to set up the service bureau on your system.

Work with External Authorization Service Screen

Purpose: Information will be provided by Oracle at a later date.

How to display this screen: Select External Service for an authorization service at the Work with Authorization Services Screen. External Authorization Service Access (B25) authority is required.

For more information: See the External Payment Layer RESTful Service reference on My Oracle Support for more information on updating these settings.

Note:

All fields are required, with the exception of the External Service flag.

Field	Description
External Service	Select this field to have request messages generated for the External Payment Service.
External URL Prefix	The prefix that forms the beginning of the URL where messages are sent. Must begin with HTTPS. The message type defines the suffix that is appended to the prefix to create the entire URL. For example, for a credit card authorization request, the entire URL might be https://remote.auth.com:1234/authorization, where remote.auth.com is the remote server, 1234 is the port, and authorization identifies an authorization request. The following endpoints are supported: balanceInquiry authorization reversal getToken generateGift activateGift rechargeGift deposit return Alphanumeric, 600 positions; required if the External Service flag is selected.
Message Version	Indicates which message version is supported with version 3.0 being the default version when creating a new authorization service. Previous versions have been removed. Version 3.0 no longer includes tags that pass the credit card number for an order and instead includes tags that pass the card token. It also allows an external merchant application to call for both Credit Cards and Stored Value Cards supported through the External Payment Service and EFTConnect.
Authentication User	The user ID for authentication of the messages to the external service. Alphanumeric, 256 positions; required if the External Service flag is selected.
Authentication Password	The password for authentication of the messages to the external service. Must be at least 6 positions long, include both numbers and letters, include a special character, and cannot end with a number. Alphanumeric, 256 positions; required if the External Service flag is selected.

Defining Authorization Service Countries

Purpose: Each service bureau that your company uses may assign its own country codes to the various credit card payment methods. These country codes may differ from the country codes your company uses.

The Authorization Service Country function is used to cross reference the country codes your company uses with the country codes the authorization and deposit service uses. By cross referencing the country codes:

• You can use your country codes when entering orders.

• The country code the service bureau uses can be included in the Authorization and Deposit transactions that are transmitted to the service bureau.

• When you create the country cross-reference, you can also indicate whether the service bureau performs address verification for the country.

Note:

Use this option if you are sending transactions to the service bureau using a point-to-point integration.

Authorization service country required for double-byte customer address: If the customer’s address uses a double-byte language, such as Chinese, you need to set up an authorization service country record to support address verification.

In this topic:

• Work with Authorization Service Country Screen

• Create Authorization Service Country Screen

Work with Authorization Service Country Screen

Purpose: This screen displays the country cross references currently defined for the service bureau. Use this screen to create, change, or delete the country cross reference information.

The country codes your company uses are defined in the Country table; the country codes the service bureau uses are provided by the service bureau.

How to display this screen: At the Work with Authorization Service Country Screen, select Country for the service bureau.

Field	Description
Authorization service	The code and description of the service bureau for which you are defining a country cross reference. Code: Alphanumeric, 3 positions; display-only. Description: Alphanumeric, 30 positions; display-only.
Country	A code you use to identify a country. Country codes are defined in and validated against the Country table; see Setting Up the Country Table (WCTY). Alphanumeric, 3 positions; optional.
Authorization Service Country	The code the service bureau uses to identify a country. Vendor country codes are provided by the service bureau. Alphanumeric, 3 positions; optional.
AVS	Defines whether the service bureau performs address verification for the country. N = The service bureau does not perform address verification for the country. Y = The service bureau performs address verification for the country. Alphanumeric, 1 position; display-only.

Option	Procedure
Create a country cross reference	Select Create to advance to the Create Authorization Service Country Screen.
Change a country cross reference	Select Change for the country cross reference to advance to the Change Authorization Service Country screen. At this screen you can change the Authorization service country and the Address verification setting. See the Create Authorization Service Country Screen for field descriptions.
Delete a country cross reference	Select Delete for the country cross reference to delete it.

Create Authorization Service Country Screen

Purpose: Use this screen to cross reference the country codes your company uses with the codes the service bureau uses. For example, your company may use country code USA to identify the United States of America, whereas the service bureau may use country code US.

The country codes your company uses are defined in the Country table; the country codes the service bureau uses are provided by the service bureau.

How to display this screen: Select Create at the Work with Authorization Service Country Screen.

Field	Description
Authorization service	The code and description of the service bureau for which you are defining a country cross reference. Code: Alphanumeric, 3 positions; display-only. Description: Alphanumeric, 30 positions; display-only.
Country	A code you use to identify a country. Country codes are defined in and validated against the Country table; see Setting Up the Country Table (WCTY). Alphanumeric, 3 positions. Create screen: required. Change screen: display-only.
Authorization service country	The code the service bureau uses to identify a country. Vendor country codes are provided by the service bureau. Alphanumeric, 3 positions; required.
Address verification	Defines whether the service bureau performs address verification for the country. Unselected = The service bureau does not perform address verification for the country. Selected = The service bureau performs address verification for the country.

Defining Vendor Paytype Codes

Purpose: Each service bureau that your company uses may assign its own paytype codes to the various credit card payment methods. These paytype codes may differ from the paytype codes your company uses. For example, the service bureau may use paytype code 01 to represent payment by Visa, whereas, your company may use paytype code 04 to identify payment by Visa.

The Vendor Paytype Codes function is used to cross reference the paytype codes your company uses with the paytype codes the authorization service uses. By cross referencing the paytype codes:

• you can use your paytype codes when entering orders

• the paytype code the service bureau uses can be included in the Authorization and Deposit transactions that are transmitted to the service bureau.

In this topic:

• Work with Paytype Cross Reference Screen

• Create CC Paytype Cross Reference Screen

Work with Paytype Cross Reference Screen

Purpose: This screen displays the pay type cross references currently defined for the service bureau. Use this screen to create, change, delete, or display the pay type cross reference information.

The pay type codes your company uses are defined in the Pay Type table; the pay type codes the service bureau uses are provided by the service bureau.

How to display this screen: At the Work with Authorization Services Screen, select Paytypes for the service bureau.

Field	Description
Pay type	A code you use to identify a method of payment on an order. Pay type codes are defined in the Pay Type table; see Working with Pay Types (WPAY). Numeric, 2 positions; optional.
Vendor pay code	The code the authorization service uses to identify a method of payment.  Vendor pay type codes are provided by the service bureau.   Alphanumeric, 5 positions; optional.
Authorization Merchant #	The merchant number to use when sending authorization requests for this pay type code to the service bureau for approval.  The merchant number is assigned to your company by the service bureau.    Alphanumeric, 10 positions; optional.
Deposit merchant # (Deposit merchant number)	The merchant number to use when sending deposit requests for this pay type code to the service bureau for settlement.  The merchant number is assigned to your company by the service bureau.    Alphanumeric, 10 positions; optional.

Option	Procedure
Create a paytype cross reference	Select Create to advance to the Create CC Paytype Cross Reference Screen for the service bureau.
Change a paytype cross reference	Select Change for the pay type cross reference you want to change to advance to the Change Paytype Cross Reference Screen. At this screen you can change any information except the Authorization service and the Pay type code. See the Create CC Paytype Cross Reference Screen for field descriptions.
Delete a paytype cross reference	Select Delete for the pay type cross reference you want to delete.
Display a paytype cross reference	Select Display for the pay type cross reference you want to display to advance to the Display CC Paytype Cross Reference Screen. You cannot change any information at this screen. See the Create CC Paytype Cross Reference Screen for field descriptions.

Create CC Paytype Cross Reference Screen

Purpose: Use this screen to cross reference the pay type codes your company uses with the codes the service bureau uses.  For example, your company may use pay type code 4 to identify payment by Visa, whereas the service bureau may use pay type code 1.

The pay type codes your company uses are defined in the Pay Type table; the pay type codes the service bureau uses are provided by the service bureau.

How to display this screen: Select Create at the Work with Paytype Cross Reference Screen.

Field	Description
Pay type	The code you use to identify a method of payment on an order. Pay type codes are defined in the Pay Type table; see Working with Pay Types (WPAY). Numeric, 2 positions. Create screen: required. Change screen: display-only.
Vendor paytype/code	The code the service bureau uses to identify a method of payment.  Vendor pay type codes are provided by the service bureau. Alphanumeric, 5 positions; required.
Authorization merchant #	The merchant number to use when sending authorization requests for this pay type code to the service bureau for approval.  The merchant number is assigned to your company by the service bureau. Alphanumeric, 10 positions; optional.
Deposit merchant #	The merchant number to use when sending deposit requests for this pay type code to the service bureau for settlement.  The merchant number is assigned to your company by the service bureau. Alphanumeric, 10 positions; optional.

Instructions:

1. Enter the pay type code you company uses to identify the payment method in the Pay type field.

2. Enter the corresponding pay type code the service bureau uses to identify the payment method in the Vendor pay code.

3. Optionally, enter the authorization and deposit merchant numbers assigned to your company by the service bureau in the Authorization Merchant # and the Deposit merchant # (Deposit merchant number) fields.

4. Your entries are cleared from the screen and a message similar to the following displays: CC Vendor Paytype Cross Reference (NAB - 5) created.

Defining Vendor Response Codes

Vendor response codes identify the reasons that the service bureau approves (authorizes) or declines a credit card charge or deposit. The codes are assigned to each transaction by the service bureau when approving or declining the request.

You should define each code for each service bureau you work with.

The system allows you to set up the following instructions for vendor response codes:

• how many times to attempt authorization for this response

• whether to put the order on hold and, if so, for how long

• whether to flag the order for cancellation

Online credit card authorizations: If you are sending credit cards for authorization during order entry/maintenance (the On-line Authorizations (B89) system control value is selected), the system displays additional fields where you can enter a message indicating whether the credit card was approved or declined and if any action should be taken, such as asking the customer to repeat the credit card number or requesting a different credit card for authorization. If you define a message, the system displays the Select Authorization Response Option Window in order entry/maintenance when a response is received from the service bureau. This window displays the pop up window messages you defined for this vendor response. See Performing Online Credit Card Authorizations for an overview on online authorizations and the required setup.

Credit card decline email: If you specify a program in the Credit Card Decline Email Program (K53) system control value, the batch authorization process in pick slip generation generates an email to the customer when an order is placed on hold due to a credit card decline. See that system control value for more information.

In this topic:

• Entity Setup

• Vendor Response Setup Examples

• About Deposits

• Work with Vendor Response Screen

  • Create Vendor Response Screen

• Select Entity for Vendor Response Details Screen

• Work with Ship Via $ Limit to Hold Screen

  • Create Ship Via $ Limit to Hold Screen

• Work with Pay Type $ Limit to Force Authorization Screen

  • Create Pay Type $ Limit to Force Authorization Screen

• Work with Item Class $ Limit to Hold Screen

• Create Item Class $ Limit to Hold Screen

• Change Item Class $ Limit to Hold Screen

• Display Item Class $ Limit to Hold Screen

• Work with Postal Code $ Limit to Hold Screen

• Create Postal Code $ Limit to Hold Screen

• Change Postal Code $ Limit to Hold Screen

• Display Postal Code $ Limit to Hold Screen

Defining Vendor Response Codes

Entity Setup

Additionally, you can set up the following instructions for a vendor 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 amount 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.

• Whether a dollar limit to force an authorization is applied to a specific pay type. See Entity pay type dollar limits.

• Whether a dollar limit is applied to the item class associated with an item on the order that requires authorization. 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.

• Whether a dollar limit is applied to the postal code 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 amount 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.

Online authorization: If you are performing online authorization, the system does not evaluate the order for entity pay type dollar limit or entity ship via dollar limit; however, the system will evaluate the order for item class dollar limit and postal code dollar limit.

Entity dollar limit hierarchy: The system uses the following hierarchy when evaluating whether the order meets an entity dollar limit.

1. Evaluate the order for Entity pay type dollar limits.

2. If the order does not qualify for entity pay type dollar limits, evaluate the order for Entity ship via dollar limits.

3. If the order does not qualify for entity ship via dollar limits, evaluate the order for Entity item class dollar limits.

4. If the order does not qualify for entity item class dollar limits, evaluate the order for Entity postal code dollar limits.

If an order qualifies for more than one of the entity dollar limits, the system holds/releases the order using the last entity dollar limit that qualifies. For example, if the order qualifies for both entity ship via dollar limit and entity postal code dollar limit, the system holds or releases the order based on the entity postal code dollar limit setup.

Entity ship via dollar limits

You can set up a ship via dollar limit for an AVS response for each entity in your company. You can use the ship via dollar limit to reduce the amount of fraud. For example, a credit card may receive an AVS response of “all address matching,” but you may want to perform an additional check against the ship via assigned to the order and the dollar amount that requires authorization.

• If the authorization amount is less than the ship via dollar limit, the system releases the order from any AVS hold.

• If the authorization amount is greater than the ship via dollar limit and the sold to customer and ship to customer are different, the system places the order on hold using the hold reason defined for the ship via dollar limit.

The system checks the following information to determine if an order should go on hold due to a ship via dollar limit:

• the service bureau code

• the AVS response code received from the service bureau

• the Entity associated with the order

• the Ship via code on the order header

• the $ limit to hold on the order

• the sold to customer and ship to customer are different

• The Use Credit Card Vendor Response Entity Ship Via Dollar Limits (F94) system control value is selected. If this system control value is not selected, the system does not perform an edit against the ship via dollar limit for an AVS response to determine if an order should go on hold.

The system does not evaluate the order for ship via dollar limit if:

• The order does not pass authorization, regardless of whether the ship to customer is different than the sold to customer.

• You are performing online authorization.

Entity ship via dollar limit summary: 

AVS response	Entity $ limit	Auth amount less than entity $ limit	Auth amount greater than or equal to entity $ limit
hold reason	no hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Entity Via $Limit.	The system places the order on hold, using the hold reason defined for the AVS response. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	hold reason	The system does not place the order on hold.	The system places the order on hold, using the hold reason defined for the entity ship via dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	no hold reason	The system does not place the order on hold.	The system does not place the order on hold.
hold reason	hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Entity Via $Limit.	The system places the order on hold, using the hold reason defined for the entity ship via dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.

Ship via dollar limit example: The following is an example of how to set up a ship via dollar limit for an AVS response code.

AVS Response	Description	Hold Reason Code
I3	All Address Matching	None

The following is an example of how to set pu ship via dollar limit hold values:

AVS Response	Entity	Ship Via	$ Limit	Hold Reason Code
I3	555	1	$50.00	J3
I3	555	2	$75.00	J4
I3	555	3	$150.00	J5

Using the example, if an order passed AVS because it received an AVS response of I3, all address matching, the system would then perform an edit against the ship via dollar limit defined for the response.

If a ship via dollar limit was defined for the entity associated with the order, the ship via defined on the order, and the dollar amount on the order that required authorization was greater than the dollar limit defined for the AVS response, the order would then be placed on hold, using the hold reason code defined for the ship via dollar limit.

Using the example, the system would assign the hold reason code J3 to an order if the order was associated with entity 555, ship via code 1, and the dollar amount that required authorization was greater than $50.00.

Entity pay type dollar limits

You can set up a pay type dollar limit for a vendor response for each entity in your company. You can use the pay type dollar limit to force authorizations that have been declined.

Example: If a credit card received a vendor response of "credit card exceeds limit", you may want to force the authorization through anyway if the dollar amount that requires authorization is less than $50.00.

If you set up a pay type dollar limit, the order receives a forced authorization if:

• the credit card on the order is declined, and

• the dollar amount that requires authorization is greater than $1.00 and is less than the pay type dollar limit you have set up for the credit card pay type on the order. Note: If you wish to force authorizations for credit cards requiring authorizations less than $1.00, enter an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value.

In this situation, the order receives a forced authorization, and the system writes the Default Credit Card Authorization Number for Soft Declines (F93) to the Authorization number field on the Authorization History record. The system processes the authorization through Order Administration, as if the number that defaulted from the system control value was an actual authorization number. The order will be processed through pick slip generation and the system will produce pick slips for the order. The system also writes an order transaction history message indicating the authorization was forced.

If the Default Credit Card Authorization Number for Soft Declines (F93) system control value is blank, the order is placed on hold, using the vendor response hold reason code. If the hold reason code for the vendor response is blank, or a hold reason code has not been defined for the vendor response, the order is not placed on hold, and is processed through pick slip generation.

Note:

The system may still place the order on hold if it fails AVS authorization.

The system checks the following information to determine if an order should receive a forced authorization after it has been declined:

• the service bureau code

• the Vendor response code received from the service bureau

• the Entity associated with the order

• the credit card Pay type on the order that requires authorization

The system does not evaluate the order for pay type dollar limit if you are performing online authorization.

Note:

The system performs an edit against the pay type dollar limit defined for a vendor response before the number of authorization attempts logic. If the order passes the pay type dollar limit edit, the system does not perform the number of attempts edit against the order. 

Entity pay type dollar limit summary: 

Vendor response	Auth amount less than entity $ limit to force auth	Auth amount greater than or equal to entity $ limit to force auth
hold reason	The system does not place the order on hold. Order transaction history message: System Forced CC Auth - Auth# 999999.	The system places the order on hold, using the hold reason defined for the vendor response. Order transaction history message: SYS HLD - Declined Credit Card.

Pay type dollar limit example: This example shows how to set up a pay type dollar limit for a vendor response code.

Vendor Response	Description	Hold Reason Code
Vendor Response Value:
42	Declined, card over limit	H4

Vendor Response	Entity	Pay Type	Dollar Limit
Pay Type Dollar Limit Values:
42	555	4 VISA	$50.00
42	555	5 MASTERCARD	$75.00

Using the example, if an order did not pass authorization because it received a vendor response of 42, declined card over limit, the system would then perform an edit against the pay type dollar limit defined for the response.

If a pay type dollar limit was defined for the entity associated with the order, the pay type defined on the order, and the dollar amount on the order that required authorization was less than the dollar limit defined for the vendor response, the order would receive a forced authorization, using the Default Credit Card Authorization Number for Soft Declines (F93).

Using the example, an order would receive a forced authorization if the pay type on the order was VISA and the dollar amount for the VISA card was under $50.00.

Entity item class dollar limits

You can set up an item class dollar limit for an AVS response for each entity in your company. You can use the item class dollar limit to reduce the amount of fraud. For example, a credit card may receive an AVS response of “all address matching”, but you may want to perform an additional check against the item class (such as high-theft items) assigned to one or more of the items on the order and the dollar amount that requires authorization.

• 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.

The system checks the following information to determine if an order should go on hold due to an item class dollar limit:

• the service bureau code

• the AVS response code received from the service bureau

• the Entity associated with the order

• the $ limit to hold on the order

• the item class assigned to one or more of the items on the order requesting authorization

Note:

• The item(s) assigned to the item class must be requesting authorization. For example, if the item assigned to the item class is on backorder, the other items on the order requesting authorization will not qualify for the item class dollar limit.

• If more than one item class on the order qualifies for an item class dollar limit, the system uses the item class associated with the lowest order number. For example, if order line 1 is associated with item class PNT and order line 3 is associated with item class ELC and both qualify, the system uses the item class dollar limit defined for item class PNT.

The system does not evaluate the order for item class dollar limit if the order does not pass authorization.

Entity item class dollar limit summary: 

AVS response	Entity $ limit	Auth amount less than entity $ limit	Auth amount greater than or equal to entity $ limit
hold reason	no hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Item Class $Limit.	The system places the order on hold, using the hold reason defined for the AVS response. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	hold reason	The system does not place the order on hold.	The system places the order on hold, using the hold reason defined for the entity item class dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	no hold reason	The system does not place the order on hold.	The system does not place the order on hold.
hold reason	hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Item Class $Limit.	The system places the order on hold, using the hold reason defined for the entity item class dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.

Item class dollar limit example: The following is an example of how to set up an item class dollar limit for an AVS response code.

AVS Response	Description	Hold Reason Code
I3	All Address Matching	None

Item class dollar limit to hold example:

AVS Response	Entity	Item Class	Dollar Limit	Hold Reason Code
I3	555	ELC	$50.00	C1
I3	555	PNT	$75.00	C2
I3	555	ZBA	$150.00	C3

Using the example, if an order passed AVS because it received an AVS response of I3, all address matching, the system would then perform an edit against the item class dollar limit defined for the response.

If an item class dollar limit was defined for the entity associated with the order, the item class assigned to at least one of the items on the order requiring authorization, and the dollar amount on the order that required authorization is equal to or greater than the dollar limit defined for the AVS response, the order would then be placed on hold, using the hold reason code defined for the item class dollar limit.

Using the example, the system would assign the hold reason code C1 to an order if the order was associated with entity 555, item class ELC, and the dollar amount that required authorization was equal to or greater than $50.00.

Entity postal code dollar limits

You can set up a postal code dollar limit for an AVS response for each entity in your company. You can use the postal code dollar limit to reduce the amount of fraud. For example, a credit card may receive an AVS response of “All Address Match”, but you may want to perform an additional check against the postal code assigned to the bill to or sold to customer on the order and the dollar amount that requires authorization.

• If the authorization amount is less than the postal code dollar limit, the system releases the order from any AVS hold.

• If the authorization amount 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.

The system checks the following information to determine if an order should go on hold due to a postal code dollar limit:

• the service bureau code

• the AVS response code received from the service bureau

• the Entity associated with the order

• the postal code for the bill to customer on the order; if a bill to customer is not defined, the system validates the postal code for the sold to customer on the order

• the $ limit to hold on the order

The system does not place the order on postal code dollar limit hold if the order does not pass authorization.

Entity postal code dollar limit summary: 

AVS response	Entity $ limit	Auth amount less than entity $ limit	Auth amount greater than or equal to entity $ limit
hold reason	no hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Postal Code $Limit.	The system places the order on hold, using the hold reason defined for the AVS response. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	hold reason	The system does not place the order on hold.	The system places the order on hold, using the hold reason defined for the entity postal code dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	no hold reason	The system does not place the order on hold.	The system does not place the order on hold.
hold reason	hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Postal Code $Limit.	The system places the order on hold, using the hold reason defined for the entity postal code dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.

Postal code dollar limit example: The following is an example of how to set up a postal code dollar limit for an AVS response code.

AVS Response	Description	Hold Reason Code
I3	All Address Matching	None

Postal code dollar limit to hold example:

AVS Response	Entity	Postal code	Dollar Limit	Hold Reason Code
I3	555	01468	$50.00	P1
I3	555	01701	$75.00	P2
I3	555	02053	$150.00	P3

Using the example, if an order passed AVS because it received an AVS response of I3, all address matching, the system would then perform an edit against the postal code dollar limit defined for the response.

If a postal code dollar limit was defined for the entity associated with the order, the postal code assigned to the sold to, and the dollar amount on the order that required authorization is equal to or greater than the dollar limit defined for the AVS response, the order would then be placed on hold, using the hold reason code defined for the postal code dollar limit.

Using the example, the system would assign the hold reason code P1 to an order if the order was associated with entity 555, postal code 01468, and the dollar amount that required authorization was equal to or greater than $50.00.

Vendor Response Setup Examples

Examples of different vendor responses, and how you might set them up on the system for credit card authorization before shipment, are:

Stolen credit card:

• do not reattempt authorization

• put the order on CF (credit card fraud) hold

• flag the order for cancellation

Over credit limit:

• put the order on hold for 5 days before reattempting authorization

• flag the order for cancellation after a number of declined authorizations

Transmission error:

• do not put the order on hold; reattempt authorization immediately

Address verification failed:

• do not reattempt authorization

• put the order on AV (address verification) hold

Card security value should be on the credit card:

• do not reattempt authorization

• put the order on CF (credit card fraud) hold

Note:

A pick slip will not print if the authorization is declined or if the order is on hold.

Determining the maximum number of declines: The system counts the number of declines for each different vendor response code separately.  For example, if an authorization is declined twice for a transmission error, and is then declined for exceeding a credit limit, the counter starts again at 1 the first time you receive the new vendor response code.  

The Maximum Number of Retries on Credit Card Orders (E74) system control value specifies the maximum number of all declines (with any vendor response that represents a decline) an order can accumulate before being flagged for cancellation.   This value overrides the limit you specify for an individual vendor response. Be sure to set this system control value high enough that you do not inadvertently flag on order for cancellation when it still might be eligible for authorization.

Releasing held orders: The Release Orders on Time Hold periodic function evaluates held credit card orders for release based on their hold dates. See Releasing Orders from Time Hold.

You can also use the Release Held Orders (ERHO) menu option to release orders one at a time..

Canceling orders: You can use the Working with Credit Card Cancellations (WCCC) menu option to cancel all orders flagged for cancellation automatically.   You can also set up this function as part of your periodic process.

About Deposits

Response codes may be used both for credit card authorizations and deposit authorizations.  Typically, you would need to authorize a deposit because the order is using deferred or installment billing, and so you would not have a current authorization for the amount of the deposit you are processing.

The system does not perform the same types of actions against the order for a deposit authorization as it does for other authorizations. Specifically, the system does not reference the following fields (defined at the Create Vendor Response Screen) when processing an authorization for a deposit:

• Hold reason

• of authorization attempts

• of days between attempts

• Cancel reason

• Letter type

Similarly, the Maximum Number of Retries on Credit Card Orders (E74) system control value does not play a role in authorizing deposits.

Force deposit: You can set a vendor response code to “force deposit” in your company when you receive this response code from the deposit service. To do so, select the Force deposit for FPO flag for the response code. Forcing deposit means that you process all of the same updates in your company as if you had received an approval for the authorization.

Regular (non-payment plan) deposits are always forced.

Note:

You must make your own arrangements with the service bureau regarding how to deal with unconfirmed or rejected deposit transactions.

The system checks the setting of this "force deposit" flag only when:

• you process a deposit for a deferred or installment pay plan

• the service bureau supports force deposit

• the authorization is declined (that is, the response code is not 100)

• the system submitted the transaction with an action code of B (obtain both an authorization and deposit) rather than D (deposit only)

If you don't force: When a payment plan deposit fails authorization and is not forced, the deposit appears on the Unconfirmed Deposits Listing Report. You can use Manage Rejected Deposits in Modern view to work with these deposits. Additionally, the order is placed on hold, and any orders that match the sold to customer and/or the credit card number are placed on hold as well.

More information:

• Deferred/Installment Billing Overview 

• Processing Auto Deposits (SDEP) 

Work with Vendor Response Screen

Purpose: This screen displays the response codes currently defined for the service bureau. Use this screen to add, delete, or change a response code for the service bureau.

You must create a vendor response code for each code used by the service bureau. If the system receives a vendor response code it does not recognize, it puts the order on AVS hold.

How to display this screen: Select Responses for the service bureau at the Work with Authorization Services Screen 

Field	Description
Response code	The code assigned by the service bureau that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. Alphanumeric, 10 positions; optional.
Description	The description of the response code.   Alphanumeric, up to 40 positions; optional.

Option	Procedure
Change a vendor response code	Select Change for a response code to advance to the Change Vendor Response Screen. At this screen you can change any information except the Authorization service code and the Response code. See the Create Vendor Response Screen for field descriptions.
Delete a vendor response code	Select Delete for a response code to delete it.
Display a vendor response code	Select Display for a response code to advance to the Display Vendor Response Screen. You cannot change any information at this screen. See the Create Vendor Response Screen for field descriptions.
Work with ship via dollar limits and pay type dollar limits for a vendor response code	Select Response/Entity Details for a response code to advance to the Work with Ship Via $ Limit to Hold Screen.
Create a vendor response code	Select Create to advance to the Create Vendor Response Screen.

Create Vendor Response Screen

Purpose: Use this screen to define the response codes that the service bureau uses to indicate the disposition of the authorization, and how the system should then handle the order.

How to display this screen: Select Create at the Work with Vendor Response Screen 

Field	Description
Response code	The code assigned by the service bureau to identify whether the credit card was authorized or declined, and the reason for the authorization or decline. You should define each code used by the service bureau on the system. If the service bureau returns a response that the system does not recognize, the order appears on the Credit Card Authorization Listing as DECLINED (no description will appear) and is put on AVS hold; you must release the order through the Release Held Orders menu option, described in Selecting Held Orders (ERHO). Deposits: See About Deposits for an example of how response codes may be used during deposits processing. Note:  The INSUFFICIENT_FUNDS response code for the RLT authorization service (WASV) must be assigned a hold reason code of SV. Alphanumeric, 10 positions. Create screen: required. Change screen: display-only.
ORCE response	The code assigned by the Oracle Retail Customer Engagement service bureau to identify whether the stored value card transaction was approved or declined. Use this field to map a response from Oracle Retail Customer Engagement to a vendor response code. This field displays only if the Authorization service code for the service bureau is RLT. See Customer Engagement Stored Value Card Integration. Alphanumeric, 60 positions. Create screen: optional. Change screen: display-only.
Description 1	The description of the response code. You can use the description provided by the service bureau or you can use your own description.    Both lines of the description appear on the Credit Card Authorization Listing. You can also review it in standard order inquiry at the Authorization History Details Window. Deposits:  The first line only of the response code description displays on the Display Deposit History Detail Screen in standard order inquiry when the service bureau uses this response code for a deposit authorization. Alphanumeric, 100 positions; required.
Description 2	An additional description for the response code.   Alphanumeric, 100 positions; optional.
Hold reason	The hold code to use for orders receiving this response. This a paytype-level hold; the order will be put on AT hold. The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations, so you can use this field as a description of the vendor response for that report. No pick slip prints if the order is placed on hold.   If you assign a Hold date to the order (by completing the # of days between attempts field) you can release the order through the Release Orders on Time Hold periodic function. If not, you must use the Release Held Orders or Manual Credit Card Authorization function to release the order. Leave the Hold field blank if orders with this response code should not be placed on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Deposits: The system does not reference this field when processing an authorization for a deposit. See About Deposits. Alphanumeric, 2 positions; optional.
# authorization attempts (Number of authorization attempts)	The number of times to attempt to authorize an order before flagging it for cancellation.  This field defines the number of attempts for this response code only; if the vendor returns a different response code, the count begins again at one. Enter 1 in this field if you want to flag an order for cancellation immediately.  If this value is set to more than one, the system will continue to resubmit the order for authorization until the value is reached, provided the order is not held. The Maximum Number of Retries on Credit Card Orders (E74) system control value overrides this limit if it is lower than the maximum specified for a given response code. This system control value will also override the limit for a response code if the combined total authorization attempts for all responses on an order meets the maximum defined in the System Control table. Leave this field blank if you want to the system to continue to attempt authorization indefinitely (however, the system control value described above will override a blank value). Deposits: The system does not reference this field when processing an authorization for a deposit. See About Deposits. Online credit card authorization: The system does not reference this field when processing an online credit card authorizations. Numeric, 2 positions; optional.
# of days between attempts	The number of days to add to the current date when calculating a Hold until date for an order.   Example:  If the current date is 7/15, and this field is set to 5, the system assigns a Hold until date of 7/20. If you leave this field blank and: if the Hold reason field is also blank, the system will repeatedly submit the order for reauthorization until the Number of authorization attempts is reached; if you have defined a Hold reason, the system will never submit the order for reauthorization repeatedly (for example, if the order is flagged for cancellation; see Cancel reason). The Release Orders on Time Hold periodic function releases an order from hold once the Hold date is reached. See Releasing Orders from Time Hold. Deposits:  The system does not reference this field when processing an authorization for a deposit. See About Deposits. Online credit card authorization: The system does not reference this field when processing an online credit card authorization. Numeric, 2 positions; optional.
Cancel reason	The cancel reason to use when an order has reached the # authorization attempts (Number of authorization attempts), or in the number in the system control value (whichever is lower). As part of this process, the order is flagged for cancellation; you use the Working with Credit Card Cancellations (WCCC) option to cancel such orders. You can also set this function up as part of your periodic processing. If an order becomes eligible for cancellation because its total number of authorization attempts meet the maximum defined in the System Control table, the system uses the cancellation code associated with the most recently received vendor response. Cancel reason codes are defined in and validated against the Cancel Reason Code table; see Establishing Cancel Reason Codes (WCNR). Deposits: The system does not reference this field when processing an authorization for a deposit. See About Deposits. Online credit card authorization: The system does not reference this field when processing an online credit card authorization. Numeric, 2 positions; optional (required if you enter a value in the # authorization attempts field).
Force deposit for FPO	Indicates whether to process all the usual updates for a deposit when you receive this response code from the service bureau, even though this response code actually represents a decline. Selected = force deposit Unselected (default) = Do not force deposit About Deposits
Pop up window messages (online authorization messages)	Four additional fields where you can enter a message indicating whether the credit card is approved or declined and if any action should be taken, such as asking the customer to repeat the credit card number or requesting a different credit card for authorization. Note:  These fields only display if the On-line Authorizations (B89) system control value is selected and the Batch/online field for the service bureau is set to I (online authorization only) or C (online and batch authorization). If you are sending credit cards for authorization during order entry (the On-line Authorizations (B89) system control value is selected), the system displays the  Select Authorization Response Option Window in order entry when a response is received from the service bureau. This window displays the pop up window messages you defined for this vendor response. See Performing Online Credit Card Authorizations for an overview on online authorizations and the required setup. Alphanumeric, four 40-positions fields; optional.

Select Entity for Vendor Response Details Screen

Purpose: Use this screen to define more information for a vendor response for each entity in your company.  At this screen you can:

• define a ship via dollar limit for an AVS response code to perform an additional edit against the authorization amount if the ship via on the order matches a ship via dollar limit and the sold to customer and ship to customer are different.

• define a pay type dollar limit to force an authorization for a declined vendor response code.

• define an item class dollar limit for an AVS response code to perform an additional edit against the authorization amount if one or more item(s) on the order requiring authorization has an item class that matches an item class dollar limit.

• define a postal code dollar limit for an AVS response code to perform an additional edit against the authorization amount if the postal code for the sold to on the order matches a postal code dollar limit.

How to display this screen: On the Work with Vendor Response Screen screen, select Response/Entity Details for a vendor response

Field	Description
Authorization service	The code and description to identify the service bureau for which you are working with vendor response details.   This is the service bureau you selected at the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the service bureau that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. This is the vendor response you selected on the Work with Vendor Response Screen. For ship via dollar limit, postal code dollar limit, and item class dollar limit, this must be an AVS response code. Pay type dollar limit applies to a vendor response code. Vendor response code:  Alphanumeric, 10 positions; display-only. Vendor response description:  Alphanumeric, 40 positions; display-only.
Entity	A code for the entity for which you wish to create vendor response details.  An entity is a component of the sales reporting hierarchy.  An entity can represent the business units in your company, for example, mail order, retail, wholesale).  A list of all the valid entity records set up for the company you are currently in displays. Entity codes are defined in and validated against the Entity table. See Working with Entities (WENT). Numeric, 3 positions; optional.
Description	A description of the entity. Alphanumeric, 25 positions; optional.

Screen Option	Procedure
Define ship via dollar limits for a specific entity	Select Ship Via $ Limit for an entity to advance to the Work with Ship Via $ Limit to Hold Screen.
Define pay type dollar limits for a specific entity	Select Pay Type $ Limit for an entity to advance to the Work with Pay Type $ Limit to Force Authorization Screen.
Define item class dollar limits for a specific entity	Select Item Class $ Limit for an entity to advance to the Work with Item Class $ Limit to Hold Screen.
Define postal code dollar limits for a specific entity	Select Postal Code $ Limit for an entity to advance to the Work with Postal Code $ Limit to Hold Screen.

Work with Ship Via $ Limit to Hold Screen

Purpose: Use this screen to create and maintain ship via dollar limits for a specific entity, AVS response, and service bureau.

Ship via dollar limit defines 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 amount 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.

You might use this if you want to keep a careful check for stolen credit cards. For example, you can place an order on hold if the order is associated with a Federal Express ship via and the dollar amount required for authorization is greater than $200.00.

See Entity ship via dollar limits for more information on the processing the system performs.

Note:

If you are performing online authorization, the system does not validate entity ship via dollar limit.

How to display this screen:  Select Ship Via $ Limit for an entity on the Work with Vendor Response Screen

Field	Description
Authorization service	The code and description of the service bureau for which you are working with ship via dollar limits. This is the service bureau you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the service bureau that identifies whether the credit card passed address verification. This is the AVS response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Ship Via	A code for the carrier you use to ship merchandise.   Ship via codes are defined in and validated against the Ship Via table using Working with Ship Via Codes (WVIA). Numeric, 2 positions; optional.
$ Limit to Hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the service bureau/AVS response code/entity/ship via code combination and the dollar amount the requires authorization is greater than the amount defined for the ship via dollar limit. The system assigns the hold reason code defined for the ship via dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the ship via dollar amount specified. Numeric, 13 positions with a 2-place decimal; optional.
Hold Reason	The hold reason code to assign to orders whose authorization amount is greater than the ship via dollar limit. Alphanumeric, 2 positions; optional.
Description	A description of the hold reason code. Alphanumeric, 50 positions; optional.

Screen Option	Procedure
Change a ship via dollar limit	Select Change for a ship via dollar limit to hold to advance to the Change Ship Via $ Limit to Hold Screen. At this screen you can change the ship via, dollar limit, and hold reason code. See the Create Ship Via $ Limit to Hold Screen for field descriptions.
Delete a ship via dollar limit	Select Delete for a ship via dollar limit to hold to delete it.
Display a ship via dollar limit	Select Display for a ship via dollar limit to hold to advance to the Display Ship Via $ Limit to Hold Screen. You cannot change any information at this screen. See the Create Ship Via $ Limit to Hold Screen for field descriptions.
Create a ship via dollar limit	Select Create to advance to Create Ship Via $ Limit to Hold Screen.

Create Ship Via $ Limit to Hold Screen

Purpose: Use this screen to create a ship via dollar limit.

How to display this screen: Select Create on the Work with Ship Via $ Limit to Hold Screen.

Field	Description
Authorization service	The code and description of the service bureau for which you are creating a ship via dollar limit. This is the service bureau you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description of the AVS response code assigned by the service bureau that identifies whether the credit card pass address verification. This is the AVS response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Work with Vendor Response Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Ship via	A code for the carrier you use to ship merchandise.   An error message indicates if you try to create a ship via dollar limit for a ship via that already has a dollar limit defined for this AVS response code and entity: Duplicate record exists. Ship via codes are defined in and validated against the Ship Via table using Working with Ship Via Codes (WVIA). Numeric, 2 positions; optional.
$ limit to hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the service bureau/AVS response code/entity/ship via code combination and the dollar amount that requires authorization is greater than the amount defined for the ship via dollar limit. The system assigns the hold reason code defined for the ship via dollar limit to the order. Conversely, if you do not define a dollar limit, the system does not place an order on hold if the order does not pass AVS authorization, but is under the ship via dollar amount specified. An error message indicates if you try to enter a dollar limit that is less than $1.00: Ship Via $ Limit cannot be less than One. Numeric, 13 positions with a 2-place decimal; optional.
Hold reason	A code for the hold reason the system assigns to the order when the authorization amount is greater than the ship via dollar limit. This is a paytype level hold; the order will be put on AT hold.   The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations. No pick slip prints if the order is on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Alphanumeric, 2 positions; optional.

Work with Pay Type $ Limit to Force Authorization Screen

Purpose: Use this screen to create and maintain pay type dollar limits.

Pay type dollar limit defines whether a dollar limit to force an authorization is applied to a specific pay type.

See Entity pay type dollar limits for more information on the processing the system performs.

Note:

If you are performing online authorization, the system does not validate entity pay type dollar limit.

How to display this screen: On the Work with Vendor Response Screen, select Pay Type $ Limit for an entity.

Field	Description
Authorization service	The code and description of the service bureau for which you are working with pay type dollar limits for a vendor response. This is the service bureau you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description of the vendor response assigned by the service bureau that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. This is the vendor response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Pay type	A code used to identify a method of payment on an order. Pay type codes are defined in and validated against the Pay Type table. Numeric, 2 positions; optional.
Description	A description of the pay type. Alphanumeric, 30 positions; display-only.
Dollar limit to force authorization	The dollar limit that indicates whether the order is eligible for a forced authorization. If the dollar amount for the credit card is greater than $1.00 but less than the dollar amount defined, the system forces an authorization. Note:  If you wish to force authorizations for credit cards requiring authorizations less than $1.00, enter an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value. Numeric, 13 positions with a 2-place decimal; optional.

Screen Option	Procedure
Change a pay type dollar limit	Select Change for a pay type dollar limit to advance to the Change Pay Type $ Limit to Force Authorization Screen. You can change the pay type code or dollar amount on this screen. See the Create Pay Type $ Limit to Force Authorization Screen for field descriptions.
Delete a pay type dollar limit	Select Delete for a pay type dollar limit to delete it.
Display a pay type dollar limit	Select Display for a pay type dollar limit to advance to the Display Pay Type $ Limit to Force Authorization Screen. You cannot change any information at this screen. See the Create Pay Type $ Limit to Force Authorization Screen for field descriptions.
Create a pay type dollar limit	Select Create to advance to the Create Pay Type $ Limit to Force Authorization Screen.

Create Pay Type $ Limit to Force Authorization Screen

Purpose: Use this screen to create a pay type dollar limit.

How to display this screen: Select Create on the Work with Pay Type $ Limit to Force Authorization Screen.

Field	Description
Authorization service	The code and description of the service bureau for which you are creating a pay type dollar limit for a vendor response. This is the service bureau you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description of the response assigned by the service bureau that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. This is the vendor response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Pay type	A code used to identify a method of payment on an order. Pay type codes are defined in and validated against the Pay Type table; see Working with Pay Types (WPAY). An error message indicates if you try to create a pay type dollar limit for a pay type that already has a pay type dollar limit defined for this vendor response and entity: Duplicate record exists. An error message indicates if you enter a pay type other than a credit card pay type: Pay Type entered must be a credit card. Numeric, 2 positions; required.
$ limit to authorization	The dollar amount that you wish to use to force a credit card authorization.   If the dollar amount defined for the credit card is greater than $1.00 but less than the amount you define, the system forces the credit card authorization. If the dollar amount defined for the credit card is equal to or greater than the amount you define, the system does not authorize the credit card. An error message indicates if you enter a dollar amount that is less than $1.00: Pay Type $ Limit cannot be less than One Dollar ($1.00). Note:  If you wish to force authorizations for credit cards requiring authorizations less than $1.00, enter an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value. Numeric, 13 positions with a 2-place decimal; required.

Work with Item Class $ Limit to Hold Screen

Purpose: Use this screen to create and maintain item class dollar limits.

Item class dollar limit defines whether a dollar limit is applied to the item class associated with an item on the order that requires authorization.

• 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.

You might use this if you want to keep a careful check for stolen credit cards. For example, you can place an order on hold if at least one of the items on the order requesting authorization is assigned to item class PNT (high-fraud items) and the dollar amount required for authorization is greater than $200.00.

See Entity item class dollar limits for more information on the processing the system performs.

How to display this screen: Select Item Class $ Limit for an entity on the Work with Vendor Response Screen.

Field	Description
Authorization service	The code and description to identify the service bureau for which you are working with item class dollar limits. This is the service bureau you selected on the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the service bureau that identifies whether the credit card passed address verification. This is the AVS response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Item class	A code for an item class used to group like items together. Item class codes are defined in and validated against the Item Class table. Alphanumeric, 3 positions; optional.
$ Limit To Hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the service bureau/AVS response code/entity/item class combination and the dollar amount that requires authorization is greater than the amount defined for the item class dollar limit. The system assigns the hold reason code defined for the item class dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the item class dollar amount specified. Numeric, 13 positions with a 2-place decimal; optional.
Hold Reason/Description	The code and description of the hold reason to assign to orders whose authorization amount is greater than the item class dollar limit. Code: Alphanumeric, 2 positions; optional. Description: Alphanumeric, 50 positions; display-only.

Screen Option	Procedure
Create an item class dollar limit	Select Create to advance to the Create Item Class $ Limit to Hold Screen.
Change an item class dollar limit	Select Change for an item class dollar limit to hold to advance to the Change Item Class $ Limit to Hold Screen.
Delete an item class dollar limit	Select Delete for an item class dollar limit to hold to delete it.
Display an item class dollar limit	Select Display for an item class dollar limit to hold to advance to the Display Item Class $ Limit to Hold Screen.

Create Item Class $ Limit to Hold Screen

Purpose: Use this screen to create an item class dollar limit.

How to display this screen: Select Create at the Work with Item Class $ Limit to Hold Screen.

Field	Description
Authorization service	The code and description of the service bureau for which you are creating an AVS response item class dollar limit. This is the service bureau you selected at the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description of the AVS response code assigned by the service bureau that identifies whether the credit card passed address verification. This is the AVS response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected at the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Item class	A code for an item class used to group like items together. Item class codes are defined in and validated against the Item Class table. An error message indicates if you try to create an item class dollar limit for an item class that already has a dollar limit defined for the vendor response code and entity: Duplicate record exists. Alphanumeric, 3 positions. Create screen: required. Change screen: display-only.
$ limit to hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the service bureau/AVS response code/entity/item class combination and the dollar amount that requires authorization is greater than the amount defined for the item class dollar limit. The system assigns the hold reason code defined for the item class dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the item class dollar amount specified. An error message indicates if you try to enter a dollar limit that is less than $1.00: Item Class $ Limit cannot be less than $1.00. Numeric, 13 positions with a 2-place decimal; required.
Hold reason	A code for the hold reason the system assigns to the order when the order meets the item class dollar limit hold requirements. This is a paytype level hold; the order will be put on AT hold. The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations. No pick slip prints if the order is on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Alphanumeric, 2 positions; optional.

Change Item Class $ Limit to Hold Screen

To change: At the Work with Item Class $ Limit to Hold Screen, select Change for an item class dollar limit to hold to advance to the Change Item Class $ Limit to Hold screen. At this screen, you can change the $ limit to hold and hold reason code.

See Create Item Class $ Limit to Hold Screen for a description of the fields on this screen.

Display Item Class $ Limit to Hold Screen

To display: At the Work with Item Class $ Limit to Hold Screen, select Display for an item class dollar limit to hold to advance to the Display Item Class $ Limit to Hold screen. You cannot change any fields on this screen.

See Create Item Class $ Limit to Hold Screen for a description of the fields on this screen.

Work with Postal Code $ Limit to Hold Screen

Purpose: Use this screen to create and maintain postal code dollar limits.

Postal code dollar limit defines whether a dollar limit is applied to the postal code for the 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 amount 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.

You might use this if you want to keep a careful check for stolen credit cards. For example, you can place an order on hold if the order is associated with a high-crime delivery area and the dollar amount required for authorization is greater than $200.00.

See Entity postal code dollar limits for an example and additional processing logic.

How to display this screen: Select Postal Code $ Limit for an entity at the Select Entity for Vendor Response Details Screen.

Field	Description
Authorization service	The code and description of the service bureau for which you are working with postal code dollar limits. This is the service bureau you selected on the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the service bureau that identifies whether the credit card passed address verification. This is the vendor response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Postal code	A code for a postal code or zip code representing a delivery area. Alphanumeric, 10 positions; optional.
$ Limit To Hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the service bureau/AVS response code/entity/postal code combination and the dollar amount that requires authorization is greater than the amount defined for the postal code dollar limit. The system assigns the hold reason code defined for the postal code dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the postal code dollar amount specified. Numeric, 13 positions with a 2-place decimal; optional.
Hold Reason/Description	The code and description of the hold reason to assign to orders whose authorization amount is greater than the postal code dollar limit. Code: Alphanumeric, 2 positions; optional. Description: Alphanumeric, 50 positions; display-only.

Screen Option	Procedure
Create a postal code dollar limit to hold	Select Create to advance to the Create Postal Code $ Limit to Hold Screen.
Change a postal code dollar limit to hold	Select Change for a postal code dollar limit to hold to advance to the Change Postal Code $ Limit to Hold Screen.
Delete a postal code dollar limit to hold	Select Delete for a postal code dollar limit to hold to delete it.
Display a postal code dollar limit to hold	Select Display for a postal code dollar limit to hold to advance to the Display Postal Code $ Limit to Hold Screen.

Create Postal Code $ Limit to Hold Screen

Purpose: Use this screen to create a postal code dollar limit.

How to display this screen: Select Create at the Work with Postal Code $ Limit to Hold Screen.

Field	Description
Authorization service	The code and description of the service bureau for which you are creating an AVS response postal code dollar limit. This is the service bureau you selected at the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description of the AVS response assigned by the service bureau that identifies whether the credit card passed address verification. This is the AVS response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected at the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Postal code	A code for a postal code or zip code representing a delivery area. Postal codes are defined in and validated against the Zip/City/State table. An error message indicates if you try to create a postal code dollar limit for a postal code that already has a dollar limit defined for the AVS response and entity: Duplicate record exists. Alphanumeric, 5 positions. Create screen: required. Change screen: display-only.
$ limit to hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the service bureau/AVS response code/entity/postal code combination and the dollar amount that requires authorization is greater than the amount defined for the postal code dollar limit. The system assigns the hold reason code defined for the postal code dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the postal code dollar amount specified. An error message indicates if you try to enter a dollar limit that is less than $1.00: Postal Code $ Limit cannot be less than $1.00. Numeric, 13 positions with a 2-place decimal; required.
Hold reason	A code for the hold reason the system assigns to the order when the authorization amount is greater than the postal code dollar limit. This is a paytype level hold; the order will be put on AT hold. The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations. No pick slip prints if the order is on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Alphanumeric, 2 positions; optional.

Change Postal Code $ Limit to Hold Screen

To change: At the Work with Postal Code $ Limit to Hold Screen, select Change for a postal code dollar limit to hold to advance to the Change Postal Code $ Limit to Hold screen. At this screen, you can change the $ limit to hold and hold reason code.

See Create Postal Code $ Limit to Hold Screen for a description of the fields on this screen.

Display Postal Code $ Limit to Hold Screen

To display: At the Work with Postal Code $ Limit to Hold Screen, select Display for a postal code dollar limit to hold to advance to the Display Item Class $ Limit to Hold screen. You cannot change any fields on this screen.

See Create Postal Code $ Limit to Hold Screen for a description of the fields on this screen.

Defining Merchant ID Overrides

Purpose: Use merchant ID overrides to set up overrides for the different entities in your company.   

When used: You use the merchant ID, which the service bureau assigns, to identify your company when you transmit information to the service bureau. Although you can set up a default ID for your company, you may need to set up overrides for each separate entity under which you perform authorizations and deposits.

Access to screens: The screens you use to work with merchant ID overrides are available through the Work with Authorization Services Screen.

Source code points to entity: The system determines the entity for a customer order based on the source code on the order header.  When you create a source code you must specify a division, and when you create a division you must specify an entity.  In this way, the source code on the order header indicates which merchant ID override to use for transactions related to the order.

Deferred/installment pay plans: If you use deferred or installment billing, you would also use these screens to set up merchant ID overrides for transactions related to these orders. See Deferred/Installment Billing Overview for more information on pay plans.

In this topic:

• Work with Merchant ID Overrides Screen

• Create Merchant ID by Entity Screen

For more information:

• Introducing Offer and Source Codes 

• Working with Entities (WENT)

• Working with Divisions (WDIV)

Work with Merchant ID Overrides Screen

How to display this screen: Select Merchant ID Override for an authorization service at the Work with Authorization Services Screen.

Field	Description
Authorization service	The service code representing the authorization service you selected at the Work with Authorization Services Screen. Alphanumeric, 3 positions; display-only.
Entity	The code representing an entity with a unique merchant ID. Numeric, 3 positions; optional.
Merchant ID	An account number assigned by the service bureau to identify transmissions to/from a particular entity in your company. The default merchant ID, used for regular (as opposed to pay plan) transactions displays. To review the deferred or installment merchant IDs, select Change or Display for the entity. Alphanumeric, 20 positions; optional.

Screen Option	Procedure
Create a new merchant ID override	Select Create to advance to the Create Merchant ID by Entity Screen.
Change a merchant ID override	Select Change for a merchant ID override to advance to the Change Merchant ID Override Screen. At this screen, you can change the merchant ID fields and API fields. See the Create Merchant ID by Entity Screen for field descriptions.
Delete a merchant ID override	Select Delete for a merchant ID override to delete it.
Display a merchant ID override	Select Display for a merchant ID override to advance to the Display Merchant ID Override Screen. You cannot change any information at this screen. See the Create Merchant ID by Entity Screen for field descriptions.

Create Merchant ID by Entity Screen

Purpose: Use this screen to create a new merchant ID override for orders associated with a specific entity in your company.

How to display this screen: Select Create at the Work with Merchant ID Overrides Screen.

Field	Description
Entity	Enter the entity associated with the merchant ID. Entities are defined in and validated against the Entity table; see Working with Entities (WENT). Numeric, 3 positions. Create screen: required. Change screen: display-only.
Merchant ID	Enter the merchant ID to use when transmitting information to an authorization or deposit service for orders associated with this entity (based on the division associated with the source code on the order header).  This is the merchant ID to use for regular, as opposed to pay plan, transactions. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 positions; required.
Deferred merchant ID	Enter the merchant ID to use when transmitting transactions to a service bureau for orders that are associated with this entity, and which are using a deferred billing pay plan.   Deferred and installment pay plans are available only if the Deferred and Installment Billing (F51) system control value is selected. See Deferred/Installment Billing Overview. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 position; optional.
Installment merchant ID	Enter the merchant ID to use when transmitting transactions to a service bureau for orders that are associated with this entity, and which are using an installment plan. Deferred and installment pay plans are available only if the Deferred and Installment Billing (F51)Deferred and Installment Billing (F51) system control value is selected. See Deferred/Installment Billing Overview. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 positions; optional.
API User name	The user name, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 64 positions; optional.
API Password	The password, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 64 positions; optional.
API Signature	The encrypted signature, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 128 positions; optional.

Defining Authorization Service Currencies

Purpose: Use the Work with Authorization Currency function to set up cross references between the currency codes you use in Order Administration and the service bureau's codes. The system uses these cross references to determine which currency code to pass to the service bureau when authorizing credit cards and processing deposits.

In this topic:

• Work with Authorization Service Currency Screen

• Create Authorization Service Currency Screen

Work with Authorization Service Currency Screen

How to display this screen: Select Currency for the authorization service at the Work with Authorization Services Screen.

Field	Description
Authorization service	The service to use the cross references. The service you selected at the Work with Authorization Services Screen displays. Code:  alphanumeric, 3 positions; display-only. Description:  alphanumeric, 30 positions; display-only.
Currency	The code identifying a type of currency in Order Administration.    Currency codes are defined in and validated against the Currency table; see Working with Currency (WCUR). Alphanumeric, 3 positions; optional.
Authorization Service Currency	The related currency code used by the authorization service. Alphanumeric, 3 positions; optional.

Select Option	Procedure
Change an authorization service currency code  cross reference	Select Change for a currency code to advance to the Change Authorization Service Currency Screen. At this screen you can change only the authorization service currency code. See the Create Authorization Service Currency Screen for field descriptions.
Delete an authorization service currency code	Select Delete for a currency code to delete it.
Display an authorization service currency code cross reference	Select Display for a currency code to advance to the Display Authorization Service Currency Screen. You cannot change any information at this screen. See the Create Authorization Service Currency Screen for field descriptions.
Create an authorization service currency code cross reference	Select Create to advance to the Create Authorization Service Currency Screen.

Create Authorization Service Currency Screen

Purpose: Use this screen to define an equivalency between a currency code in your company and a currency code used by the service bureau.

How to display this screen: Select Create at the Work with Authorization Service Currency Screen.

Field	Description
Authorization service	The service bureau to use the cross references. The service bureau you selected at the Work with Authorization Services Screen displays. Code:  alphanumeric, 3 positions; display-only. Description:  alphanumeric, 30 positions; display-only.
Currency	The code identifying a type of currency in your company.    Currency codes are defined in and validated against the Currency table; see Working with Currency (WCUR). Alphanumeric, 3 positions. Create screen: optional. Change screen: display-only.
Authorization service currency	The related currency code used by the service bureau. Alphanumeric, 3 positions; optional.

Performing Online Credit Card Authorizations

Overview: Online credit card authorization allows you to send and receive the information required to authorize a credit card when the order is placed instead of when the pick slip is generated for the order.

Quotes: If the Online Authorization field for a quote order type is selected, the system performs online authorization during quote entry; see Entering Pre-Order Quotes for an overview.

In this topic: This topic provides an overview of the online credit card authorization process and the required setup.

• Receiving a Credit Card Authorization During Order Entry

  • What Credit Card Amount is Sent for Authorization?

  • Hierarchy for Placing the Credit Card On Hold

  • What Happens When a Credit Card is Approved?

  • What Happens When a Credit Card is Declined?

  • When Communication Failures Occur

  • What Happens When an Undefined Response is Returned?

  • Select Authorization Response Option Window

• Resending Credit Cards for Authorization

• Pick Slip Generation

• Credit Card Authorization List

• Transmitting and Receiving Deposits

• Online Authorization Process

• Online Credit Card Authorization Setup

  • System Control Values

  • Number Assignment Value

  • Service Bureau Settings

  • Order Types

  • Pay Types

  • Pick Slip Generation

Receiving a Credit Card Authorization During Order Entry

The system performs online authorization when you select Accept to accept an order after determining if the order should go on hold due to the credit card payment method. Note that online authorization can still take place if the order is on hold for another reason, provided the order is eligible.

Generic order interface: If you receive orders through the Generic Order Interface (Order API), the system performs online authorization after determining if the order should go on hold and performing credit card tokenization; see Performing Online Credit Card Authorization on Web Orders.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Batch order entry: If you are using batch order entry, the system performs online authorization when you accept a batch at the Work with Error Orders Batches Screen or Select Customer Sold To For Order Screen.

Order maintenance: The system performs online authorization when you select Auth On-Line for a credit card payment on the Enter Payment Methods Screen.

When you convert a quote to an order in order maintenance, the system will perform online authorization for eligible payment methods only if the Authorize Full Amount During Order Entry (G99) system control value is selected; see Converting Quotes to Orders.

1. The system determines if the order is eligible for online authorization. In order to receive a credit card authorization during order entry:

• the On-line Authorizations (B89) system control value must be selected.

• the order type defined for the order must be eligible for online authorizations (the On-line authorization field is set to Window (on-line eligible and display window) or Without Window (on-line eligible and do not display window).

• the order must have a credit card, stored value card, or debit (Switch) card payment method.

• the order must be in an open or suspended status. Note: You can authorize a credit card payment during order maintenance when the order is on hold; regardless of whether the payment is authorized, the order remains on hold.

• the arrival date on the order cannot be greater than the current date.

  Express bill orders: When you enter a credit card payment method on an express bill order, you must manually authorize the card or the order must be eligible for online authorization. However, since you cannot enter the Authorization Request ID at this screen, Oracle recommends that you instead use the Add Authorization option from the Order Summary page in Modern View to apply a manual authorization.

  See Online Credit Card Authorization Setup for more information on setting up the required values for online authorization.

2. The system determines the amount to authorize.

What Credit Card Amount is Sent for Authorization?

• If the Online Auth Verification Only (I96) system control value is selected, 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.

• If the Online Auth Verification Only (I96) system control value is unselected, the system looks at the setting of the Authorize Full Amount During Order Entry (G99) system control value to determine the amount sent for authorization.

The Authorize Full Amount During Order Entry (G99) system control value determines if the credit card is authorized for the full order amount or for the shippable amount on the order.

Authorize full amount...	Authorize shippable amount...
The system sends the entire dollar amount defined for the credit card for authorization. If the credit card is the only payment method... The amount to authorize is the order total. The order total is the sum of all charges on the order, including: merchandise, freight, additional freight, tax, handling, additional charges, GST and PST.	The system sends the dollar amount associated with what is shippable on the order, across all ship to customers, for authorization. If the credit card is the only payment method... This shippable dollar amount includes: shippable merchandise amount, including drop ship items tax associated with the shippable merchandise amount total freight total additional freight total order level additional charges Note:  The system sends the total freight and total additional freight for authorization, regardless of whether you are prorating freight charges (the Prorate Freight Charges (D39) system control value is selected).
If the credit card is the catch-all payment method... The amount to authorize is the remaining dollar amount not associated with another payment method on the order. The system subtracts the amount applied to any other payment methods from the order total. order total - dollar amount associated with other payment methods = amount to authorize for this credit card	If the credit card is the catch-all payment method... The amount to authorize is the remaining shippable dollar amount not associated with another payment method on the order. The system subtracts the amount applied to any other payment methods from the shippable dollar amount. shippable dollar amount - dollar amount associated with other payment methods = amount to authorize for this credit card Excluded from authorizations: order lines with a future arrival date order lines on backorder, canceled, closed, or sold out reserved order lines that are coordinate grouped with an order line on backorder or with an order line with a future arrival date

Excluded from authorizations:

• order lines with a future arrival date

• order lines on backorder, canceled, closed, or sold out

• reserved order lines that are coordinate grouped with an order line on backorder or with an order line with a future arrival date

Regardless of whether you are authorizing the full amount or the shippable amount...

Included in authorizations:

• express bill order lines

• drop ship order lines

• non-inventory order lines

Deferred Billing

If the credit card on the order is associated with a deferred pay plan, the system:

• sends an authorization for $1.00 if the Authorize full amount field for the pay plan is unselected.

• sends an authorization for the dollar amount available for authorization if the Authorize full amount field for the pay plan is selected.

Installment Billing

If the credit card on the order is associated with an installment pay plan, the system:

• sends an authorization for the first installment amount if the Authorize full amount field for the pay plan is unselected.

• sends an authorization for the dollar amount available for authorization if the Authorize full amount field for the pay plan is selected.

If more than one credit card is sent for authorization:

The system sends for authorization the credit card defined with a dollar amount, then sends the catch-all credit card for authorization.

Credit cards requiring authorizations less than $1.00: 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.

3. The system sends the authorization amount to the service bureau. If there is an amount to authorize for the credit card, the system sends an authorization request in online format to the service bureau.

4. The service bureau sends back a response. The service bureau sends an authorization response to Order Administration.

There are 3 types of responses you can receive from the service bureau.

• R = an authorization response is received, such as declined or approved

• T = the program timed out before an authorization response was received

• U = an undefined response

Additionally, if an authorization response is received, the service bureau sends back an authorization response code, AVS response code (if performing address verification), CID response code (if performing credit card identification verification), authorization code, and date.

Vendor response settings: If a pop up window message has been defined for the vendor response received, the system displays the Select Authorization Response Option Window. Also, if a hold reason code has been defined for the vendor response received, the system places the order on hold.

Oracle Retail Customer Engagement stored value cards: When using the Customer Engagement Stored Value Card Integration, if the Oracle Retail Customer Engagement stored value card is the only payment on the order and the amount authorized for the card is less than the order total, Order Administration updates the amount for the card with the amount authorized and displays the message Insufficient balance on card - please add another payment. In order to accept the order, you must add another payment to the order to cover the amount of the order that is not covered by the Oracle Retail Customer Engagement stored value card. Example: If the order total is 500.00 and the amount authorized for the Oracle Retail Customer Engagement stored value card is 236.20, the system updates the amount for the card to 236.20 and requires another form of payment to cover the remaining 289.55 balance on the order.

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 CID verification fails.

The system uses this hierarchy to determine if the credit card pay type should go on hold:

• Authorization 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.

• 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 credit 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).

What Happens When a Credit Card is Approved?

When a credit card is approved during order entry, the system:

• Select Authorization Response Option Window

• places the order on hold if a hold reason code has been defined for the vendor response. Typically, if an authorization is approved, the order is not placed on hold. However, if the credit card is approved but fails address verification or card identification verification, you may want to place the order on hold.

• once you accept the order, you return to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table indicating the order number, that the credit card has been approved, the dollar amount authorized, the transaction sequence number, and the authorization number. The status for this authorization is *UPDT, indicating the online authorization has completed.

• creates a record in the Authorization History table indicating the credit card has been approved, the authorization number, the date the credit card was authorized, and the dollar amount authorized. If you reject an order after the credit card has been approved, the system removes the record in the Authorization History table. You can review authorization history at the Display Authorization History Screen.

• creates a record in the Void Authorization table indicating the order number and the dollar amount eligible for void. If you reject an order after the credit card has been approved, the system removes the record from the Void Authorization table.

AVS response: If the credit card charge is approved (authorized) but the order fails the address verification check and receives an AVS response that has a hold reason code, the system:

• places the order on AT hold.

• places the credit card payment method on the order on AV (AVS) hold.

• creates an order transaction history message indicating the credit card was declined: SYS HLD - DECLINED CREDIT CARD.

• updates the record in the On-Line Authorization table indicating the credit card failed AVS. The OLA AVS result field is updated with the AVS response received from the service bureau. You can review the response at the Authorization History Details Window.

• updates the record in the Authorization History table indicating the credit card failed AVS. The AUH status field is updated to O (authorized but not used) and the AVS response field is updated with the AVS response received from the service bureau. You can review the status of the credit card and the AVS response at the Authorization History Details Window.

You must contact the customer and obtain correct address information, then take the order off of hold through the Release Held Orders function and resend for authorization.

If the authorization has not yet expired and the transaction passes AVS, the system updates the credit card authorization record from an O (authorized but not used) status to an A (approved) status. If the authorization has expired, the system updates the credit card authorization record from an O (authorized but not used) status to a D (declined) status and resends the credit card for authorization and address verification.

Card security identification response: If the credit card charge is approved (authorized) but the order fails the credit card security check and receives a card security identification response (CID, CVV2, CVC2) that has a hold reason code, the system:

• places the order on AT hold.

• places the credit card payment method on the order on CF (credit card fraud) hold.

• creates an order transaction history message indicating the credit card was declined: SYS HLD - DECLINED CREDIT CARD.

• updates the record in the On-Line Authorization table indicating the credit card failed card security. The OLA vendor response 2 field is updated with the card security response received from the service bureau. You can review the response at the Authorization History Details Window.

• updates the record in the Authorization History table indicating the credit card failed card security. The AUH status field is updated to O (authorized but not used) and the Vendor response 2 field is updated with the card security response received from the service bureau. You can review the status of the credit card and the card security response at the Authorization History Details Window.

You must contact the customer to verify credit card ownership, then take the order off of hold through the Release Held Orders (ERHO) menu option and resend for authorization.

If the authorization has not yet expired and the transaction passes card security identification, the system updates the credit card authorization record from an O (authorized but not used) status to an A (approved) status. If the authorization has expired, the system updates the credit card authorization record from an O (authorized but not used) status to a D (declined) status and resends the credit card for authorization and card security identification.

Voiding an online authorization: After receiving an online authorization, if you change the price of an item in Order Maintenance, the stem voids the authorization. Because the authorization is voided, the system sends the order for batch authorization during pick slip generation.

What Happens When a Credit Card is Declined?

When a credit card is declined during order entry, the system:

• displays the Select Authorization Response Option Window if a vendor response pop up window message has been defined, the On-line authorization field for the order type is set to Window (on-line eligible and display window), and a Response time is defined for the service bureau. The message should indicate the credit card has been declined and any action you should take to correct the decline or inform the customer. From this window, you can accept the order or return to the order to make any corrections.

• places the order on hold: If a hold reason code is defined for the vendor response, the system assigns this hold reason code to the order payment method and places the order header on AT (Declined Credit Card) hold. If the response received is not defined for the service bureau, the system places the order payment method on AV (Invalid Response Code) hold.

• once you accept the order you return to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table indicating the order number, that the credit card has been declined, the dollar amount submitted for authorization, and the transaction sequence number. The status of this authorization is *UPDT, indicating the online authorization has been completed.

• creates a record in the Authorization History table indicating the credit card has been declined, the reason why the credit card was declined, the date the credit card was declined, and the dollar amount submitted for authorization. If you reject the order after the credit card has been declined, the system removes the record from the Authorization History table. You can review authorization history at the Display Authorization History Screen.

You can send the credit card up for authorization again during order maintenance, using the Performing Batch Authorization (SATH) menu option, or during pick slip generation if the Batch/on-line field for the service bureau contains a C (on-line and batch authorizations).

When Communication Failures Occur

Communication failures can occur if 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 display the Select Authorization Response Option Window since a vendor response was not received.

• accepts the order and returns you to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table. The status of this authorization is:

• RDY, indicating online authorization has not been performed.

• SENT, indicating the online authorization transmission failed after the credit card was sent to the service bureau for authorization.

• RCVD, indicating the online authorization transmission failed after a response was received from the service bureau, but final updates could not be completed. This may occur if the Online Authorization integration job became inactive. The authorization does not complete processing until the job is active. Once the Online Authorization integration job is active, the system updates the status of the authorization to *UPDT.

• creates a record in the Authorization History table indicating the credit card is waiting for authorization, the date the credit card was sent for authorization, and the dollar amount waiting for authorization.

The amount of time the system waits for an authorization is defined in the Response time field for the service bureau.

Grace period: The system allows a 2 day grace period to receive a response from the service bureau if the status of the authorization 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. You will need to resend the credit card for authorization during order maintenance or pick slip generation.

What Happens When an Undefined Response is Returned?

When an undefined response is returned, the system:

• does not display the Select Authorization Response Option Window since this vendor response has not been defined for the service bureau.

• places the order on AVS hold.

• accepts the order and returns you to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table indicating the order number, that the credit card is waiting for authorization, the dollar amount waiting for authorization, and the transaction sequence number. The status of this authorization is *RDY, indicating online authorization has not been performed.

• creates a record in the Authorization History table indicating the credit card is waiting for authorization, the date the credit card was sent for authorization, and the dollar amount waiting for authorization.

You can resend the order for authorization during order maintenance, using the Performing Batch Authorization (SATH) menu option, or during pick slip generation if the Batch/on-line field for the service bureau contains a C (on-line and batch authorizations).

Select Authorization Response Option Window

Use this window to review the response received from the service bureau and any messages defined for this vendor response.

Once you review the message, you can accept the order or return to the order to make any corrections or reject the order.

Typically, a vendor response pop up window message is defined for a vendor response indicating a declined authorization, declined address verification, or declined card identification verification.

How to display this screen: This window displays when you select Accept to accept an order in order entry if:

• the dollar amount defined for the credit card payment method on the order was sent up for authorization and received a response, and

• the On-line authorization field for the order type on the order is set to Window (on-line eligible and display window), and

• a Response time is defined for the service bureau, and 

• the Pop up window messages field for the vendor response returned by the service bureau contains text.

Note:

The Pop up window messages # 1 field must contain text in order to display this window. If you define text in the Pop up window messages # 2 - # 4 fields and not in the Pop up window messages # 1 field, this window will not display.

This window displays for each credit card payment method on the order that is sent up for authorization and meets the criteria above.

What message displays? You can receive a response from the service bureau for the authorization, address verification (AVS), and credit card security identification (CID, CVV2, CVC2). If you receive a response for the authorization, AVS verification, and card security identification, the system uses the following hierarchy to determine the pop up window message that displays in the Select Authorization Response Option window:

• Authorization response has a message defined: the message associated with the authorization response displays in the Select Authorization Response Option window.

• AVS response has a message defined: if the authorization response does not have a message defined, the message associated with the AVS response displays in the Select Authorization Option window.

• Card security identification response has a message defined: if the authorization response and AVS response do not have a message defined, the message associated with the card security response displays in the Select Authorization Option window.

Batch order entry: This window does not display if you are performing online credit card authorization during batch order entry.

Order maintenance: The Select Authorization Response Option window displays if you are performing online credit card authorization during order maintenance. You can authorize a credit card during order maintenance by selecting On-line Auth for a credit card payment method.

Field	Description
Order #	The order number containing the credit card payment method that received this authorization response. Numeric, 8 positions; display-only.
Pay type	The description of the credit card payment method that received the authorization response containing this message text. Alphanumeric, 30 positions; display-only.
Credit card #	The credit card number defined for the credit card payment method used on the order. Information will be provided by Oracle at a later date. Alphanumeric, 20 positions; display-only.
Exp date (credit card expiration date)	The date this credit card is no longer valid. Numeric, 4 positions (MMYY format); display-only.
Auth amt	The amount sent for authorization for this credit card. If this credit card was the catch all payment method on the order or the only payment method on the order, this field is blank. Numeric, 13 positions with a 2-place decimal; display-only.
Vendor response pop up window messages # 1 - # 4	The message text from the Pop up window messages # 1 - # 4 fields for the vendor response you received from the service bureau. This message text should indicate whether the credit card has been approved or declined and any action that you should take to correct any problems and inform the customer. Alphanumeric, four 40-position fields; display-only.

Screen Option	Procedure
Accept the order	Select Accept Order. The system returns you to the Select Customer Sold To For Order Screen or the Customer Selection Screen if the operator placing the order is a CTI user, and processes the order through the Order Async.
Return to the order to make any corrections or reject the order	Select Edit Order. The system returns you to the Work with Order/Recap Screen or the Enter Payment Method Screen where you can make any corrections or reject the order.

Resending Credit Cards for Authorization

If you did not receive a response from the service bureau during order entry or the credit card was declined in order entry, you can resend the credit card for authorization:

• selecting On-line Auth for the credit card at the Enter Payment Methods Screen in Order Maintenance in order maintenance. The system sends the credit card for authorization, waits for a response as in order entry, and displays the Select Authorization Response Option Window if pop up window message text was defined for the vendor response.

• using the Performing Batch Authorization (SATH) menu option. This menu option allows you to send credit cards associated with a selected ship via for authorization.

• during pick slip generation if the Batch/on-line field for the service bureau contains a C (on-line and batch authorizations).

Pick Slip Generation

You can generate pick slips for orders that contain pre-paid payment methods, such as cash or check, and/or credit cards that have received an approved authorization by selecting the Preauthorized orders only field in the pick generation template.

If you try to generate pick slips for orders that contain credit cards that have not been authorized with the Preauthorized orders only field selected and the Use Auto Authorization Interface (C14) system control value selected, the system will not send the credit cards up for authorization and will not generate pick slips.

Note:

If you generate pick slips for preauthorized orders only and records exist in the Authorization History table in an S (sent) status, the system updates the records to a D (decline) status. The next time you generate pick slips with the Preauthorized orders only field unselected, the system sends orders associated with records in the Authorization History table in a D status up for authorization.

Receiving authorizations during pick slip generation: If the credit card has not yet received an approved authorization, you can resend the credit card for authorization during pick slip generation if the Preauthorized orders only field in the pick generation template is unselected and the Batch/on-line field for the service bureau is set to C (batch and on-line authorization). See Authorizations During Pick Slip Generation for more information on receiving authorizations during pick slip generation.

Authorization Listing Screen

Credit Card Authorization List

The Online Credit Card Authorization Listing is a report you can use to review credit cards that have been authorized, declined, or sent for authorization for a specific date range.

You can generate this report by:

• defining selection criteria at the  and selecting Accept.

• sending credit cards for authorization using the Performing Batch Authorization (SATH) menu option.

Note:

The system generates a similar report when you authorize credit cards during pick slip generation; see Online Credit Card Authorization Listing.

Transmitting and Receiving Deposits

After you obtain an authorization for a credit card charge, you can generate a pick slip for the order, 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.

Online Authorization Process

Online Credit Card Authorization Setup

Purpose: Before you can receive online credit card authorizations in your company, you must perform the necessary setup. Information requiring creation and setup includes:

• System Control Values

• Number Assignment Value

• Service Bureau Settings, including response codes and currency codes

• Order Types eligible for online credit card authorization

• credit card Pay Types

• Pick Slip Generation

System Control Values

System Control Value	Description
On-line Authorizations (B89)	Select this field to indicate you will be performing online credit card authorizations. If this field is unselected, you will not be able to authorize credit cards in order entry or order maintenance.
Authorize Full Amount During Order Entry (G99)	Select this field to indicate you will send an order up for authorization for the full order amount. Deselect this field to indicate you will send an order up for authorization for the shippable order amount.
Online Auth Verification Only (I96)	Select this field to indicate you want the system to process 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. If this field is unselected, the system looks at the Authorize Full Amount During Order Entry (G99) system control value to determine the amount sent for authorization.

Number Assignment Value

The number assignment Transaction Sequence # assigns the next available number to the credit card authorization.

Service Bureau Settings

• When you are setting up a service bureau to support online authorization, please note these required settings:

• Industry code: enter your DBA number.

• Batch/on-line: set to I (on-line) to perform only online credit card authorizations; set to C (on-line or batch) to perform both online credit card authorizations and batch credit card authorizations.

• Response time: set the number of seconds the system waits to receive a response from the service bureau before continuing to process the order.

• Pay type cross reference (Paytypes at the Work with Authorization Services Screen): Create a cross-reference for each pay type code for which you wish to receive online credit card authorization, using the vendor pay code information supplied by the service bureau.

• Currency cross reference (Currency at the Work with Authorization Services Screen): Create a cross-reference for each currency code you will use on orders receiving online credit card authorizations, using the vendor currency code information supplied by the service bureau.

• Vendor responses (Responses at the Work with Authorization Services Screen): Optionally, you can define Vendor response pop up window messages. The messages display in a pop up window in order entry when a credit card that was sent up for authorization is declined. You can enter up to four 40-position lines of message text. Set up vendor responses for authorizations, AVS (if you are performing address verification), and CID (if you are performing credit card identification).

Order Types

You define whether an order type is eligible for online 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:

• Window indicates the order type is eligible for online authorizations and the Select Authorization Response Option Window displays.

• Without Window indicates the order type is eligible for online authorization and the Select Authorization Response Option Window does not display.

• Not Eligible indicates the order type is not eligible for online authorization.

Online authorization for web orders: In order to perform online authorization when Order Administration receives the web order through the Generic Order Interface (Order API), the Online Authorization setting for the order type on the web order must be set to Without Window.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Pay Types

Each credit card pay type eligible for online 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.

Pick Slip Generation

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.

Processing Authorizations and Deposits Using Point-to-Point Communication

Purpose: Processing authorizations and deposits using point-to-point communication, allows you to post transactions directly to the service bureau in the format required by the service bureau.

Available Point-to-Point Integrations

Integration	See:
Oracle Retail Customer Engagement Stored Value Card integration: Allows you to process the stored value card transactions between Order Administration and Oracle Retail Customer Engagement in Oracle Retail Customer Engagement’s message format.	Customer Engagement Stored Value Card Integration for an overview and more information on the Oracle Retail Customer Engagement messages used to process stored value card transactions between Order Administration and the Oracle Retail Customer Engagement system using point-to-point communication.

For more information: See:

• Stored Value Card Integration for more information on how to process stored value card transactions.

• Processing Auto Deposits (SDEP) for more information on deposit processing in Order Administration.

PayPal Direct Connection Integration

Purpose: The PayPal Direct Connection integration enables you to use PayPal as a method of payment on web orders.

• The web storefront sends the PayPal payment on the order directly to PayPal for authorization. The order must receive an approved authorization on the web storefront before it is sent to Order Administration for processing.

• During pick slip generation, Order Administration verifies that the amount required to generate the pick slip is covered by the authorization received for the PayPal payment during web storefront processing. If the amount is not covered, the system places the order on Credit Card Decline hold and the PayPal payment on PayPal Decline hold.

• During deposit processing, Order Administration sends the deposit transaction directly to PayPal for confirmation and settlement.

• When an order is canceled or the PayPal payment method deactivated, Order Administration sends an authorization reversal request to PayPal.

PayPal is an e-commerce business that allows you to perform payment and money transfers securely over the Internet. PayPal’s service builds on the existing financial infrastructure of bank accounts and credit cards and utilizes fraud prevention systems to create a safe, global, real-time payment solution.

Note:

PayPal is a registered trademark

The Order Administration PayPal Direct Connection integration allows you to use PayPal as a form of payment on web orders and send the deposit transactions directly to PayPal.

Note:

Because the PayPal Direct Connection Integration does not send authorization transactions between Order Administration and PayPal, web orders containing a PayPal payment must receive an approved authorization on the web storefront before being sent to Order Administration for processing. In addition, you can only use PayPal as a form of payment on web orders. The Order Administration PayPal Direct Connection integration does not support PayPal as a form of payment on non-web orders.

In this topic: This topic provides an overview of the PayPal Direct Connection integration and the required setup.

• PayPal Direct Connection Integration Process

• Processing Orders Containing a PayPal Payment

  • Validating a Web Order that Contains a PayPal Payment

  • Maintaining a PayPal Order

  • Applying Refunds Across Multiple Capture Transaction IDs

• Processing Authorizations for a PayPal Order

  • PayPal Authorization Processing

  • Approved PayPal Authorizations

  • Declined PayPal Authorizations

• Processing Deposits for a PayPal Order

  • PayPal Deposit Processing

  • Approved PayPal Deposits

  • Failed PayPal Deposits

• Purchase Deposit Transactions

  • PayPal DoCapture Request

  • PayPal DoCapture Response

• Return Deposit Transactions

  • PayPal RefundTransaction Request

  • PayPal RefundTransaction Response

• PayPal Authorization Reversals

  • PayPal DoVoid Transaction Request

  • PayPal DoVoid Transaction Response

• PayPal Direct Connection Integration Restrictions

• PayPal Direct Connection Integration Troubleshooting

  • PayPal Log

• PayPal Direct Connection Integration Setup

  • Creating the PayPal Decline Order Hold Reason

  • Creating the PPL (PayPal) Service Bureau

  • Creating a PayPal Pay Type

PayPal Direct Connection Integration Process

• Processing Orders Containing a PayPal Payment

  • Validating a Web Order that Contains a PayPal Payment

  • Maintaining a PayPal Order

• Processing Authorizations for a PayPal Order

• Processing Deposits for a PayPal Order

PayPal Direct Connection integration illustration:

Processing Orders Containing a PayPal Payment

When a customer places an order on the web storefront and pays for the order using a PayPal account:

• The web storefront sends an authorization request for the PayPal payment directly to PayPal.

• PayPal validates the PayPal account number that is passed in the authorization request and sends PayPal confirmation information back to the web storefront.

• The web storefront completes the order and sends the order to Order Administration in the Inbound Order XML Message (CWORDERIN).

Web orders containing a PayPal payment that has been authorized by PayPal contain the following information in the Inbound Order XML Message (CWORDERIN). The authorization for the PayPal payment is sent to Order Administration as a manual authorization.

For more information see the Web Services Guide on My Oracle Support (ID 2953017.1).

• Regular order information

• PayPal pay type passed in the payment_type field

• PayPal transaction ID passed in the cc_number field

• Approved PayPal payment:

  • auth_amount

  • auth_number (this is the first 16 positions of the PayPal transaction ID)

  • auth_date (this is the date the PayPal payment was authorized with PayPal)

Validating a Web Order that Contains a PayPal Payment

Because the PayPal Direct Connection Integration does not send authorization transactions between Order Administration and PayPal, web orders containing a PayPal payment must receive an approved authorization on the web storefront before being sent to Order Administration for processing.

If Order Administration receives a web order that contains a PayPal payment that has not yet received an approved authorization, the system will accept the order; however, the PayPal payment will fail batch authorization and you will not be able to generate a pick slip for the order. See Processing Authorizations for a PayPal Order.

Maintaining a PayPal Order

When you advance to an order in order maintenance that contains a pay type with PPL (PayPal) defined as the authorization service and deposit service, the system displays the PayPal Warning Window indicating that you should not make any changes to the order that would increase the order total. When you generate a pick slip for an order that contains a PayPal payment, the system validates that the amount required to generate the pick slip does not exceed 15% or $75.00 of the initial authorization amount that was received from PayPal during web storefront processing.

Examples:

• If the authorization received from PayPal during web storefront processing is $100.00, you can increase the order total up to $115.00 ($100.00 + 15% = $115.00) and still process the order without any problems. However, once you exceed $115.00, the PayPal payment will fail batch authorization and the system will not generate a pick slip or perform drop ship processing for the order.

• If the authorization received from PayPal during web storefront processing is $600.00, you can increase the order total up to $675.00 and still process the order without any problems. However, once you exceed $675.00, the PayPal payment will fail batch authorization and the system will not generate a pick slip or perform drop ship processing for the order. Note: The system does not allow you to increase the order total by 15% ($600.00 + 15% = $690.00) because it would exceed $75.00 of the initial authorization amount that was received from PayPal during web storefront processing.

Reversals? The system submits a reversal to PayPal if:

• The entire order is canceled or sold out, or;

• The payment method is deactivated before any transactions are billed.

The system does not submit a reversal to PayPal for a partial amount, such as when:

• A single item on a multi-line order is canceled or sold out.

• A single unit on an order line is canceled or sold out.

• Any items remaining on the order are canceled after a shipment has taken place.

Also, the reversal is not submitted if any of the order lines have been submitted to Order Orchestration for fulfillment.

For more information: See Stored Value Card Authorization Reversal.

Applying Refunds Across Multiple Capture Transaction IDs

PayPal cannot process a refund that exceeds the amount of the initial deposit. For example, if an order includes two deposits of $25.00, PayPal requires that any single refund processed not exceed $25.00.

In order to be able to reconcile refunds against the initial deposits, Order Administration stores the TRANSACTIONID provided by PayPal for each deposit as the Capture Transaction ID in the Credit Card Deposit History table for each successful deposit with PayPal, so that each refund amount applies to a deposit amount.

Example: You process an order in two shipments:

• Shipment 1: $50.00

• Shipment 2: $40.00

During deposit processing, the capture transaction ID for each shipment is stored in the Credit Card Deposit History table. This ID is not displayed on any screen.

If you then need to process one or more refunds against the order, Order Administration uses the capture transaction IDs to reconcile the refund amounts. It uses the capture transaction ID that matches the refund amount, if any; otherwise, it uses the capture transaction ID for the lowest total shipment that exceeds the refund amount. For example:

• If the refund amount is $40.00: Use the capture transaction ID for shipment 2, because the amount matches this shipment.

• If the refund amount is $50:00: Use the capture transaction ID for shipment 1, because the amount matches this shipment.

• If the refund amount is $45:00: Use the capture transaction ID for shipment 1 (because $45.00 is more than the amount for shipment 2).

• If the refund amount is $25.00: Use the capture transaction ID for shipment 1 (because $25.00 does not match the amount of either deposit).

• If the refund amount is more than $50.00: Split the refund across both capture transaction IDs.

Sometimes multiple capture transaction ID are used for a refund deposit, because no single transaction is large enough to cover the refund. In these cases, the Display Order Payment History Screen indicates the number of deposits used for the total refund amount. For example, if you process a refund totaling $60.00 for an order with the two shipments, one for $50.00 and another for $25.00, the Display Order Payment History screen indicates:

• Partial Deposit confirmed $50.00-

• Partial Deposit confirmed $10.00-

• Deposit split into 2 separate deposits.

• Deposit confirmed $60.00-

Note:

These messages are not displayed at the Payment Method Details panel in Contact Center (Modern View Order Summary), although the purchase and deposit amounts are displayed.

In this situation, there is also an Order Transaction History message written, for example: Refund for inv# 1234 exceeds PayPal limit. Note that the message may be truncated based on the size of the invoice number.

Multiple refunds? Order Administration tracks the total returned amount for PayPal payment methods in order to ensure that subsequent refunds do not result in overusing any individual deposit amounts. For example, if there was a deposit for $50.00 and a deposit of $10.00, and there is already a refund amount of $40.00 applied to the first deposit, leaving $10.00 unrefunded, a subsequent refund of $15.00 would be split across the two deposits.

If the deposit fails: When the deposit is not initially processed successfully and you use Manage Rejected Deposits in Modern View instead, no capture transaction ID is recorded, so a refund cannot be applied to the deposit.

Note:

Deposits processed before update 20.0 will not have a capture transaction ID, so the process described above does not apply to these deposits.

Processing Authorizations for a PayPal Order

The system calls authorization processing when you generate a pick slip or perform drop ship processing for an order that contains a pay type with PPL (PayPal) defined as the authorization service. During authorization processing for an order that contains a PayPal pay type, the system validates that the required authorization amount is covered by the initial authorization received for the PayPal payment during web storefront processing.

• Approved PayPal Authorizations

  • Example: Approved PayPal Authorization

  • Example: Multiple Approved PayPal Authorizations

  • Example: Approved PayPal Authorization for Amount Within Allowed 15%

  • Example: Approved PayPal Authorization and Credit Card Authorization

• Declined PayPal Authorizations

  • Example: Declined PayPal Authorization for Amount Over 15%

  • Example: Declined PayPal Authorization for Amount Over $75.00

Note:

Orders containing a PayPal payment should have received an authorization from PayPal on the web storefront before the order was received into Order Administration. The system does not send a PayPal payment to PayPal for authorization during pick slip generation or drop ship processing.

PayPal Authorization Processing

The system performs the following steps during PayPal authorization processing.

#	Step
1.	The system determines if a manual authorization exists for the PayPal payment on the order.
	If a manual authorization does not exist for the PayPal payment on the order, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs.
	If a manual authorization exists for the PayPal payment on the order, the system determines if this if the first time authorization processing was called for the PayPal payment on the order.
2.	If this is the first time authorization processing was called for the PayPal payment on the order, the system: Creates an order history record indicating the manual authorization was detected. This record indicates: The date when the order history record was created. The first 16 positions of the PayPal transaction ID. The amount that was manually authorized. This is the amount that was authorized by PayPal on the web storefront. Creates an authorization history record for the manual authorization. This record indicates: That the authorization was authorized. The first 16 positions of the PayPal transaction ID in the Authorization # field. The date the PayPal payment was authorized by PayPal on the web storefront. The date the authorization expires. The amount authorized for the PayPal payment. The amount available to apply towards other authorization requests. This amount equals the amount authorized until the system approves an authorization request.

Order history record for manual authorization: The system creates an order history record for the authorization that was received from PayPal on the web storefront. For example:

Date	Type	Transaction Note	Amount	User
7/28/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Authorization history record for manual authorization: The system creates an approved authorization history record for the authorization that was received from PayPal on the web storefront. For example:   

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	100.00

#	Step
3.	The system determines if the initial authorization has expired. The system uses the following calculation to determine the expiration date: authorization date from Authorization History table + Reauthorization days from Pay Type table = authorization expiration date For example, if the initial authorization date is 7/01/09 and the Reauthorization days is 29, the initial authorization expires on 7/29/09 (7/01/09 + 29 = 7/29/09). If the initial authorization has expired, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs.
4.	The system determines if the amount of the authorization request exceeds the manual authorization. The system allows the authorization request amount to be 15%, or up to $75.00, over the initial authorization amount. For example: If the manual authorization is for $100.00, the authorization request cannot exceed $115.00 ($100.00 + 15% = $115.00). If the manual authorization is for $600.00, the authorization request cannot exceed $675.00. The system does not allow an increase of 15% to the $600.00 authorization because 15% of $600.00 exceeds $75.00 (600.00 + 15% = 690.00). If the authorization request amount exceeds the initial authorization by 15% or $75.00, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs. Orders that Contain a Catch-All Credit Card Pay Type If the order contains a catch-all credit card pay type in addition to the PayPal pay type, instead of declining the PayPal authorization, the system adds the amount that exceeds the manual authorization to the catch-all credit card pay type on the order. In this situation, the system approves the PayPal authorization for the manual authorization amount and applies the amount not covered by the manual authorization to the catch-all credit card. For example, if the manual authorization for the PayPal pay type is $100.00 and the order total is $124.00, the system approves the PayPal authorization request for $100.00 and applies $24.00 towards the catch-all credit card on the order.
5.	If the amount of the authorization request is covered by the manual authorization or exceeds the manual authorization but is within the 15% or $75.00 allowance, the system approves the authorization. If the approved authorization amount exceeds the manual authorization, the system creates a new authorization history record for the extra amount. This record indicates: That the authorization was authorized. The first 16 positions of the PayPal transaction ID in the Authorization # field. The date the PayPal payment was authorized; this is the date the initial authorization was received from PayPal. The date the authorization expires. The extra amount authorized for the PayPal payment. See Approved PayPal Authorizations for the updates that the system performs.

Approved PayPal Authorizations

If the authorization received for the PayPal payment during web storefront processing covers the amount in the authorization request, the system:

• Generates a pick slip or performs drop ship processing for the order.

• Decreases the Amount available for the initial authorization history record by the authorization request amount. For example, if the initial authorization amount received on the web storefront is $100.00, and the authorization request amount is $28.00, the remaining amount available on the initial authorization is $72.00.

• If the authorization request amount exceeds the manual authorization received for the PayPal payment, but is within the 15% or $75.00 allowance, the system creates a new authorization history record for the extra amount.

Updated authorization history record for manual authorization:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	72.00

New authorization history record for the amount not covered by the manual authorization but within the 15% or $75.00 allowance:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00

Example: Approved PayPal Authorization

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal authorizes the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-CC_NUMBER (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $100.00. Because the unused authorization amount of $100.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

• Creates an authorization history record for the PayPal payment on the order.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	.00

Example: Multiple Approved PayPal Authorizations

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You generate a pick slip for part of the order. The authorization amount required to generate a pick slip for the order is $42.00. Because the unused authorization amount of $100.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Creates an authorization history record.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	58.00

You generate a pick slip for the remainder of the order. The authorization amount required to generate a pick slip for the order is $58.00. Because the unused authorization amount of $58.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Updates the authorization history record.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	58.00	0.00

Example: Approved PayPal Authorization for Amount Within Allowed 15%

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You maintain the order and as a result the order total increases to $110.50.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $110.50. Because the required authorization amount is within 15% of the unused authorization amount of $100.00, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/27/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Creates authorization history records:

• One authorization history record for the original authorization amount received from PayPal on the web storefront.

• One authorization history record for the amount that was over the original authorization amount, but within 15% of the original authorization amount.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	0.00
Authorized	O-AUTH_CODE	6/26/09	7/25/09	10.50	0.00

Example: Approved PayPal Authorization and Credit Card Authorization

Declined PayPal Authorizations

If the authorization received for the PayPal payment during web storefront processing does not cover the authorization request amount, the system places the order on hold and does not generate a pick slip or perform drop ship processing for the order.

The system declines the PayPal authorization for the following reasons:

• A manual authorization does not exist for the PayPal payment, or

• The initial authorization received from PayPal on the web storefront has expired, or

• The authorization request amount exceeds 15% of the initial authorization amount received from PayPal on the web storefront, or

• The authorization request amount exceeds $75.00 of the initial authorization amount received from PayPal on the web storefront.

If the authorization received for the PayPal payment during web storefront processing cannot cover the authorization request amount, or a manual authorization for the PayPal payment does not exist, the system:

• Does not generate a pick slip or perform drop ship processing for the order.

• If the authorization was declined because the initial authorization has expired, the system updates the Amount available for the initial authorization history record to zero. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09 EXPIRED	100.00	.00

• If the authorization was declined because the initial authorization amount cannot cover the authorization request amount, the system does not update the initial authorization history record. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/27/09	8/25/09	100.00	100.00

• Creates an authorization history record for the declined authorization amount. For example:

Status	Vendor Response	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Declined	PPLDECLINE		7/27/09	8/25/09	39.00	.00

• Places the order on Declined Credit Card (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code (typically PP PayPal Decline). Note:

• If the PPLDECLINE response code has not been set up for the PPL service bureau, the system places the order on AV hold.

• If the PPLDECLINE response code exists, but a hold reason is not defined for the response code, the system does not place the order on hold, but does not generate a pick slip for the order since the initial authorization for the PayPal payment is not valid.

• Creates order history records indicating the authorization was declined and the order as put on hold. For example:

Date	Type	Transaction Note	Amount	User
7/27/09	PICKGEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
7/27/09	HOLD	SYS HLD - DECLINED CREDIT CARD	39.00	USER

Correcting PayPal authorization declines: If Order Administration declines the PayPal authorization request, you will need to correct the error by either:

• Maintaining the order and reducing the order total so that it does not exceed 15% or $75.00 of the initial authorization amount received from PayPal on the web storefront.

• Calling the customer on the order to ask for an additional form of payment to cover the amount that exceeds the initial authorization amount received from PayPal on the web storefront.

• Canceling the order.

Note:

Before you run pick slip generation or perform drop ship processing for the order again, make sure to remove the order from hold.

Example: Declined PayPal Authorization for Amount Over 15%

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the current date.

You maintain the order and as a result the order total increases to $122.50.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $122.50. Because the unused authorization amount of $100.00 does not cover the amount required to generate a pick slip for the order, and the amount required exceeds 15% of the unused authorization, the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-42693038SP2401	100.00	AUTH
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	22.50	USER

Creates authorization history records for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	100.00
Declined		6/26/09	7/25/09	22.50	0.00

The system allows you to generate a pick slip for the order if:

• You maintain the order and decrease the amount so that it does not exceed 15% of the unused PayPal authorization ($115.00), or

• You maintain the order and apply the amount that exceeds 15% of the unused PayPal authorization towards another form of payment.

Example: Declined PayPal Authorization for Amount Over $75.00

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $600.00 and PayPal approves the payment for $600.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 600.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the current date.

You maintain the order and as a result the order total increases to $680.00.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $680.00. While $680.00 is within 15% of the unused PayPal authorization, it is greater than $75.00 of the unused authorization. Because the authorization amount required to generate a pick slip for the order ($680.00) is greater than $75.00 of the unused PayPal authorization ($600.00), the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-42693038SP2401	600.00	AUTH
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	80.00	USER

Creates authorization history records for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	600.00	600.00
Declined		6/26/09	7/25/09	80.00	0.00

The system allows you to generate a pick slip for the order if:

• You maintain the order and decrease the amount so that it does not exceed $75.00 of the unused PayPal authorization ($675.00), or

• You maintain the order and apply the amount that exceeds $75.00 of the unused PayPal authorization towards another form of payment.

Example: Initial PayPal Authorization Expired

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00. Due to communication problems, the web storefront cannot send the PayPal payment to PayPal for approval. The web storefront sends the order to Order Administration without a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

Order Administration receives and processes the order.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $100.00. Because a manual authorization does not exist for the PayPal payment on the order, the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	100.00	USER

Creates an authorization history record for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Declined		6/26/09	7/25/09	100.00	0.00

Processing Deposits for a PayPal Order

When you process deposits for an order that contains a pay type with PPL (PayPal) defined as the deposit service, the system sends the deposit transaction directly to PayPal via PayPal SOAP API architecture.

• PayPal Deposit Processing

  • Approved PayPal Deposits

  • Failed PayPal Deposits

• Purchase Deposit Transactions

  • PayPal DoCapture Request

  • PayPal DoCapture Response

• Return Deposit Transactions

  • PayPal RefundTransaction Request

  • PayPal RefundTransaction Response

PayPal Deposit Processing

The system performs the following steps during PayPal deposit processing.

#	Step
1.	Determines if the deposit is for a debit or credit transaction. If the deposit transaction is for a debit transaction, the system sends the PayPal DoCapture Request to PayPal. If the deposit transaction is for a credit transaction, the system sends the PayPal RefundTransaction Request to PayPal.
2.	PayPal processes the deposit and sends the response back to Order Administration. If the deposit transaction is for a debit transaction, PayPal sends the PayPal DoCapture Response to Order Administration. If the deposit transaction is for a credit transaction, PayPal sends the PayPal RefundTransaction Response to Order Administration.
3.	Order Administration receives the response and processes the deposit. See Approved PayPal Deposits and Failed PayPal Deposits.

Approved PayPal Deposits

If the deposit for the PayPal payment was approved, the system:

• For debit transactions, updates the authorization history record with the deposit amount. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Dep
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	28.00

• Creates a deposit history record for the deposit transaction.

For debit transactions:

Inv#	Type	Date	Amt	Status	Response	Action
467	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

For credit transactions:

Inv#	Type	Date	Amt	Status	Response	Action
479	*RETURN	7/30/09	20.00-	CONFIRMED	*PROCESSED	Return

• For debit transactions:

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. However, if a transaction ID is already defined in the Authentication value field, the system replaces the transaction ID only if the deposit amount for the current deposit transaction is equal to or greater than the deposit amount for the previous deposit transaction. For example, If you process two deposit transactions for a PayPal order: the first deposit for $25.00 and the second deposit for $40.00, when you process the second deposit, the system updates the transaction ID defined in the Authentication value field with the transaction ID returned for the second deposit since the second deposit amount ($40.00) is greater than the first deposit amount ($25.00).

• During deposit processing, updates the Credit Card Deposit History table with the transaction ID for each successful deposit, storing it as the capture transaction ID. The system then uses this capture transaction ID to tie refunds, if generated, to individual deposits; see Applying Refunds Across Multiple Capture Transaction IDs for more information. This ID is not displayed on any screen.

Example: Approved PayPal Deposit Across Multiple Authorizations

The PayPal payment on an order has the following authorization history records:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $112.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history records with the deposit amount of $112.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	100.00
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00	12.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	112.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

Example: Approved PayPal Deposit Across Multiple Deposits; Authentication Value Updated

The PayPal payment on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $28.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $28.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	28.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

• You submit a second debit deposit transaction for the PayPal payment for $28.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $28.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	56.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit
470	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system performs this update because the deposit amount for the current deposit transaction ($28.00) is equal to the deposit amount for the previous deposit transaction.

• You submit a third debit deposit transaction for the PayPal payment for $44.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $44.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	44.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit
470	*PURCH	7/29/09	28.00	CONFIRMED	*PROCESSED	Deposit
471	*PURCH	7/30/09	44.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system performs this update because the deposit amount for the current deposit transaction ($44.00) is greater than the deposit amount for the previous deposit transaction ($28.00).

Example: Approved PayPal Deposit Across Multiple Deposits; Authentication Value Not Updated

The PayPal payment on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $56.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $56.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	56.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
472	*PURCH	7/28/09	56.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

• You submit a second debit deposit transaction for the PayPal payment for $44.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $44.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	44.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
472	*PURCH	7/28/09	56.00	CONFIRMED	*PROCESSED	Deposit
473	*PURCH	7/28/09	44.00	CONFIRMED	*PROCESSED	Deposit

• Does not update the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system does not update this field because the deposit amount for the current deposit transaction ($44.00) is less than the deposit amount for the previous deposit transaction ($56.00).

Example: Approved PayPal Deposit and Catch-All Credit Card Deposit

The PayPal pay type on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

The catch-all credit card pay type on the order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	AUTH_#	7/28/09	8/26/09	24.00	.00	.00

You submit a debit deposit transaction for the order for $124.00. Order Administration:

• Sends the deposit transaction for the credit card to the service bureau for deposit processing.

• Sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history records with the deposit amount of $124.00.

PayPal pay type:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	124.00

Catch-all Credit Card pay type:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	AUTH_#	7/28/09	8/26/09	24.00	.00	24.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action	Ser
475	*PURCH	7/28/09	100.00	CONFIRMED	*PROCESSED	Deposit	PPL
475	*PURCH	7/28/09	24.00	CONFIRMED	100	Deposit	PMT

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

Example: Approved PayPal Credit Deposit

The PayPal payment on an order has the following authorization history records:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/30/09	8/28/09	100.00	.00	100.00
Authorized	O-AUTH_CODE	7/30/09	8/28/09	14.19	.00	14.19

A debit deposit history record exists for the order:

Inv#	Type	Date	Amt	Status	Response	Action
480	*PURCH	7/30/09	114.20	CONFIRMED	*PROCESSED	Deposit

The customer returns part of the order for a credit of $22.00.

You submit a credit deposit transaction for the PayPal payment for $22.00. Order Administration sends the deposit transaction to PayPal in the PayPal RefundTransaction Request and receives the approved response in the PayPal RefundTransaction Response.

Order Administration creates a deposit history record for the credit deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
481	*PURCH	7/30/09	22.00-	CONFIRMED	*PROCESSED	Return

Failed PayPal Deposits

The deposit transaction will be rejected if:

• Communication failures occur between Order Administration and PayPal.

• A duplicate deposit transaction already exists on the PayPal system.

• For debit deposit transactions:

  • The debit amount is greater than the associated authorization amount.

  • The transaction ID defined for the deposit does not match the associated authorization transaction.

• For credit deposit transactions:

  • The transaction ID defined for the deposit does not match the associated debit deposit transaction.

  • The credit amount is greater than the deposit amount.

For example, the PayPal payment on an order receives an authorization for $100.00.

On 6/24, the system ships part of the order for $40.00.

On 6/30, the system ships the rest of the order for $60.00.

On 7/15, the system processes a return for the order for $75.00.

Because the return amount of $75.00 is greater than each deposit amount, PayPal fails the return deposit.

Correcting failed deposits: You can use the Submit Rejected Deposits (SRDP) menu option to cancel or resend failed deposits.

See PayPal Direct Connection Integration Troubleshooting.

Purchase Deposit Transactions

Deposits for a debit (*PURCH) transaction use the PayPal DoCapture method to process the settlement. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL service bureau as the credentials used to establish a direct connection to the PayPal system during deposit processing.

PayPal DoCapture Request

Order Administration sends the purchase deposit transaction to PayPal in the PayPal DoCapture Request transaction.

Parameter	Description
METHOD	DoCapture. Transactions sent to PayPal for a purchase deposit use the PayPal DoCapture API.
AUTHORIZATION ID	The transaction ID from the Credit card # field in the Order Payment Method table.
AMT	The amount of the deposit transaction. PayPal will accept an amount that is up to 15% or $75.00 more than the original authorization amount. Note:  This amount cannot exceed $10,000.
CURRENCYCODE	The PayPal currency code, from the ASC Currency code field in the Auth Service Currency table that corresponds to the Currency in the Order Header Extended table. If the Currency in the Order Header Extended table is blank, the system uses the currency code defined in the Local Currency Code (A55) system control value to determine which ASC Currency code in the Auth Service Currency table to use. If a cross reference is not defined in Authorization Service Currency for the selected currency code, the system leaves the CURRENCYCODE in the PayPal DoCapture Request blank; PayPal treats a blank CURRENCYCODE as USD currency. See the Work with Authorization Service Currency Screen to cross-reference the Order Administration currency code to the PayPal currency code.
COMPLETETYPE	NotComplete. This value indicates that there may be additional captures.
INVNUM	The company number and invoice number. Also includes the ecommerce order number if the Append Ecommerce Order # to PayPal Invoice ID (M40) system control value is selected. The company number and invoice number include leading zeros. Example:  006-0000467-EC12345, where 006 is the company number, 0000467 is the invoice number, and EC12345 is the ecommerce order number.
NOTE	The charge description from the Charge description field in the Authorization Service table, followed by the order number. A plus sign (+) displays for each space. Example:  PAYPAL+DIRECT+COMMUNICATION+1845, where PAYPAL DIRECT COMMUNICATION is the charge description and 1845 is the order number.

PayPal DoCapture Response

Order Administration receives the purchase deposit response transaction from PayPal in the PayPal DoCapture Response transaction.

Parameter	Description
AUTHORIZATION ID	The transaction ID from the card number field in the Order Payment Method table.
TRANSACTIONID	The unique transaction ID assigned by PayPal to the deposit confirmation. Updates the Authentication value field in the Order Payment Method table. However, if a transaction ID is already defined in the Authentication value field, the system replaces the transaction ID only if the deposit amount for the current deposit transaction is equal to or greater than the deposit amount for the previous deposit transaction. Example:  If you process two deposit transactions for a PayPal order: the first deposit for $25.00 and the second deposit for $40.00, when you process the second deposit, the system updates the transaction ID defined in the Authentication value field with the transaction ID returned for the second deposit since the second deposit amount ($40.00) is greater than the first deposit amount ($25.00). Capture transaction ID: During deposit processing, the system updates the Credit Card Deposit History table with this transaction ID for each successful deposit, storing it as the capture transaction ID. The system then uses this capture transaction ID to tie refunds, if generated, to individual deposits; see Applying Refunds Across Multiple Capture Transaction IDs for more information. This ID is not displayed on any screen.
PARENT TRANSACTIONID
PAYMENTTYPE	Indicates whether the payment is instant or delayed.
ORDERTIME	The date and time when the payment was processed by PayPal. Example:  2009-07-24T17:23:15Z
AMT	The final amount charged, including any shipping and taxes from the Merchant Profile.
FEEAMT	The PayPal fee amount charged for the transaction.
SETTLEAMT	The amount deposited in the merchant’s PayPal account if there is a currency conversion.
EXCHANGERATE	The exchange rate if a currency conversion occurred.
PAYMENTSTATUS	Order Administration considers a deposit successful if the following status is received: Completed = The payment was completed, and the funds were added successfully to the merchant’s account balance. Refunded = The merchant refunded the payment. Processed = A payment was accepted. The system considers any other response a rejected deposit. Updates the Response field in the Deposit History table.

Return Deposit Transactions

Deposits for a credit (*RETURN) transaction use the PayPal RefundTransaction method to process the settlement. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL service bureau as the credentials used to establish a direct connection to the PayPal system during deposit processing.

PayPal RefundTransaction Request

Order Administration sends the return deposit request transaction to PayPal in the PayPal RefundTransaction Request transaction.

Parameter	Description
METHOD	RefundTransaction. Transactions sent to PayPal for a return deposit use the PayPal RefundTransaction API.
TRANSACTIONID	The transaction ID from the Authentication value field in the Order Payment Method table for the record associated with the first non-deactivated PayPal pay type. This ID is also stored in the Credit Card Deposit History table as the capture transaction ID. The system uses this value to match a purchase deposit to the return deposit. When a refund is applied across multiple transactions, the system uses the capture transaction IDs to reconcile the refund amounts and submits each refund amount separately based on the originating capture transaction ID. See Applying Refunds Across Multiple Capture Transaction IDs for a discussion. If a transaction ID does not exist in the Authentication value, the system sends a blank Authorization ID field to PayPal. Because PayPal cannot match a purchase deposit to the return deposit, the system places the return deposit in a failed status.
REFUNDTYPE	The type of refund to make. Set to Partial.
AMT	The amount of the deposit (refund) transaction. Return Amount PayPal does not accept returns for an amount that is greater than the original deposit amount. For example, the PayPal payment on an order receives an authorization for $100.00. On 6/24, the system ships part of the order for $40.00. On 6/30, the system ships the rest of the order for $60.00. On 7/15, the system processes a return for the order for $75.00. Because the return amount of $75.00 is greater than each deposit amount, PayPal fails the return deposit.
NOTE	The charge description from the Charge description field in the Authorization Service table, followed by the order number. A plus sign (+) displays for each space. Example:  PAYPAL+DIRECT+COMMUNICATION+1845, where PAYPAL DIRECT COMMUNICATION is the charge description and 1845 is the order number.

PayPal RefundTransaction Response

Order Administration receives the return deposit response transaction from PayPal in the PayPal RefundTransaction Response transaction.

Parameter	Description
REFUND TRANSACTIONID	The unique transaction ID assigned by PayPal to the deposit confirmation.
NETREFUNDAMT	The amount subtracted from the PayPal balance of the original recipient of payment to make this refund.
FEEREFUNDAMT	The transaction fee refunded to the original recipient of payment.
GROSSREFUND AMT	The amount of money refunded to the original payer.

PayPal Authorization Reversals

Authorization reversals use the PayPal DoVoid method to request the reversal. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL service bureau as the credentials used to establish a direct connection to the PayPal system when processing a stored value card authorization trigger record (File/Key = AHR).

Sent when? The system creates authorization reversal triggers only if the Send reversal flag is selected for PayPal in Defining Authorization Services (WASV). Also, the system sends a DoVoid request for a reversal only if:

• The entire order is canceled or sold out, or;

• The payment method is deactivated before any transactions are billed.

The system does not submit a reversal to PayPal for a partial amount, such as when:

• A single item on a multi-line order is canceled or sold out.

• A single unit on an order line is canceled or sold out.

• Any items remaining on the order are canceled after a shipment has taken place.

For more information: See:

• Stored Value Card Authorization Reversal for background.

• Working with Outbound Interface Transactions (WOIT) for information on creating and processing outbound interface triggers.

• Defining Authorization Services (WASV) for information on setting up PayPal as an authorization service.

PayPal DoVoid Transaction Request

Order Administration sends the DoVoid request to PayPal to request an authorization reversal.

The DoVoid request specifies the stored value card number for the Order Payment Method as the AUTHORIZATIONID.

PayPal DoVoid Transaction Response

The DoVoid response confirms that the DoVoid request was successful and echoes the AUTHORIZATIONID.

PayPal Direct Connection Integration Restrictions

The Order Administration PayPal Direct Connection does not support the following.

• Online or batch authorization processing in Order Administration. Web orders containing a PayPal payment must receive an approved authorization from PayPal on the web storefront before being sent to Order Administration for processing.

• Additions to orders that contain a PayPal pay type in Order Maintenance that would exceed 15% or $75.00 of the initial authorization received for the PayPal payment. For example, if the authorization received for the PayPal payment is $100.00, you can apply up to $115.00 towards the PayPal authorization ($100.00 + 15% = $115.00).

• Orders that contain multiple ship to customers.

• Gift card payments.

• Alias items.

• Promotions applied to web orders in Order Administration. Final order amounts must be passed from the web storefront.

• Authorization reversals are supported only for the full amount of the authorization when the entire order is canceled or sold out, when the payment method is deactivated.

• Exchanges and returns performed through order entry are not recommended when the pay type on the order is PayPal; however, the system does not prevent either activity.

• Exchanges are not supported if there is a charge on the exchanged item. In this scenario, you must create a separate order for the new charge with a different customer payment.

• Returns/Refunds using the PayPal payment cannot be greater than the original deposit amount.

PayPal Direct Connection Integration Troubleshooting

If you have problems connecting to PayPal during deposit processing, use the following steps to help troubleshoot the issue.

PayPal service set up correctly? Verify that you have performed the required setup for the PayPal Direct Connection integration; see PayPal Direct Connection Integration Setup.

PayPal Log

When you process deposits for an order containing a PayPal pay type, the system sends the deposit transaction directly to PayPal and logs the transactional information in the PayPal log.

Information in log: The PayPal log includes a copy of the deposit information sent between Order Administration and PayPal. In addition, any errors that may occur during deposit transaction processing are captured in the log.

You can use this log to confirm that communication between Order Administration and PayPal is working correctly, to isolate communication problems, or the recover information.

Sample log information:

Successful deposit process generates IFO level messages, such as the following:

11:56:55,831 INFO PAYPAL - [Settlement] Transmitted deposit(*PURCH) Processed : AMT=20.94&INVNUM=I23-1754&NOTE=PAYPAL+1754&AUTHORIZATIONID=AUTH_ID&COMPLETETYPE=NotComplete&METHOD=DoCapture

Failure deposit process and errors during processing generates ERROR level messages, such as the following:

11:56:55,831 ERROR PAYPAL - [Settlement] Transmitted deposit(*PURCH) Failure : AMT=20.94=123-1234=PAYPAL+1754=AUTH_ID=NotComplete=DoCapture
11:57:06,581 ERROR PAYPAL - [Settlement] Timestamp      : 2009-05-08T15:52:55Z
11:57:08,737 ERROR PAYPAL - [Settlement] CorrelationId  : CORR_ID
11:57:10,284 ERROR PAYPAL - [Settlement] Error code     : 10002
11:57:11,972 ERROR PAYPAL - [Settlement] Short message  : Security error
11:57:15,018 ERROR PAYPAL - [Settlement] Long message   : Security header is not valid
11:57:17,300 ERROR PAYPAL - [Settlement] Severity code  : Error
11:57:20,297 INFO  PAYPAL - [Settlement] Transmitted deposit(*RETURN)Failure : AMT=68.00=123-123456=PAYPALID+7042982=AUTH_ID=NotComplete=RefundTransaction

The time elapsed to receive a response is indicated in a DEBUG level message, such as the following:

12:19:13,481 DEBUG PAYPAL - message: [Settlement] Got response, elapsed time = 2 seconds

Errors reading the authorization service or authorization service extended generates ERROR level messages, such as the following:

11:31:04,471 ERROR PAYPAL - [Settlement] Defaults set. Do not process in PayPal 'live' environment

11:31:31,841 ERROR PAYPAL - [Settlement] Exception(s) encountered during Initialization. No Deposit processing performed.

PayPal Direct Connection Integration Setup

Purpose: Before you can use the PayPal - Direct Connection integration, you must perform the necessary setup.

• Creating the PayPal Decline Order Hold Reason

• Creating the PPL (PayPal) Service Bureau

• Creating a PayPal Pay Type

If you are upgrading from 5.0: In 5.0, the PayPal credentials are stored in the System Properties (PPOP) menu option. When you upgrade from version 5.0, the PayPal credentials are stored in the Work with Authentication Services (WASV) menu option in the API user name, API password, and API signature fields. You will need to redefine your PayPal credentials as part of the upgrade process.

Type of PayPal integration: The PayPal Direct Connection integration uses PayPal’s Express Checkout to send deposit transactions between PayPal and Order Administration. Communication protocol is provided through the PayPal SOAP API Architecture, which uses a signed SOAP request over HTTPS. The PayPal API jar file, provided by PayPal and included with Order Administration, handles communication between PayPal and Order Administration.

In order to use the PayPal Direct Connection integration, your web storefront must support a direct connection to PayPal to perform authorizations.

Related system control value: In addition to the setup described below, you can use the Append Ecommerce Order # to PayPal Invoice ID (M40) to define whether to include the ecommerce order number in the INVNUM set to PayPal.

Creating the PayPal Decline Order Hold Reason

Use the Establishing Order Hold Reason Codes (WOHR) menu option to create the PP (PayPal Decline) order hold reason code. The system assigns this reason to the PayPal pay type on the order when it is declined during PayPal authorization processing at pick slip generation time.

At the Create Order Hold Reason Screen, enter the following information:

Field	Description
Reason	Enter PP.
Description	Enter PAYPAL DECLINE.

Creating the PPL (PayPal) Service Bureau

Use the Defining Authorization Services (WASV) menu option to create the PPL service bureau.

Multiple PayPal accounts: If you use multiple PayPal accounts, for example, each of your entities uses an individual PayPal account, you can:

• Use the Work with Merchant ID Overrides Screen to set up overrides for the different entities in your company. In this situation, you can define unique API credentials to establish a connection to the PayPal system for each of your PayPal accounts at the Create Merchant ID by Entity Screen. You can create one PayPal pay type for all of your accounts; see Creating a PayPal Pay Type.

• Use the Work with Authorization Service Currency Screen to set up a cross-reference between the Order Administration currency code and the PayPal currency code. When sending the PayPal DoCapture Request to PayPal, the system populates the CURRENCYCODE in the request with the ASC Currency code in the Auth Service Currency table that corresponds to the Currency in the Order Header Extended table.

  • If the Currency in the Order Header Extended table is blank, the system uses the currency code defined in the Local Currency Code (A55) system control value to determine which ASC Currency code in the Auth Service Currency table to use.

  • If a cross reference is not defined in Authorization Service Currency for the selected currency code, the system leaves the CURRENCYCODE in the PayPal DoCapture Request blank; PayPal treats a blank CURRENCYCODE as USD currency.

At the First Create Authorization Services Screen, enter the following information:

Field	Description
Service code	Enter the name of the PayPal account; for example PPL.
Application	Select Auth/Deposit.
Charge description	Enter PAYPAL DIRECT CONNECTION.

At the Second Create Authorization Service Screen, enter the following information:

Field	Description
Media type	Select Communication.
Batch/Online	Select Batch.
Active production system?	Select this field to send transactions to PayPal.
Primary authorization service	Enter PPL.
Test mode?	Select this field if you are sending transactions to PayPal’s test “sandbox” environment. Deselect this field if you are sending transactions to PayPal’s production “live” environment.
	The following fields are used to establish a connection to the PayPal system when using the PayPal Direct Connection Integration. You can also define API credential information at the entity level using the Create Merchant ID by Entity Screen.
API User name	Enter the user name, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.
API Password	Enter the password, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.
API Signature	Enter the encrypted signature, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.

At the Create Vendor Response Screen, enter the following information:

Field	Description
Response code	Enter PPLDECLINE.
Description 1	Enter PAYPAL DECLINE.
Hold reason	Enter PP. If you do not enter PP as the hold reason, the system places the PayPal payment on AV hold.

Creating a PayPal Pay Type

Use the Work with Pay Types (WPAY) menu option to create the PayPal pay type, making sure to define the following information.

Field	Description
Pay category	Enter Credit Card (pay category 2).
Card type	Enter Credit (card type C).
Authorization service	Enter the name of the PayPal Direct Connection service bureau, for example, PPL.
Deposit service	Enter the name of the PayPal Direct Connection service bureau, for example, PPL.
Reauthorization days	Enter the number of days before PayPal payments expire. Make sure the number of days you enter matches the number of days defined in the PayPal system. Typically, PayPal payments are good for 29 days.
Send reversal	Select this field to enable sending reversals to PayPal when the value of the entire authorization amount is canceled or deactivated. See Stored Value Card Authorization Reversal for background.

External Payment Service

External payment service is a RESTful web service that provides an interface from Order Administration for sending stored value card transactions and receiving responses. Using this service, you can build a custom payment processor that maps to your payment provider.

This payment service needs to be configured to use the integration layer component of Order Administration, as this component controls payment service processing.

Supported stored value card transactions:

• activation request

• authorization request

• balance inquiry

• deposit request

• generation request

• recharge request

• return request

• reversal request

For more information: For background on stored value card authorization, see:

• Defining Authorization Services (WASV)

In this topic:

• External Payment Service Setup

  • Authorization Service Settings

  • Work with Pay Types (WPAY)

  • Work with Order Types (WOTY)

  • Stored Value Card Reversal Function

• Subsequent Authorization Requests through the External Payment Service

For sample messages see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

External Payment Service Setup

The required setup for the External Payment Service is described below, and includes:

• Secured Feature

• Authentication

• Authorization Service Settings

• Work with Pay Types (WPAY)

• Work with Order Types (WOTY)

Additional security requirements: For additional security-related setup requirements, including implementation of OAuth, see the External Payment Service Technical Reference Paper on My Oracle Support (2149144.1).

Secured Feature

The External Authorization Service Access (B25) secured feature controls access to the Work with External Authorization Service Screen, where you can work with required settings for the External Payment Service. These settings are described briefly below under External Service Settings

Authentication

Use OAuth to authenticate the External Payment Service. See the Oracle Retail Omnichannel Web Service Authentication Guide on My Oracle Support (2728265.1) for more information.

Authorization Service Settings

Use Defining Authorization Services (WASV) to create a service bureau for the External Payment Service.

Settings for External Payment Service: The following table lists some of the required settings, in addition to the basic settings required for all service bureaus and any optional settings, to support the External Payment Service.

Fields at the first Create/Change/Display Authorization Services screen include:	Description
Service Code	Typically set to EXT or EXC, but can be set to anything.
Application	Select Auth/Deposit.
Void auth at deposit	Select this field to void any unused portion of a credit card or stored value card authorization at deposit time. Note:  The Retain Unused Stored Value Card Authorization After Deposit (J21) system control value does not control stored value card deposit updates for the External Payment Layer.
Send reversal	Select this field to perform a credit card authorization reversal when you process a cancellation associated with a credit card payment or deactivate a credit card payment.
Fields at the second Create/Change/Display Authorization Services screen:
Media type	Select Communication.
Batch/Online	Select Online or Batch.
Immediate response	Must be selected.
Primary authorization service	Should be blank
Communication type	Payment Link must be selected, to indicate messages sent the external payment layer are processed directly.
Response check frequency	Indicates the multiple to apply to the Response time to determine how long to wait for a response after a connection when you are using the External Payment Service. For example, if the Response check frequency is 6 and the Response time is 10,000, the system waits 60,000 milliseconds (60 seconds or 1 minute) for a response after connection. Note:  If the total response interval is exceeded for an authorization record, the record goes into *RCVD status with a response type of SU, and is then removed from the Credit Card Authorization Transaction table (CCAT00).
Response time	Indicates the number of milliseconds to wait for a connection to the service bureau when you are using the External Payment Service. For example, set this field to 10,000 milliseconds to wait 10 seconds for a connection. Note: Order Management System does not wait the entire response time if it is not necessary. To avoid potential timeout issues, Oracle recommends that you set the Response Time high enough for the authorization service to prevent issues that could potentially occur if the authorization process times out while processing multiple authorizations for an order.
Country codes	If needed, define a cross reference between your country code and the country code used by the service bureau. Note:  This option also indicates whether a service bureau performs address verification processing for the country. See Defining Authorization Service Countries.
Currency codes	If needed, define a cross reference between your currency code and the currency code used by the service bureau; see Defining Authorization Service Currencies.
Merchant ID Override	If needed, define a merchant ID override for the different entities in your company; see Defining Merchant ID Overrides.
Paytype codes	If needed, define a cross reference between your pay type code and the pay type code used by the service bureau; see Defining Vendor Paytype Codes.
Response codes	Define the reasons that the service bureau approves (authorizes) or declines a transaction. The codes are assigned to each transaction by the service bureau when approving or declining the request; see Defining Vendor Response Codes. A response code of SU, indicating service unavailable, must be created. When there is a REJECT or ERROR response, the order goes on AT hold and the authorization is updated as declined when: The reason code passed is not defined as an authorization response code, or The reason code passed is defined as an authorization response code but also has a hold code defined, or No reason code is passed. If no reason code is passed, a response code of SU is applied.

External Service Settings

The additional External Service Settings at the Work with External Authorization Service Screen are accessible only to users with External Authorization Service Access (B25) authority.

All fields on the screen are required, with the exception of the External Service flag.

Tracking changes to external service settings: Changes that users make to external service settings are tracked in the User Audit table, and listed on the User Authority Change report. See Tracking User, Authority, and Password Updates for more information.

For more information: See the External Payment Layer RESTful Service technical reference on My Oracle Support for more information on updating these settings.

Setting	Notes
External Service	Select this field to have request messages generated for the External Payment Service.
External URL Prefix	The prefix that forms the beginning of the URL where messages are sent. Must begin with https. The message type defines the endpoint suffix that is appended to the prefix, creating the entire URL. For example, for a credit card authorization request, the entire URL might be https://remote.auth.com:1234/authorization, where remote.auth.com is the remote server, 1234 is the port, and authorization identifies an authorization request. The following endpoints are supported: balanceInquiry authorization reversal getToken generateGift activateGift rechargeGift deposit return
Message Version	Indicates which message version is supported with version 3.0 being the default version when creating a new authorization service. Previous versions have been removed. Version 3.0 no longer includes tags that pass the credit card number for an order and instead includes tags that pass the card token. It also allows an external merchant application to call for both Credit Cards and Stored Value Cards supported through the External Payment Service and EFTConnect.
Authentication User	The user ID for authentication of the messages to the external service.
Authentication Password	The password for authentication of the messages to the external service. Must be at least 6 positions long, include both numbers and letters, include a special character, and cannot end with a number.

Work with Pay Types (WPAY)

Use Working with Pay Types (WPAY) to assign the authorization and deposit service to each credit card or stored value card pay type that uses the External Payment Service.

Work with Order Types (WOTY)

In order to perform online authorization on web orders, the Online Authorization setting for the order type on the web order must be set to Without Window. See Establishing Order Types (WOTY) for more information on setting up an order type.

Stored Value Card Reversal Function

You can use a periodic function, described below, to submit stored value card reversal requests for closed or canceled orders.

REVXAHP (Program name = PFREVXAHP): Reverse Partial Auth for External Payment Service: Generates SVC reversal request messages for the External Payment Service within the specified company, provided that:

• A company is specified.

• The parameter specified for the function is a valid stored value card pay type code for the company.

• The pay type is assigned to an authorization service configured as the External Payment Service.

• The pay type does not match the Default Auth Code for CC Netting (M25) system control value.

For more information: See Stored Value Card Authorization Reversal for an overview of the authorization reversal process.

Subsequent Authorization Requests through the External Payment Service

About subsequent authorizations: Order Management System sends information through the External Payment Service indicating whether a transaction was initiated by the merchant, or by the customer. For example, when the customer initially places the order, this is a transaction initiated by the customer; an example of a merchant-initiated transaction is a subsequent authorization that is acquired by Order Administration when the initial authorization is expired.

Message version: Additional tags are available to support passing information identifying a subsequent authorization that was not initiated by the customer. You need to have a version 3.0 selected for the External Payment Service to use the new tags. See External Service Settings for more information.

Term definitions:

• Merchant-Initiated Transactions (MIT): An authorization that the system initiates without the customer’s active participation.

• Cardholder-Initiated Transactions (CIT): An authorization that uses payment information provided by the customer.

• Credentials on File (COF): The cardholder payment information that is stored by the system.

Types of subsequent authorizations: Brief descriptions of subsequent authorization types for credit cards include:

• Resubmission of a failed deposit: When the Supports Auth Resubmission flag is selected for the authorization service in Defining Authorization Services (WASV) and a previous deposit request for the credit card failed. A subsequent authorization and deposit request is generated, with the subsequentAuth tag set to Y and the subsequentAuthReason set to RESUBMIT. However, if the Supports Auth Resubmission flag is not selected, the subsequentAuthReason is set to REAUTH.

• Split shipment: When the order is not fulfilled in a single shipment. In this case, the request for the subsequent authorization includes a subsequentAuthReason set to REAUTH and passes the existing ci_transaction_id as the subsequentAuthTransactionID.

• Deferred or installment billing: When the order uses deferred or installment billing. The pay type’s Notify of installments setting indicates whether to send the subsequentAuthReason set to INSTALLMENT or REAUTH. See Deferred/Installment Billing Overview for background.

• Customer membership orders: When you generate orders for a customer membership that has been authorized. Authorization can take place either through the order originating the customer membership, or through a generated membership order. The CIT Transaction ID (customer-initiated transaction ID) and the original authorization amount are stored on the customer membership, although this information is not displayed on any screen. For more information, see Subsequent Authorizations through the External Payment Service for Membership Orders.

Details on the tags in the authorization request message supporting subsequent authorization requests: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).