Home
Documentation
HCL Commerce is a high-availability, highly scalable and customizable e-commerce platform. Able to support hundreds of thousands of transactions per day, HCL Commerce allows you to do business with consumers (B2C) or directly with businesses (B2B). HCL Commerce uses cloud friendly technology to make deployment and operation both easy and efficient. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels. Business users can also use AI enabled content management capabilities.
Reference
Topics in the Reference section contain all of the HCL Commerce reference documentation.
Payments subsystem
In HCL Commerce, payment processing uses the Payments subsystem.
Payments subsystem
In HCL Commerce, payment processing uses the Payments subsystem.
Payments subsystem architecture
The Payments subsystem contains three main parts: Payment rules engine, Payment plug-in controller, and payment plug-ins.
Payment methods
Payment methods are the various financial instruments—such as credit cards, e-checks, gift certificates, and coupons—that shoppers select on the Order Summary page to finalize a purchase.

Documentation
HCL Commerce is a high-availability, highly scalable and customizable e-commerce platform. Able to support hundreds of thousands of transactions per day, HCL Commerce allows you to do business with consumers (B2C) or directly with businesses (B2B). HCL Commerce uses cloud friendly technology to make deployment and operation both easy and efficient. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels. Business users can also use AI enabled content management capabilities.
- Getting started
  HCL Commerce has different advantages for business users, administrators and developers. HCL Commerce targets each of these roles with a tailored set of offerings so that each of your users can get maximum benefit.
- Installing and deploying
  Learn how to install and deploy HCL Commerce development environments and HCL Commerce production environments.
- Migrating
  Before you migrate to HCL Commerce Version 9.1, review this information to help plan and execute your migration.
- Operating
  Topics in the Operating category highlight tasks that are typically performed by business users, customer support representatives, to complete their day-to-day tasks in the operation of the HCL Commerce site.
- Integrating
  Topics in the Integrating category highlight the tasks that are commonly performed for using HCL Commerce in combination with other products.
- Administering
  Topics in the Administering category highlight tasks that are typically performed by the Site Administrator, to support daily operations of the HCL Commerce site.
- Customizing
  The topics in the Customizing section describe tasks performed by an application developer to customize HCL Commerce.
- Tutorials
  HCL Commerce provides many tutorials to help you customize and understand your HCL Commerce instance and stores.
- Samples
  Topics in the Samples category highlight the various samples that are provided with HCL Commerce.
- Compliance
  The following section describes how you can leverage HCL Commerce features and functionality to help your site be compliant with different privacy and security standards.
- Securing
  These topics describe the security features of HCL Commerce and how to configure these features.
- Performance
  Topics in the Performance section describe the means by which to plan, implement, test, and re-visit the optimization of HCL Commerce site performance.
- Troubleshooting
  Topics in the Troubleshooting section highlight common issues that are encountered with HCL Commerce, and how they can be addressed or mitigated.
