Skip Headers

Oracle iStore Implementation and Administration Guide
Release 12.1
Part Number E13575-06
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Implementing Payment Types and Shipping Methods

This chapter covers the following topics:

Overview of Implementing Payment Types and Shipping Methods Chapter

This chapter contains information on how to implement payment types and shipping methods in Oracle iStore.

Oracle iStore Payment Types Overview

Oracle iStore allows you to configure several payment types for your sites. Each site can use different payment types. After being enabled in Oracle Payments and Oracle iStore, site administrators select the desired payment type for each site in the Oracle iStore Site Administration Application. Following are the seeded payment types:

Other seeded values (not payment types, but attributes of payment types) include:

The seeded values for credit card payment types are:

Note: Any payment method (channel) enabled on an Oracle iStore site must also be enabled as a payment channel within Oracle Order Management, for the operating unit against which the order will eventually be placed.

The Oracle Payments Role in Payment Methods

Oracle Payments (previously Oracle iPayments) centralizes the storage of payment information, including payment methods (e.g., credit cards, checks, etc.) and payment instruments (e.g., credit card numbers). Since Oracle iStore supports a few methods (PO*, Invoice and Fax_CC) that are outside the purview of Oracle Payments, the payment types used in Oracle iStore cannot be based solely on an Oracle Payments table/lookup. Thus, Oracle iStore uses its own lookup, IBE_PAYMENT_TYPE, to store the additional payment types that are unique to Oracle iStore but not present in Oracle Payments, and the payment types implementers wish to use in the sites. Implementers must follow these rules when setting up payment types:

*PO is not an actual payment method, but rather an attribute of the payment.

Note: At the end of the installation patching process, Oracle Payments automatically runs an Oracle iStore concurrent program, iStore Program to Migrate Credit Card Data to Oracle Payments. This concurrent program migrates the iStore data for primary and preferred credit card to the Oracle Payments model.

See the Oracle Payments Implementation Guide for additional information. Information on selecting payment types for sites can be found in the chapter, Implementing Site Management.

Credit Card Processing

Oracle Order Management, Oracle Payments, Oracle Receivables, and Oracle iStore work together to enable credit card processing. When a customer attempts to use a credit card in Oracle iStore, the system checks the value of the profile option, IBE: Perform Payment Authorization in iStore. When the profile is set to Yes, Oracle iStore calls an Oracle Payments API to authorize the credit card before creating the order.

If credit card authorization fails, Oracle iStore displays an error message and the order won’t be created. If the authorization is successful, an order will be created.

If the profile is set to No, payment authorization is not done through Oracle iStore; rather, credit card authorization is performed in Oracle Order Management.

See the appendix, Profile Options, for more information on the profile option.

Credit Card Processing Rules and Behavior

The following rules and behavior apply to this functionality:

See the Credit Card Risk Management Support topic, below, for information about a special scenario with the profile option, ASO: Credit Card Authorization, and risk management.

Payment Types Business Flows

This section contains business flows for payment types:

Non-Credit Card Business Flow

The non-credit card business flow is:

  1. Customer chooses a non-credit card payment type as payment method.

  2. Checkout process is finalized and the order is placed through Oracle iStore.

  3. Order information is passed to Oracle Order Management via Oracle Order Capture.

  4. Oracle Order Management picks, ships, and delivers the order.

  5. After shipment, Oracle Receivables handles payment remittance for applicable payment types.

Credit Card Business Flow

Credit card business flow is:

  1. Customer chooses a credit card payment type as payment method.

  2. Checkout process is finalized, and the order is placed through Oracle iStore.

  3. Oracle iStore passes order information to Oracle Order Management.

  4. Oracle Order Management can interface with Oracle Payments or other applications for credit card processing.

    Oracle Payments integrates with third-party payment providers to authorize the credit card, and passes transaction results back to Oracle Order Management. See the Oracle Payments Implementation Guide for additional information.

  5. If approved, Oracle Order Management picks, ships, and delivers the order. See the Oracle Order Management Implementation Manual for additional information.

  6. After shipment, Oracle Receivables processes payment remittance. See Oracle Receivables documentation for more information.

