1. Implementation Guide
  2. Configuration and Administration
  3. Payment Configurations

Payment Configurations

Purpose: Use the Payment Configurations page to configure the merchants and payment methods used through integration with Oracle Retail EFTConnect. The Work with Authorization Service (WASV) option displays the merchant accounts that you create and work with in the Payment Configurations page.

Note:

Access to this page requires ALLOW authority to the WPMT (Payment Configurations) menu option. If you have DISPLAY authority, you cannot advance to this page.

About EFTConnect: Oracle Retail EFTConnect facilitates integration with account providers, such as CyberSource and Adyen, and other custom Oracle Payment Interface (OPI) payment services. Use of EFTConnect removes any requirement to configure each credit card payment type in Order Administration; instead, the payment processor that hosts the payment form validates the card used on an order, including the card number length, format, leading digits, or expiration date.

Configuration for other payment methods: Use the Work with Pay Type (WPAY) option in Classic View for other payment methods, such as cash, check, PayPal, external payment service gift cards, or Customer Engagement stored value cards. Payment methods that have been configured through the Payment Configurations page in Modern View are display-only in the Work with Pay Type option in Classic View.

Required settings before you begin: Before you use this page to set up a merchant account for your brand and define payment methods, the following configuration is required in Classic View:

  • Properties: Configure the following properties in Work with Admin Properties (CPRP):

    • ELO_CONFIG_URL: Used to establish a connection with EFTConnect when you use the Payment Configurations page. Contact your Oracle representative if this property is not defined, or if the Payment Configurations page in Modern View displays an error.

    • ELO_IDCS_ENDPOINT_URL: Used to request the token for OAuth authentication for the integration with EFTConnect. If this property is blank, the IDCS_SERVICE_ENDPOINT_URL is used. OAuth must also be configured for the outbound EFTConnect web service in Work with Web Service Authentication (WWSA).

      Note:

      The Client ID and Client Secret are from the EFTConnect record in Work with Web Service Authentication (WWSA). Regardless of which endpoint URL is used, the client ID and secret must be valid for the EFTConnect web service.

    • ELO_PAYMENT_URL: Defines the URL to use for any transactional communication with EFTConnect, such as obtaining a form token, authorization, or deposit. Required for use of the Payment Configurations page in Modern View.

    • ELO_THRESHOLD_TIME: Used for logging purposes. Compares the elapsed time of the web service with the ELO_THRESHOLD_TIME. If the elapsed time exceeds the threshold, a message is logged.

    • ELO_TIMEOUT: Defines the number of milliseconds to wait before requests from Order Administration to EFTConnect time out.

    • ELO_POLL_COUNT_THRESHOLD: Determines whether the transaction should be updated as unconfirmed if the threshold has been exceeded. It has a default threshold of 3, but this setting may need to be changed by the retailer. This value indicates the number of times that OACS calls EFTConnect to check if it has the status of the transaction (Capture, Refund, or Auth+Capture) from the payment provider. If the poll count is equal to or exceeds this setting, the status is changed to Unconfirmed. The deposit will need to be managed in Manage Rejected Deposits.

  • Authentication: Set up outbound authentication for EFTConnect in Work with Web Service Authentication (WWSA). OAuth is required. Note that this authentication is company-specific; for example, if you use company 1 and company 2, you need to configure authentication in both companies. The retailer needs to copy the client secret from IDCS or OCI IAM and paste it in as the Client Secret for the EFTConnect record in Work with Web Service Authentication.

  • System control values:

    • Use Auto Authorization Interface (C14) must be selected.

    • Selecting On-Line Authorizations (B89) is optional.

  • For CyberSource, the Merchant Account, Merchant Key, and Merchant Secret Key are entered into the merchant service screen after selecting CyberSource.

    Note:

    It is the responsibility of the retailer to obtain their credentials from the payment service provider.

If the page does not load successfully: Reasons why the page does not load can include:

  • If you do not have ALLOW authority to the WPMT (Payment Configurations) menu option, you cannot advance to this page.

  • If the page displays an error such as Access to Payment Configurations is not allowed. Contact your system administrator, this can indicate that one of the property settings listed above, such as the required URLs, are not set to valid URLs. The error might also include additional information, such as EFT Connect Configuration URL value is invalid or EFT Connect Payments URL value is invalid.

  • If the Auto Authorization Interface (C14) system control value is not selected, the page displays an error: Access to Payment Configurations is not allowed. Contact your system administrator.

  • If any of the required properties are not defined correctly in Work with Admin Properties:

    • EFT Connect Configuration URL value is invalid: Indicates that the ELO_CONFIG_URL is not set correctly.

    • EFT Connect Payment URL value is invalid: Indicates that the ELO_PAYMENT_URL is not set correctly.

