5 Accounting

Payments

In Order Administration Cloud Service (OACS), payments refers to the method of payment used on an order. The payment method is the way in which funds are transferred from the buyer to the seller. The following payment options are available in OACS:

About EFTConnect: Oracle Retail EFTConnect facilitates integration with Account Providers, such as CyberSource, Adyen, and 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.

If your payment service provider would like a published offering with Order Management Suite Cloud Service leveraging the EFTConnect OPI integration, submit an enhancement request to Oracle for next steps. Otherwise, if you want to create a direct integration as part of your implementation project, refer to the External Payment Service for creating a custom integration. Use the Payment Configurations page to configure the merchants and payment methods used through integration with Oracle Retail EFTConnect.

Configuration for other payment methods: Use the Work with Authorization Services (WASV) and Working with Pay Types (WPAY) options in Classic View for all payment methods that do not process through EFTConnect, such as cash, check, PayPal, external payment service credit cards and gift cards, or Customer Engagement stored value cards. You cannot create, change, or delete an authorization service or pay type that uses EFTConnect through this option, instead, use the Payment Configurations option in Modern View to create and manage any payment processing through EFTConnect. Once the merchant account is created, configure additional settings for the EFTConnect authorization service within Work with Authorization Services such as Response Code hold reasons or country and currency mappings.

Note:

The EFTConnect Payment Form is required for adding or replacing an external service payment method through Modern View Order Entry, Order Edit, Customer Membership and Rejected Deposits.  This Payment Form will collect the required payment card data, and EFTConnect will return a Form Token to Order Administration for subsequent authorizations, deposits and refunds with the external payment service. See the EFTConnect Custom Core Implementation Reference Paper on My Oracle Support for more information on this implementation.

Cash/Check

Cash and check are forms of payment used in OACS. See Working with Pay Types (WPAY) for information on setting up the cash/check pay type.

Credit or Debit Card

Credit and debit cards are forms of payment used in OACS. In order to charge orders to a credit or debit card, you need to configure your merchant account and set up all credit card or debit card payment methods. If you are setting up credit or debit cards through EFTConnect, see the Payment Configurations page for more information. If you are setting up credit and debit cards through the External Payment Service, see Work with Authorization Services (WASV) and Working with Pay Types (WPAY).

Online Banking

Online banking is a form of payment used in OACS that draws directly from a customers’ bank account. When setting up Online Banking as a new pay type, the Advance Capture flag is automatically set to Yes.

Advance Capture for Online Banking Payments

The Advance Capture for Online Banking payment method is only available through the External Payment Service. It allows retailers to capture (or settle) payment at the time the authorization is obtained, instead of when the order is fulfilled. Online Banking payments, also known as Electronic Funds Transfer (EFT), are advance captured by an external system prior to submitting with an order, to Order Administration via the Order API. Because the payment was already captured, deposit processing will not send debit transactions to the External Payment Service payment processor; however, credit transactions will be submitted and processed as normal.

Online Banking payments are not eligible:

  • for subsequent authorizations,

  • to be associated with Deferred or Installment Billing Plans since they are prepaid,

  • to be associated with Store Pickup or Ship for Pickup orders when paid for in POS.

Submitting an order with an Online Banking Payment

Since Online Banking payments are advance captured by an external system, these payments are only supported on orders submitted thru the Order API (CWOrderIn v15.0 and above).

When submitting an order with an Online Banking payment, the following fields are required in the Payment object:

Attribute Comment

auth_amount

Must be populated with the amount that has been authorized and captured.

transaction_id

Necessary to perform a reference refund when a credit transaction is generated due to a return, discount, cancellation, etc.

payment_captured

Must be set to ‘Y’ indicating that the Online Banking payment has already been captured.

If any of these fields are missing, blank or not set properly, for a payment defined as Online Banking, the order is created in Error status. When an Online Banking payment is in error, the Online Banking payment will be automatically deactivated, and the retailer will need to determine whether a refund is required or not. To resolve the order, a new payment will be required, or the order will need to be rejected.

Note:

When an Online Banking payment is automatically deactivated due to payment error, a refund will NOT be generated. If it is deemed that a refund is required, it must be managed outside of Order Administration.

The Order API also evaluates the Online Banking balance due configuration, determining whether the order should be placed on Balance Due hold if the payments do not match the order total.

All the same payment validations that occur when submitting an order via the Order API also occur when resubmitting an order in error status and when unlocking an order.

Stored Value Card