Credit Card Verification Number Support

In today’s e-commerce environment, companies are increasingly seeking ways to reduce credit card fraud and ensure secure online ordering for their customers. To address this need, Oracle iStore features close integration with Oracle Payments to provide merchants with the ability to require that their customers enter a Card Verification Value 2 (CVV2) during checkout.

Overview of CVV2

CVV2 is a 3- or 4-digit number printed on the back of credit cards. Requiring that customers enter this number during checkout helps ensure that the credit card is on hand during the order placement process.

CVV2 Process Flow

The business process flow is as follows:

  1. A customer logs into an Oracle iStore site, adds items to shopping cart, and proceeds to checkout to place the order.

  2. In the Payment and Billing Information page, the user enters the CVV2 number in the CVV2 field, located next to the credit card selection field.

  3. The value the user enters is passed to an Oracle Payments API, along with the card number, name, address, and relevant information.

  4. If the user inputs an invalid CVV2 number, the transaction fails and an error message displays in the Review and Submit Order page.

The following graphic shows how the CVV2 field might appear in the Payment and Billing Information page in an implementation of Oracle iStore.

CVV2 Field in Payment and Billing Information Page

the picture is described in the document text

Implementing CVV2

The CVV2 feature is implemented using Oracle Payments, a mandatory dependency for this feature. Implementers can set the field to be mandatory or optional. If CVV2 is mandatory, the Oracle iStore Customer Application displays an asterisk (*) next to CVV2 number field. Use the following steps to set up CVV2.

  1. Ensure that credit card authorization is set up. See the Oracle Payments Implementation Guide and the "Credit Card Processing" and the "Credit Card Business Flow" sections within this chapter.

  2. To implement CVV2 as mandatory: In the Oracle Payments Setup, System Security Options page, in the Credit Card Owner Verification Control area, set the Require Security Code Entry to Yes.

  3. To implement CVV2 as optional: Set the Require Security Code Entry in Payments to No.

Note: The CVV2 text field will always display in the Customer Application billing section, regardless of whether it is marked as optional or mandatory in Oracle Payments.

Rules and Guidelines for CVV2

Keep the following rules and guidelines in mind as you implement and use the feature:

Refer to the Oracle Payments Implementation Guide for more information.

Credit Card Risk Management Support

With increasing numbers of credit card transactions online, merchants need a way to detect fraudulent transactions. Oracle iStore meets this need with its integration to the Oracle Payments Risk Management functionality.

Overview of Risk Management

Risk Management functionality allows businesses to have any number of predefined risk factors to verify the identity of their customers and assess their customer credit and risk ratings in a secure environment during real-time credit card authorization. Authorization returns an authorization code, and if Risk Management is enabled, a risk score. Risk scores range from zero to 100, with zero meaning a risk-free transaction and 100 meaning a high-risk authorization. If the risk score exceeds the risk threshold merchants have set up, the order is automatically placed on credit card high risk hold.

Risk Management Process Flow

The business process flow is as follows:

  1. A user adds items to a shopping cart, proceeds to checkout, and places the order.

  2. As part of credit card payment authorization, an Oracle Payments API is called to authorize the payment. At this time, Oracle Payments checks if risk management is enabled and evaluates the risk formula associated with the payee (customer). If the credit card authorization fails, the order will not be placed, and the user is shown an error message -- if the credit card authorization is done by Oracle iStore. If the credit card authorization is done by Oracle Order Management and the authorization fails, then the order will be created and put on "payment hold". A message saying that the order has been put on hold will be displayed.

  3. If the authorization succeeds, Oracle Payments returns the risk score obtained after evaluation, taking into account the threshold value implemented by the merchant. If the risk score is more than the threshold value, the payment request is deemed too risky, and the order is put on "payment hold". A message saying that the order has been put on hold will be displayed.

Implementing Risk Management

