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.
Payment events and task commands
Payment events correspond to order life cycle phases and task commands.

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

Payment events and task commands

Payment events correspond to order life cycle phases and task commands.

The following table shows the main order life cycle phases and the corresponding payment events and task commands.

Order life cycle phase	Payment event	Task command
Order Capture	Prime Payment	PrimePaymentCmd
Release to Fulfillment	Reserve Payment	ReservePaymentCmd
Shipment Confirmation	Finalize Payment	FinalizePaymentCmd

The payment actions that are run during the processing of each task command vary according to the payment methods involved and their matching Payment rules. For example, the payment actions defined for a credit card during order capture will probably be different from the payment actions defined for an electronic check during the same order capture event. Also, all stores do not process payments the same way. Some stores might not accept a particular brand of credit card, for example.

Task command	Description
StoreAndValidatePaymentCmd	Pre-order authorization (store payment information and validate it). By default, this task command creates am order (EDPOrder) when there is no payment related operation.
TriggerPaymentActionsCmd	Triggering actions.
CancelOrderCmd	Order cancellation.
EditCmd	Edits (changes to payment amounts or payment methods, or late edits) EditCmd happens in two ways: by adding, removing, or updating payment information, and by the TriggerPaymentActionsCmd.
FinalizeRefundCmd	Credit return merchandise authorization (RMA).
FinalizePaymentCmd	Fulfillment (goods have shipped and shipment is confirmed).
PrimeRefundCmd	Return merchandise authorization (RMA) capture.
PrimePaymentCmd	Order capture (when the Buy button is clicked).
ReservePaymentCmd	Release to fulfillment (goods are ready to ship).