- Reference
  Topics in the Reference section contain all of the HCL Commerce reference documentation.
  - HCL Commerce API reference
    HCL Commerce exposes two main programming APIs. The first and newest API is a REST interface, and most new classes are exposed here. The legacy Java API also contains new classes not suitable for REST, and can be browsed in Javadoc format.
  - Cross-reference of data beans and tables
    Data beans are grouped into several component groups.
  - Cross-reference of commands, tasks, and tables
    URL commands, controller commands, task commands, view commands and tables are related to each other.
  - Cross reference: Commands to beans to database tables
    Use this information when you are customizing a command and you want to know which tables are affected. You should also use this topic if you are modifying a table and want to know which commands and beans are affected.
  - Run Engine commands
    The following Run Engine commands are available by default for you to configure the applications that are running inside the containers.
  - Entering Docker containers
    To enter a Docker container you can complete the following steps.
  - Docker container start up logic for HCL Commerce Version 9.1
    When you deploy a container from an HCL provided image, an Entrypoint.sh helper script determines the configurations to use while starting up the container. Review the following information to learn about what the helper script does, and how you can customize the configurations.
  - HCL Commerce database schema
    Learn how to extend and maintain the HCL Commerce database schema to ensure data integrity and performance.
  - Payments subsystem
    In HCL Commerce, payment processing uses the Payments subsystem.
    - Payments subsystem
      In HCL Commerce, payment processing uses the Payments subsystem.
      - Payments subsystem architecture
        The Payments subsystem contains three main parts: Payment rules engine, Payment plug-in controller, and payment plug-ins.
        Payment instructions
        A payment instruction is a specific instance of a payment method containing the data required to execute a transaction. While a "Payment Method" is a general category (for example, Visa), a "Payment Instruction" is the actual data record for a specific order, including the total amount, account holder's name, billing address, card number, and expiration date.
        Payment methods
        Payment methods are the various financial instruments—such as credit cards, e-checks, gift certificates, and coupons—that shoppers select on the Order Summary page to finalize a purchase.
        Refund methods
        Refund methods define the processes for crediting customers during the merchandise return process and are managed through Payment and ReturnPayment policy types.
        Payment, refund, and return payment business policies
        Payment methods and refund methods are defined in the POLICY, POLICYDESC, and POLICYCMD database tables. If the predefined payment methods and business policies do not meet your needs, you can add new ones. However, do not remove a Payment or ReturnPayment business policy; this could result in a broken payment term and condition.
        Payment actions
        A payment action moves a payment state to a target state. Payment actions are triggered by payment rules based on the payment method, payment event, and payment state.
        Payment rules engine
        The Payment rules engine determines which action to take based on the payment instruction, payment method and the payment event.
        Payment plug-in controller
        The Payment plug-in controller is a component of the Payments subsystem. It determines which plug-in to use (based on the payment method) and which plug-in API method to call (based on the action).
        Merchant feature
        Map a store to a merchant to facilitate payment operations and manage configuration properties.
        Payment events and task commands
        Payment events correspond to order life cycle phases and task commands.
        Payment configuration group
        A payment configuration group is a set of XML files that is associated with a specific payment method. For example, if your store will accept checks, cash on delivery, and two brands of credit cards, four payment configurations are required. A payment configuration group is an identifier for a group of payment configurations for different payment methods. The same payment method can have different payment configurations in different payment configurations groups identified by a different payment configuration group ID. A payment configuration ID is the mechanism by which the Payments subsystem identifies the set of configuration files to use for a given payment method. It is a string value that represents the folder or directory name where the XML configuration files are located. A payment configuration ID is used by the payment business policy in the POLICY database table. Payment business policies have the policy type "Payment."HCL Commerce provides a default configuration group for every payment method it initially supports (for example, for brands of credit cards, check, COD, Bill Me Later, and line of credit). You can use this configuration as it exists or create new ones manually. The "default" payment configuration group refers to a directory with default payment method configurations.
        Extended data in payments or credits
        Some payment plug-ins require extra protocol data or keywords to communicate with a back-end system. This extra protocol data called extended data is in addition to the standard attributes defined in the PaymentInstruction definition. Extended data is any data other than the currency, amount of the payment instruction, and the payment method name. For example, credit card number, expiration, and billing address are extended data.
        Financial transactions
        A financial transaction is either a single individual payment or a credit transaction. A payment financial transaction corresponds to a payment action in the Payment rules engine and a credit financial transaction corresponds to a refund action. Every time the Payment rules engine decides the payment or refund action that needs to be run, the corresponding financial transaction is then run in the Payments Plug-in Controller with the Payments Plug-in.
      - Payment life cycle
        There are three stages to payment processing: validation, reservation, and finalization. The payment life cycle is related to the order life cycle stages: order capture, release to fulfillment, and shipping.
      - Payment plug-ins
        A payment plug-in is a self-contained software component that serves as a proxy for a payment back-end system.
    - Extended data in payments or credits
      Some payment plug-ins require extra protocol data or keywords to communicate with a back-end system. This extra protocol data called extended data is in addition to the standard attributes defined in the PaymentInstruction definition. Extended data is any data other than the currency, amount of the payment instruction, and the payment method name. For example, credit card number, expiration, and billing address are extended data.
    - Payment rules provided in HCL Commerce
      Payment rules specify the payment actions that should occur for the payment methods a store accepts for its goods or services. Payment actions and credit actions are determined in terms of current-to-target state movements. payment rules define what target state a payment should be in by defining the actions needed to move a payment from its current state to the target state.
    - Payment configuration files
      Use these files when configuring the Payments subsystem and payment plug-ins.
    - Payment plug-in specification
      Review the following overview of the payment plug-in specification to better understand how you can use payment plug-ins.
  - Dynamic caching
    In general, caching improves response time and reduces system load. Caching techniques are used to improve the performance of World Wide Web Internet applications. Most techniques cache static content (content that rarely changes) such as graphic and text files. However, many websites serve dynamic content, containing personalized information or data that changes more frequently. Caching dynamic content requires more sophisticated caching techniques, such as those provided by the WebSphere Application Server dynamic cache, a built-in service for caching and serving dynamic content.
  - HCL Commerce store pages properties
  - Cache-entry elements
    The root element of the cachespec.xml file, <cache>, contains <cache-entry> elements. The WebSphere dynamic cache service parses the cachespec.xml file during start-up, and extracts a set of configuration parameters from each <cache-entry> element.
  - Data Load utility configuration file schema
    The Data Load utility contains several configuration files. You can use the configuration file schema to understand and customize the data load configuration files.
  - HCL Commerce web services
    HCL Commerce provides many web services.
  - Utilities
    In HCL Commerce utilities are scripts that perform operations such as loading access control policies, loading store data, and cleaning the database of obsolete objects. In runtime environments, run utilities from the Utility server Docker container. In the development environment, run utilities from the bin directory.
  - Shopping flow URLs
    HCL Commerce shopping flow URLs are organized by subsystem.
  - Messaging system URLs
    The following URLs relate to the Messaging system.
  - Scheduler URLs
    The server subsystem consists of functions that are associated with URLs that are run by the scheduler.
  - jQuery Enhancements API
    The Aurora starter store in HCL Commerce is completely written in jQuery, which is one of the most commonly used JavaScript libraries used in dynamic websites. The jQuery AJAX and events API provides an easy to use framework that meets most AJAX requirements for storefront development.
  - HCL Commerce foundation tag library
    The HCL Commerce foundation JSTL tag library is a collection of custom tags that are provided to you to support the authoring of HCL Commerce JSP files. HCL Commerce stores use the JavaServer Pages Standard Tag Library (JSTL) to perform logic, instead of Java code. At the same time, business logic is moved into data beans. The combination of these steps allows for less Java code in a JSP page.