Risk Management functionality requires integration with Oracle Payments. Assuming Oracle Payments is implemented along with Oracle iStore, following is the high level process flow for implementing risk management:

  1. Step 1 - Set Profile Options

  2. Step 2 - Set up Risk Factors

  3. Step 3 - Set up Risk Formulas

Step 1 - Set Profile Options

Set the profile option, ASO: Enable Risk Management on Credit Card Authorization, to Yes to enable the feature in Oracle iStore. See the appendix, Profile Options, for more information on the settings of the profile option.

In addition, if business requirements dictate, set ASO: Credit Card Authorization to Yes and IBE: Perform Payment Authorization in iStore to No. Refer to the section, "Behavior Involving ASO: Credit Card Authorization Profile", below.

Step 2 - Set up Risk Factors

Set up risk factors (e.g., time of purchase, transaction amount, ship-to/bill-to address, payment history) in Oracle Payments. See the Oracle Payments Implementation Guide for more information.

Step 3 - Set up Risk Formulas

Set up risk formulas based on above defined risk factors and a threshold value for the formula in the Oracle Payments Payee screen. The risk score is a value between 1 and 100, and represents the cutoff point, where the orders that get authorized with a higher risk factor will be placed on credit card high risk hold. The default is 50. For example, assume an order authorizes successfully, but returns a risk factor of 51. Since its risk code is above the threshold of 50, it will be placed on hold. See the Oracle Payments Implementation Guide for more information.

Express Checkout Integration

Express checkout orders also do the risk management checks, and if the risk score is more than the threshold, the order will be put on hold. In case of express checkout orders, profile options values used are for the iStore concurrent programs administrator. Hence, implementers should set the risk management profile values accordingly for the iStore concurrent programs administrator.

Refer to the Oracle Order Management Implementation Manual and the Oracle Payments Implementation Guide for more information.

Behavior Involving ASO: Credit Card Authorization Profile

Specific behavior occurs when the profile option, ASO: Credit Card Authorization, is Yes.

Scenario 1

When the above conditions are set, an order will be created in entered mode and authorization is performed at order creation time without risk validation.

Scenario 2

In this case, credit card authorization will be performed with risk validation.

Credit Card Authorization for Entered or Booked Orders

By setting two profile options, merchants can configure Oracle iStore’s integration with Oracle Payments and Oracle Order Capture to specify whether credit card authorization occurs during the order state of Entered or Booked. These are discussed below.

  1. To enable credit card authorization for orders created in Entered status, set the profile options as follows:

  2. To enable Credit Card Authorization for orders created in Booked status, set the profile options as follows:

Guidelines

Statement Billing Address for Credit Cards

Merchants have the option to specify (through a setup in Oracle Payments) whether the statement billing address is required information to store a credit card number to use during checkout. As an aspect of fraud prevention, statement billing address information is used for the credit card payment verification service, Address Verification Service (AVS); this service verifies that the credit card is valid and that the address information matches the data that the credit card issuer has on file for the card (the billing address of the card). When implementers mark a credit card statement address as mandatory in Oracle Payments, Oracle iStore also marks this as mandatory information customers must select as part of credit card data in the following areas:

If credit card statement address is not mandatory in Oracle Payments, Oracle iStore does not expose credit card billing statement address anywhere in the Customer Application.

Note: This functionality applies only to newly created credit card data, or to updated credit card data. Data from previously entered credit cards will not be affected, unless the customer attempts to update an existing credit card; in this case, if the billing statement address is mandatory, during update the customer will be required to select the statement address.

Implementing Mandatory Credit Card Statement Address

This functionality requires integration with Oracle Payments. To implement the mandatory credit card statement address, in the Oracle Payments System Security Options page, set the Require Statement Billing Address Entry field to Yes and save changes. There are no setups required within Oracle iStore. See the Oracle Payments Implementation Guide for more information on the setup.

Setting up Payment Types

See the following to set up either non-credit card or credit card payment types:

Setting up Non-Credit Card Payment Types