Stored value cards are gift cards assigned a pre-paid dollar amount that you can purchase and use as a form of payment. There are two types of stored value cards available in Order Administration: physical cards you ship to the recipient card holder and virtual cards you email to the recipient card holder. See Stored Value Card Overview and Setup for additional information. See Working with Pay Types (WPAY) for information on setting up the stored value card pay type.

Stored value cards are also supported through External Payment Service and Customer Engagement. For more information on External Payment Service, see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Wallet

A wallet is a digital application used for storing electronic payment information. Digital wallets utilize security features such as encryption to protect user data to ensure secure online payments. Wallets are only available through EFTConnect payment processors and set up using the Payment Configuration screen. See the Payment Configurations page for more information. Order Administration Cloud Service only accepts payment through the Order API and not directly through Modern View Order Entry because a consumer must log into their account for approving the payment through a Wallet.

PayPal

PayPal is an online digital wallet and payment system used to pay for purchase online. It provides a secure way in which to conduct transactions by linking bank accounts, credit cards, or debit cards without sharing financial information with the recipient. See the Payment Configurations page for more information. Order Administration Cloud Service only accepts payment through the Order API and not directly through Modern View Order Entry because a consumer must log into their account for approving the payment through PayPal.

Authorizations and Authorization Reversals

Topics in this part: The following topics are described in this section:

Authorizations

An authorization occurs when a customer pays for a transaction. The payment system sends a request to the bank to verify the payment method and to hold the funds but the money does not actually move from the account.

Authorization Process

Authorizations are performed through the following actions and processes using configurations to determine the amount of the authorization. Authorizations do not apply to wallet, PayPal, or online banking since those all have to be passed through the Order API and do not support replacing the payment.

  1. Modern View Order Entry, Add Payment - $0 auth for card token, then calculated amount during submit (see below)

  2. Modern View Order Summary, Add Payment - $0 auth only for token

  3. Modern View Order Summary, Authorize Now - calculated amount (see below)

  4. CWOrderIn, online authorization for calculated amount

  5. Streamlined Pick Slip Generation (WSPS)

  6. Selecting Vendors for Drop Ship Processing(MDSP)

  7. Reprocess Drop Ship Authorizations Screen (RPDS)

  8. Reauthorizing Expired Authorizations (REAUTH) Periodic Function

  9. Reprocess Authorizations (RPAA)

  10. Performing Batch Authorization (SATH)

  11. Submit Active PO to Order Broker (ACTPO) Periodic Function

  12. Send New Orders to Order Broker (BROKER_ORD) IJCT Process

  13. Submit B/O to the Order Broker (BROKER) Periodic Function

  14. Modern View Rejected Deposits, Replace Payment - $0 auth only for token

  15. Modern View Customer Memberships, Replace Payment - $0 auth only for token

Authorization Amount for Order Entry

The authorization amount for Order Entry is calculated using the following procedure:

  1. Check On-Line Authorization (SCV B89).

    1. If set to No, send an authorization for 0.00

    2. If set to Yes, continue for next check

  2. Check the Online Authorization flag on the Establishing Order Types (WOTY).

    1. If set to Not Eligible, send an authorization for 0.00.

    2. If set to Window, send authorization request (see authorization amount calculation in step 3).

    3. If set to Without Window, send authorization request (see authorization amount calculation in step 3).

  3. If the system needs to calculate the amount of the authorization required, the following logic will be used:

    1. Check Online Auth Verification Only (SCV I96).

      1. If set to Yes, send an authorization for 0.00.

      2. If set to No, continue for next check.

    2. Check Authorize Full Amount During Order Entry (SCV G99).

      1. If set to No, continue for next check.

      2. If set to Yes, calculate the full amount of authorization needed:

        1. If this is the catch-all payment, Order Total minus amounts on the other payment methods (if any). 

        2. If this is not the catch-all payment, the Amount entered.

    3. Calculate the amount of authorization needed: 

      1. If this is the catch-all payment, Order Total of only shippable merchandise minus amounts on the other payment methods (if any). 

      2. If this is not the catch-all payment, the Amount entered for this order payment method for the shippable amount needed (should use existing logic to determine the amount). 

      3. If the amount is 0.00, send an authorization for 0.00

    4. If the calculated amount of the Credit Card authorization needed is less than 1.00 but greater than 0.00, send the authorization and do not evaluate Authorization Number for Authorizations Under $1.00 (SCV I08).

For batch processes: If the calculated amount of the authorization needed is less than 1.00 but greater than 0.00 AND Authorization Number for Authorizations Under $1.00 (SCV I08) is populated, the system will write a dummy approved authorization record with the auth number populated from the value in I08. This will be considered a valid authorization.

