|Oracle iStore Implementation and Administration Guide|
Part Number E13575-06
This chapter covers the following topics:
This chapter contains information on how to implement payment types and shipping methods in Oracle iStore.
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:
CASH - Cash
CHECK - Check
CREDIT_CARD - Credit Card
INVOICE - Invoice
Other seeded values (not payment types, but attributes of payment types) include:
FAX_CC - Fax Credit Card
PO - Purchase Order
The seeded values for credit card payment types are:
AMEX - American Express
CARTE - Carte Blanche
DINERS - Diner's Club
DISCOVER - Discover
ENROUTE - Enroute
JCB - JCB
MASTERCARD - Master Card
VISA - Visa
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.
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.
IBE_PAYMENT_TYPE is not intended to be user extensible. Custom payment types should not be added.
Any Oracle iStore payment types defined in IBE_PAYMENT_TYPE must match those set up in the Oracle Payments (stored in the table, IBY_FNDCPT_ALL_PMT_CHANNELS_V).
Any payment method enabled/disabled in Oracle Payments must also be reflected in the Oracle iStore lookup.
For manual payment types (e.g., Cash, Check) the Oracle iStore lookup must also be in sync with the Oracle Payments lookup. An exception to this rule is the PO payment type, which is specific to Oracle iStore and hence will be present in the IBE_PAYMENT_TYPE lookup.
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.
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.
The following rules and behavior apply to this functionality:
In the (rare) case when credit card authorization (handled within iStore) is a success, but Oracle Order Management order placement fails, there won't be a re-authorization when the order is placed again for the same shopping cart.
The payment method for the shopping cart cannot be changed once the credit card associated with the shopping cart has been authorized. The cart could either be ordered or saved.
If credit card authorization happens in Oracle iStore, risk validation checks will not be performed.
The error message displayed when credit card authorization fails (based on the error code, Decline, from Oracle Payments) is: Your credit card authorization was declined. Please contact customer service. For all other error codes (for example, Communication Error, System Error, Setup Error) the following message is shown: Error while processing the credit card.
Set IBE: Perform Payment Authorization in iStore to No if you are planning to use the publish quote flow and implementing line level credit cards at the same time.
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.
This section contains business flows for payment types:
Non-Credit Card Business Flow
Credit Card Business Flow
The non-credit card business flow is:
Customer chooses a non-credit card payment type as payment method.
Checkout process is finalized and the order is placed through Oracle iStore.
Order information is passed to Oracle Order Management via Oracle Order Capture.
Oracle Order Management picks, ships, and delivers the order.
After shipment, Oracle Receivables handles payment remittance for applicable payment types.
Credit card business flow is:
Customer chooses a credit card payment type as payment method.
Checkout process is finalized, and the order is placed through Oracle iStore.
Oracle iStore passes order information to Oracle Order Management.
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.
If approved, Oracle Order Management picks, ships, and delivers the order. See the Oracle Order Management Implementation Manual for additional information.
After shipment, Oracle Receivables processes payment remittance. See Oracle Receivables documentation for more information.
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.
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.
The business process flow is as follows:
A customer logs into an Oracle iStore site, adds items to shopping cart, and proceeds to checkout to place the order.
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.
The value the user enters is passed to an Oracle Payments API, along with the card number, name, address, and relevant information.
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 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.
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.
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.
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.
Keep the following rules and guidelines in mind as you implement and use the feature:
If CVV2 is mandatory, a credit card number does not get defaulted in the checkout flow. If CVV2 is optional, per Oracle iStore defaulting rules, a credit card number is defaulted into the cart when the cart is created.
If CVV2 is mandatory, implementers should disable Express Checkout functionality, since Express Checkout places the order in one click, and the user will not be able to input the CVV2 number.
If the user inputs the CVV2 number and navigates to any other page, and then comes back to billing page, the system will show the CVV2 number as masked. The user will be able to overwrite the CVV2 number in this case.
The CVV2 number is encrypted and thus cannot be copied from one transaction to another. For this reason, when a user who has credit card information in the cart duplicates the cart or uses the Copy to Cart function from a quote, the following will happen:
If CVV2 is mandatory, then the credit card details and the CVV2 details will not be copied to the newly created cart. The payment type will be cleared as well.
If CVV2 is optional, then the credit card details will be copied to the newly created cart. The CVV2 details will not be copied to the newly created cart.
Refer to the Oracle Payments Implementation Guide for more information.
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.
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.
The business process flow is as follows:
A user adds items to a shopping cart, proceeds to checkout, and places the order.
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.
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.
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:
Step 1 - Set Profile Options
Step 2 - Set up Risk Factors
Step 3 - Set up Risk Formulas
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.
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.
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 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.
Specific behavior occurs when the profile option, ASO: Credit Card Authorization, is Yes.
ASO: Enable Risk Management on Credit Card Authorization = No.
ASO: Default Order State = Entered
IBE: Perform Payment Authorization in iStore = No
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.
ASO: Enable Risk Management on Credit Card Authorization = Yes
ASO: Default Order State = Entered
IBE: Perform Payment Authorization in iStore = No
In this case, credit card authorization will be performed with risk validation.
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.
To enable credit card authorization for orders created in Entered status, set the profile options as follows:
ASO: Credit Card Authorization = Yes
ASO: Default Order State = Entered
To enable Credit Card Authorization for orders created in Booked status, set the profile options as follows:
ASO: Credit Card Authorization = No
ASO: Default Order State profile = Booked
If credit card authorization has been implemented, credit card authorization is always run when an order is booked into Oracle Order Management. Step 1, above, provides a provision to have the credit card authorization run up front when the order is created in Entered status.
In previous releases, the profile option, ASO: Credit Card Authorization, enabled/disabled credit card authorization within Oracle Order Capture. Beginning with Oracle Applications Release 12, that is no longer the case. This profile option now only is used for the functionality described in this section.
For a brief discussion of the difference between Booked and Entered orders, see the "Orders Business Flow" section in the chapter, Implementing Carts and Orders. For additional information other than that found in this guide, see the Oracle Order Management Implementation Guide.
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:
Express Checkout Preferences
Payment and Billing Information Page during checkout
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.
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.
See the following to set up either non-credit card or credit card payment types:
"Setting up Non-Credit Card Payment Types"
"Setting up Credit Card Payment Types"
To set up non-credit card payment types in Oracle iStore:
Perform the required payment types setups listed in the Oracle Receivables User Guide.
Enable the payment types in the Site Administration Application. See the chapter, Implementing Site Management, for details.
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
To set up credit cards as payment types:
Perform the required credit card payment types setups listed in the Oracle Receivables User Guide.
Enable the credit cards as payment types in the Site Administration Application. See the chapter, Implementing Site Management, for details.
Set the profile option, ASO: Credit Card Authorization, to Yes. See the appendix, Profile Options, for more information on the profile option.
This section discusses Oracle iStore's Payment Types Threshold feature.
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:
In a multiple-site deployment, some sites can have the Payment Threshold feature enabled, while other sites do not.
Payment Threshold can be enabled for each installed currency.
For purchases below the payment threshold, customers will only see appropriate payment types for which their order qualifies.
You can exclude a B2B customer, or group of B2B customers, from the threshold restriction, by assigning a user the permission, IBE_IGNORE_THRESHOLD. For more information on user permissions in Oracle iStore, see the appendix, Seeded User Data.
From a technical standpoint, Payment Types Threshold affects three tables in the database. The following table shows the data.
|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.|
To enable a Payment Threshold, follow the step below:
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:
Log into the Site Administration Application and update a site.
In the Update Site page, ensure that the Enable Threshold for Payment Types checkbox is active.
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).
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.
Save your changes.
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.
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 Commitments -- See the "Define Commitment" section
Enable Commitments -- See the "Enable Commitment" section.
Commitments are defined with deposits or guarantees. See the Oracle Receivables User's Guide for information on how to set up commitments.
To enable commitments:
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.
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.
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.
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.
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:
Log into Oracle Forms as a user with access to the Freight Carriers menus.
Navigate to Setup, then Freight Carriers; query the applicable freight carrier.
Under the Services tab, select the Organization Assignments button.
Activate the Assigned checkbox for the item validation (inventory) organization that is specified for the appropriate customer responsibility.
Repeat for each freight carrier.
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.
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:
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.
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.
Flagged as Web Enabled. See the section, "Setting up Web-Enabled Shipping Methods", within this chapter, for details.
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.
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.
Copyright © 2001, 2010, Oracle and/or its affiliates. All rights reserved.