To set up non-credit card payment types in Oracle iStore:

  1. Perform the required payment types setups listed in the Oracle Receivables User Guide.

  2. Enable the payment types in the Site Administration Application. See the chapter, Implementing Site Management, for details.

  3. If enabling Purchase Order, for each applicable site, activate the Ask for Purchase Order checkbox in the Update Site: Payments page. This will allow the appearance of the Purchase Order textbox in the Customer UI's Payment and Billing Information page.

Note: Purchase order functionality cannot be used with item-level billing. See the section, "Setting up Item-Level Billing", within this chapter, for more information.

The following figure shows how the Purchase Order textbox might display in an Oracle iStore implementation.

Example Purchase Order Number Textbox

the picture is described in the document text

Setting up Credit Card Payment Types

To set up credit cards as payment types:

  1. Perform the required credit card payment types setups listed in the Oracle Receivables User Guide.

  2. Enable the credit cards as payment types in the Site Administration Application. See the chapter, Implementing Site Management, for details.

  3. Set the profile option, ASO: Credit Card Authorization, to Yes. See the appendix, Profile Options, for more information on the profile option.

Using Payment Types Threshold

This section discusses Oracle iStore's Payment Types Threshold feature.

Payment Types Threshold Overview

Mandating the use of credit cards for purchases less than a designated amount can provide a significant benefit in some situations. For many corporations, transactions below a certain threshold amount are written off as bad debt. Tracking and collecting payments for a small amount often isn't worth the collection effort. Therefore, many businesses are moving toward mandating specific payment types for purchases that fall under a certain payment amount. To accommodate this business requirement, Oracle iStore has the Payment Types Threshold feature that enables the merchant to limit payment methods when customers make low dollar amount transactions.

From a functional perspective, the Oracle iStore payment detail page displays the appropriate payment types assigned to the payment method threshold. For example, if it is designated that all orders under $2000 must be paid with a credit card, when the customer proceeds to checkout, Credit Card is the only payment method available to him.

This feature has the following functionality:

Tables Involved in Payment Types Threshold

From a technical standpoint, Payment Types Threshold affects three tables in the database. The following table shows the data.

Payment Method Threshold - Database Tables
Table Name Field Name Affecting Threshold Comments
IBE_MSITES_B PAYMENT_THRESHOLD_ENABLE_FLAG Indicates if the payment threshold is enabled or not. "Y" is if it is enabled.
IBE_MSITE_CURRENCIES PAYMENT_THRESHOLD Holds the payment threshold value for the currency.
IBE_MSITE_INFORMATION MSITE_INFORMATION2 Used to save the flag which indicates if this payment type can be used below the payment threshold. "Y" indicates that it can be used below the threshold.

Implementing Payment Types Threshold

To enable a Payment Threshold, follow the step below:

Prerequisite

When Express Checkout is enabled, the only payment type available to a customer using Express Checkout is credit card. Therefore, if you have set up a site to mandate that credit cards are not a valid payment type for purchases below the threshold amount, you should disable Express Checkout. Remember, B2B users assigned the permission, IBE_IGNORE_THRESHOLD, will not be affected by the threshold. See the "Express Checkout" section in the chapter, Implementing Carts and Orders, for more information on Express Checkout.

Here are the high-level steps:

  1. Log into the Site Administration Application and update a site.

  2. In the Update Site page, ensure that the Enable Threshold for Payment Types checkbox is active.

  3. Navigate to the Pricing page by selecting the Pricing hyperlink. For each supported currency, enter a monetary amount, in whole numbers, in the Payment Threshold textbox. When a user attempts to place an order whose amount is below this amount, Oracle iStore will display only the payment types whose Payment Threshold checkbox is active (see the next step, below).

  4. Navigate to the Payment Types page by selecting the Payment hyperlink: In the Update Site page, select the Payment hyperlink. The Payment Types page will display all payment types currently supported by the site. To enable the payment threshold functionality for a payment type, select the Use Below Payment Threshold checkbox next to the payment type in the table.

  5. Save your changes.

Setting up Item-Level Billing

B2B customers can select bill-to contacts and addresses at item level during checkout.

Note: Item-level billing is supported only with the payment types, Cash and Invoice. These two types are supported only when a purchase order is not specified. An error will occur if users attempt to use purchase orders with item-level billing.