Authorization Amount for Order Summary, Authorize Now

The authorization amount for Order Summary, Authorize Now is calculated using the following procedure. See Add Payment and Edit Payment for information on when the Authorize Now selection is available.

  1. Assumes Use Auto Authorization Interface (SCV C14) and On-line Authorizations (SCV B89) are set to Yes and the On-Line Authorization flag on the Establishing Order Types (WOTY) is set to Window or Without Window. 

    Note:

    If C14 or B89 is set to No, Authorize Now is not available.

  2. Check Online Auth Verification Only (SCV I96).

    1. If set to No, continue for next check.

    2. If set to Yes, do not send an authorization request.

  3. Check Authorize Full Amount During Order Entry (SCV G99).

    1. If set to No, continue for next check.

    2. If set to Yes, calculate the full amount of authorization needed using existing logic:

      1. If this is the catch-all payment, Order Total minus amount on the other payment methods (if any), minus approved/valid authorizations.

      2. If this is not the catch-all payment, the Amount entered for this order payment method, minus approved/valid authorizations.

  4. Check if ALL items are on backorder:

    1. If Yes, do not send an authorization request.

    2. If No, calculate the shippable amount of authorization needed using existing logic: 

      1. If this is the catch-all payment, Order Total of only shippable merchandise minus amounts on the other payment methods (if any), minus approved/valid authorizations.

      2. If this is not the catch-all payment, the Amount entered for this order payment method for the shippable amount needed (should use existing logic to determine the amount). 

      3. If the amount is 0.00, do not send an authorization request.

Authorization Reversals

An authorization reversal is the cancellation or void of an approved credit or debit card transaction before the funds have been fully settled. It prevents the final transaction from posting and releases the temporary hold the merchant placed on the customer's funds, making the money available again in their account. As opposed to a refund, an authorization reversal occurs before a transaction is complete, while a refund is processed after the transaction is complete.

Authorization Reversal Process

The following conditions must be met before the authorization reversal procedure can be performed:

  1. The Send Reversal flag is selected on the Work with Authorization Services screen.

  2. There are no open regular, drop ship, or broker picks.

    1. If any pick is found with a status of Open (blank), Reprinted (R), Suspended (S) or Manifest Submission (M) then this order is flagged to not be reversed. 

    2. If any order_broker record has a status other then 'Y' (pending cancel), 'Z' (canceled), 'E' (error) 'U' (unfulfillable), 'C' (closed) or 'J' (rejected) then this order is flagged to not be reversed.

  3. The Pay Category is a credit card type.

  4. The order payment method authorization record must be 'O' (Authorized but not used),  'A' (Authorized) or 'V' (Voided).

  5. The order payment method must not be expired.

  6. The order total is now less than the authorization amount.

Evaluate Authorization Reversals

Evaluate Refunds/Auth Reversals is called by:

  1. Unlock Order from Modern View Order Summary and the Order Maintenance Unlock Order API.

    1. Anything that may cause the order total to go below the authorization will trigger Unlock Order.

  2. Batch jobs: SCVREV/SSVC/REVERSE (see Transmitting Activation and Reversal Transactions (SSVC).

  3. Selecting Void All/Cancel Order to void the pick slip and cancel the order at the Reprint/Void Pick Slips by Order Screen.

  4. Selecting Cancel Group to cancel a group of order lines based on the cancellation date or item in the Working with Backorders Pending Cancellation (WBPC) menu option.

  5. Processing soldout cancellations by submitting the job using the Processing Auto Soldout Cancellations (MASO) menu option or by selecting Sell Out for an order line in order maintenance.

  6. Submitting a job to cancel orders flagged for cancellation due to credit card decline using the Working with Credit Card Cancellations (WCCC) menu option.

  7. Submitting a job to cancel order lines for a given item and adding a substitute item to each order using the Processing Item Substitutions (PSUB) menu option.

  8. Canceling an order line or order on the web storefront using the Maintenance E-Commerce Process.

The Evaluate Refunds program determines refunds for cash; for credit cards it reverses extra authorizations. 

Process a Cancellation

When a cancellation is processed, an authorization reversal is triggered. Any of the following cancellation actions will trigger an authorization reversal:

Deactivate a Credit Card Payment

When a credit card payment is deactivated, an authorization reversal is triggered. The following credit card payment deactivation scenarios will trigger an authorization reversal:

  • Selecting Deactivate for the credit card payment at the Modern View Order Summary Payments screen.

  • Receiving a REJECT response from the payment processor after it was reviewed.