Pending Transactions:

Use the EFTSTA periodic function (PfrEFTStatus) to request payment status updates for pending authorization void, capture and refund transactions in EFTConnect. This function checks the status in EFTConnect of each order payment transaction record that is currently in SENT status, as this status indicates that Order Administration previously received a PENDING result code from EFTConnect for the transaction. Some payment providers process some messages asynchronously (typically can be Captures, Refunds, Voids) and will return initial result as “PENDING”, and at a later point will notify EFTConnect with the final result of the transaction. This requires Order Administration to periodically request status updates for the transactions in this status. When Order Administration receives a PENDING result code in an authorization reversal (VOID) response message from EFTConnect, the IL outbound record status will be changed to P (PENDING). 

This function uses the new ELO_POLL_COUNT_THRESHOLD property in CPRP to determine whether the transaction should be updated as unconfirmed. It has a default threshold of 3, but this setting may need to be changed by the retailer. This value indicates the number of times that OMS calls EFTConnect to check if it has the status of the transaction (Capture, Refund, or Auth+Capture) from the payment provider. If the poll count is equal to or exceeds this setting, the status is changed to Unconfirmed. The deposit will need to be managed in Manage Rejected Deposits.

You should schedule this job to run at least a half hour after running deposits to allow time for processing of the requests. The exact interval to allow between running deposits and this job depends on the quantity of requests you are processing.

Fraud Processing:

When Use Fraud Checking is enabled on the Payment Configurations Merchant Account screen, the first authorization sent for each order payment method will request that the payment processor perform fraud checking. With CyberSource, fraud checking will be performed through Decision Manager. Additional configuration within Order Administration is no longer required.

When an authorization is under review, the order will be placed on a header system level hold of FS (Fraud Scoring Hold) and a pay type system level hold of PF (Payment Fraud Scoring Hold).

Note:

If the PF hold reason code is already in use, the description will be updated to Payment Fraud Scoring Hold and you should consider creating a different code for other user hold processes.

Use the EFTFRA periodic function (PfrEFTFraud) to request payment status updates for authorization transactions under REVIEW in EFTConnect.

  • If result is REVIEW, no changes will be made, and the status will be checked next time the job is run.

  • If result is REJECT, the order is canceled using the reason code in the Fraud Score Cancel Reason Code (M14) system control value.

  • If result is ACCEPT, the order and pay type holds will be released and the order can now follow normal processing.

Authorization Reversals

When Send Authorization Reversal is enabled on the Payment Configurations Merchant Account screen, the REVERSE periodic function now applies only to all open (Status is A or O) Authorization History records whose authorization service is eligible for authorization reversal.

Note:

This periodic function no longer uses Send Reversal on the Work with Pay Type (WPAY) record or a restriction of not more than 72 hours old.

This periodic function applies only to credit cards that are configured through the Payment Configurations option in Modern View. It does not apply to ORCE Stored Value Cards, External Payment Service Gift Cards or to PayPal.

EFTConnect Data Storage

Requests are sent to EFTConnect when an order purge occurs to confirm the purge of payment-related data. You can purge orders through Purge Orders (MPOR), Purge Orders by Order Number (MORP), or the PURGEOR periodic function.

New Web Service Message Versions

The following new message versions no longer include tags that pass the credit card number for an order and instead include tags that pass the card token. These changes were made because in 23.2.301.0 or higher, the message includes only an already tokenized card number.

Note:

The previous versions of these messages are no longer available. You need to use the new message versions listed below.

  • CWEmailOut: New version 13.0 no longer includes the opm_credit_card tag and includes instead the card_token tag.

  • CWInvoiceOut: New version 7.0 no longer includes the ipm_credit_card_nbr and instead includes the card_token tag.

  • CWOrderIn: New version 12.0 no longer includes the cc_number or already_tokenized tags, but instead includes the new card_token, psp_payment_scheme, and psp_customer_token tags.

  • CWOrderOut: New version 12.0 no longer includes the credit_card_nbr tag, but instead includes the new card_token tag.

Displaying Credit Card Numbers: Storing credit card numbers are no longer supported. Instead, the Credit Card Last 4 or the Card Token will be displayed on all Classic View screens or reports where previously the credit card number would have displayed. Additionally, all Classic View screen labels have been updated to say Card instead of Credit Card.

Search by Credit Card Number: The Credit card number field is no longer available at the Classic View Order Inquiry scan screen, so that you can no longer advance to the Scan by Card Last 4 screen.

How to display: Select Payment Configurations from a menu.

For more information: See Modern View help.