Enable item-level billing by setting the profile option, ASO: Enable Line Level Billing, to Yes. See the appendix, Profile Options, for more information on the profile.

Setting up Payment Commitments

A commitment is a contractual guarantee with a customer for future purchases, usually with deposits or prepayments. In Oracle iStore, B2B users select commitments during checkout. A merchant then creates invoices against the commitment to absorb the deposit or prepayment. Customers can use commitments at item level, with any cart-level payment method.

To set up Payment Commitments:

Define Commitment

Commitments are defined with deposits or guarantees. See the Oracle Receivables User's Guide for information on how to set up commitments.

Enable Commitment

To enable commitments:

  1. Set the following profile option at the application level for Oracle iStore: IBE: Use Commitments. Set to Yes. If set to No, commitments are not available. The profile option defaults to No if not set.

  2. Set the profile Sequential Numbering to Not Used at the Oracle iStore application level. If you are using Sequential Numbering with Oracle Receivables and still want to use commitments, you can keep the Sequential Numbering turned on at the site level and still enable commitments at the application level.

Setting up Shipping Functionality

Shipping methods, also known as freight carriers, are defined in Oracle Forms, using any responsibility that contains the Shipping setup menus -- these responsibilities may include Inventory, Order Management Super User, or Purchasing.

Setting up Web-Enabled Shipping Methods

After you have set up the shipping method lookups, you must flag them as web-enabled to use them in Oracle iStore's Customer Application.

Note: All shipping methods set up in Oracle Forms will display in the Site Administration Application. But only those shipping methods set as Web Enabled and assigned to the correct item validation (inventory) organization for the user's operating unit will be available to customers in the Customer Application.

To set up shipping methods as web-enabled, log into Oracle Order Management, and, in the Carriers form, select Web Enable for each carrier you have set up. See the Oracle Order Management Implementation Manual for more information.

Assigning Freight Carriers to Default Inventory Organization

In addition to setting up shipping methods as Web Enabled, freight carriers (shipping methods) must be enabled for the item validation (inventory) organization that is tied to the operating unit linked to the customer responsibility being used in the Customer Application. The customer's operating unit is defined in the MO: Operating Unit profile option, set at responsibility level.

You may use the following steps:

Steps

  1. Log into Oracle Forms as a user with access to the Freight Carriers menus.

  2. Navigate to Setup, then Freight Carriers; query the applicable freight carrier.

  3. Under the Services tab, select the Organization Assignments button.

  4. Activate the Assigned checkbox for the item validation (inventory) organization that is specified for the appropriate customer responsibility.

  5. Repeat for each freight carrier.

  6. Save your changes.

Note: To quickly find the correct inventory organization per operating unit, log into Oracle Forms as Order Management Super User and navigate to the Setup, Parameters. The organization shown in the first field of the Parameters form is the correct item validation (inventory) organization to which you should assign the shipping methods.

Setting up Shipping by Site

You must specify the available shipping methods for each site. All shipping method lookups display to the site manager in the iStore Administration Application. However, at checkout, the Customer Application only allows customers to choose shipping methods that are:

  1. Enabled for the site in which the user is shopping. See the chapter, Implementing Site Management, for directions on how to select shipping methods for a site.

  2. Enabled for the Inventory Organization that is the item validation organization of the user's operating unit. See the section, "Assigning Freight Carriers to Default Inventory Organization", within this chapter, for details.

  3. Flagged as Web Enabled. See the section, "Setting up Web-Enabled Shipping Methods", within this chapter, for details.

Allowing Item Level Shipping

You can allow users to enter different shipping addresses at the item level by setting the profile option, IBE: Use Line Level Shipping, to Yes. See the appendix, Profile Options, for more information on the profile option.

Note that promotional goods, service items, and configurable items cannot be split with item-level shipping.

Allowing Users to Enter Shipping Information

You can allow customers to enter shipping information during checkout, by setting the profile option, IBE: Use Shipping Instructions, to Yes. See the appendix, Profile Options, for more information on the profile option.