Payment methods

Payment methods are the various financial instruments—such as credit cards, e-checks, gift certificates, and coupons—that shoppers select on the Order Summary page to finalize a purchase.

Each method is defined by specific properties, including its name, priority, editability (whether an administrator or the system can adjust the value), and transaction limits. These properties are managed via the PaymentMethodConfigurations.xml file, while the underlying payment policies are stored in the POLICY and POLICYDESC database tables.

To provide flexibility, shoppers may apply multiple payment methods to a single order. The system uses the priority setting to determine the sequence of charges; for instance, a high-priority gift certificate will be depleted before a medium-priority credit card is charged for the remaining balance.

By default, the following payment methods are available:

Credit cards

AMEX
MasterCard
VISA

BillMeLater

Offline transaction, customer is billed

Check

Electronic check or automated clearing house (ACH) transaction

COD

Cash on delivery

LOC

Line of credit

PayLater

Offline transaction. for example, the customer provides payment information later by fax.

Payment methods are associated with payment policies. For example:

db2 "select policy_id, policyname, storeent_id, properties from policy where storeent_id=10001 and policyname='VISA'"

POLICY_ID	10002
POLICYNAME	VISA
STOREENT_ID	10001
PROPERTIES	attrPageName=StandardVisa&paymentConfigurationId=default&display=true&compatibleMode=false

In B2B stores, available payment methods are defined in a contract as a payment term and condition (PaymentTC).