Home
Reference
Payments subsystem
In WebSphere Commerce, payment processing uses the Payments subsystem.
Payments subsystem
In WebSphere 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.

Reference
- WebSphere Commerce API reference
  WebSphere 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, EJB 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.
- API changes between WebSphere Commerce Version 7.0.0.9 and WebSphere Commerce Version 8.0.0.0
  If you are migrating version 7.0 of WebSphere Commerce, review the API changes between releases.
- WebSphere Commerce database schema
  The WebSphere Commerce database model was designed for data integrity and optimal performance. WebSphere Commerce provides several hundred tables that store WebSphere Commerce instance data. To maintain data integrity, and to ease maintenance referential integrity, constraints are widely used in the database model. Indexes are used carefully on tables to avoid over-indexing and to provide a good balance between data retrieval and data manipulation activities (insert and update). The business rules are implemented at the application level rather than by using database trigger. Triggers, however, are used to facilitate data staging and optimistic locking. A limited number of SQL-based database stored procedures are used for data intensive activities.
- Payments subsystem
  In WebSphere Commerce, payment processing uses the Payments subsystem.
  - Payments subsystem
    In WebSphere 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 the instance of a payment method with the details necessary to perform payment actions. For example, if a payment method name is Visa, then the payment instruction consists of Visa, the payment amount, cardholder's name, billing address, account number, and expiration date.
      - Payment methods
        Payment methods are the means by which payments are made. Payment methods include credit card brands, electronic checks, gift certificates, and manufacturers' coupons. The shopper selects the payment method on the Order Summary page.
      - Refund methods
        Refund methods are the means by which money is credited to customers returning merchandise. Refund method are configured in the POLICY database table by Payment policy types. For example, for a credit card payment method, the refund method is also a credit card.
      - 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
        You can use the merchant feature to manage merchant information by storing and managing the store-specific properties from the Payment perspective.
      - 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."WebSphere 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 WebSphere 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.
- 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.
- WebSphere Commerce web services
  WebSphere Commerce provides many web services.
- Utilities
  Utilities help you to accomplish administrative or configuration tasks, for example, loading data, publishing a store.
- Shopping flow URLs
  WebSphere Commerce shopping flow URLs are organized by subsystem.
- Ant targets
  A WebSphere Commerce instance can be created from the command line. The command-line utility uses Apache Ant to create the objects required. The targets are divided into several high-level groups that correspond to the environment that is to be configured.
- Glossary

Payments subsystem architecture

The Payments subsystem contains three main parts: Payment rules engine, Payment plug-in controller, and payment plug-ins.

Review the following concepts related to the Payments subsystem:

The Payments subsystem contains three main parts:

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).
Payment plug-ins: A payment plug-in is a self-contained software component that serves as a proxy for a payment back-end system.

Payment processing flow

The following diagram shows how a payment is processed by the Payments subsystem.

Image showing the Payments subsystem architecture

The shopper or CSR completes an order. When the order is submitted, the OrderProcess command runs, then invokes the PrimePayment payment task command.
The Payment rules engine determines the payment action that needs to be performed, for example, Approve.
The payment action is wrapped into an event, which is passed to the Payment plug-in controller. For example, for the approve action, the Payment plug-in controller API Approve is called.
The Payment plug-in controller determines which plug-in to use.
The payment action is invoked against the plug-in. For example, for approve action, the API approve of the corresponding plug-in is called.
The plug-in interacts with the Payment Service Provider.
The plug-in sets the transaction state according to the transaction execution results with the Payment Service Provider. This transaction state will return to the Payment plug-in controller.
The Payment plug-in controller updates the payment related records in the database according to the state of transaction execution returned by the plug-in.