Home
Reference
Payments subsystem
In WebSphere Commerce, payment processing uses the Payments subsystem.
Payment plug-in specification
Review the following overview of the payment plug-in specification to better understand how you can use payment plug-ins.
Enabling dependent credit support
You must perform the following procedure to enable support for dependent credit transactions.
Dependent credit
WebSphere Commerce 6.0.0.3 introduced payment rules and policies to support dependent credit.

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.
  - 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.
    - Payment plug-in containers class diagram
      The Payment plug-in containers class diagram shows the relationships between the following objects: PaymentInstruction, Payment, Credit, FinancialTransaction and ExtendedData.
    - Payment state machine
      The following diagram shows the state machine for a Payment as used by the Payment plug-in controller. It describes how a Payment moves from state to state when financial transactions, queries, or external edits are made against a payment and payment plug-ins are used to process payment transactions. The payment state is persisted in the PPCPAYMENT table.
    - Credit state machine
      The following diagram shows the state machine for a Credit as used by Payment plug-in controller. It describes how a credit moves from state to state when financial transactions, queries, or external edits are made against a payment and payment plug-ins are used to process payment transactions. The credit state is persisted in the PPCCREDIT table.
    - Financial transaction execution flow
      The Financial transaction execution flow illustrates how a financial transaction occurs, and how WebSphere Commerce interacts with the payment plug-in.
    - Plug-in deployment descriptor XSD
      An example of the XML schema document for a plug-in deployment descriptor.
    - Enabling dependent credit support
      You must perform the following procedure to enable support for dependent credit transactions.
      - Dependent credit
        WebSphere Commerce 6.0.0.3 introduced payment rules and policies to support dependent credit.
      - Configuring synchronized payment reversals
        You can configure the payments subsystem to support payment captures that are associated with shipments. This helps avoid payment problems with orders for which there are multiple shipments and multiple payment transactions.
    - Processing multiple shipments with a single approval
      You can process multiple shipments at a time with a single authorization approval by customizing the PaymentEventListenerImpl class. Without customization, the PaymentEventListenerImpl class uses the default payment rules and processes multiple transactions for multiple shipments.
    - LOC plug-in financial transactions
      Payment plug-ins can perform payment actions differently. The following table describes how the LOC plug-in performs financial transactions (payment actions). This information might be useful to plug-in writers who are modeling plug-ins after the LOC plug-in. In summary, the payment actions performed by the LOC plug-in involve checking the presence of data in the payment instruction.
    - SimpleOffline plug-in financial transactions
      The SimpleOffline plug-in performs several financial transactions (payment actions). Plug-in writers who are modeling plug-ins after the SimpleOffline plug-in could model the financial transactions in a similar way.
    - SimpleOfflinePlugin.xml
      This file contains a list of the unique parameters required for each payment method supported by the plug-in.
- 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

Dependent credit

WebSphere Commerce 6.0.0.3 introduced payment rules and policies to support dependent credit.

Dependent credits are transactions associated with a PaymentInstruction where deposits have already taken place. For example, after a deposit of $100 U.S. dollars, a credit up to $100.00 would be considered a dependent credit.

To support dependent credit implementations, there is a new implementation class RefundWithDependentSupportPolicyCmdImpl of the RefundByMethodPolicyCmd policy command registered for this policy. This policy command generates the value objects of refund instructions for the current RMA (Return Merchandise Authorization).

There is a new optional attribute in the PaymentMethodConfigurations.xml file for each payment method configuration: dependentCreditRequired. If it is not configured in this XML file, the default value of dependentCreditRequired is false. When dependentCreditRequired is set to true, credit transactions against this payment method are required to be dependent credits. When dependentCreditRequired is set to false, credit transactions against this payment method are not required to be dependent credits. That is, independent credit is supported by this payment method.

Primarily, this implementation class performs the following actions:

Applies the refund amount specified in the current RMA to those payment methods for which RefundAllowed=true.
1. For those payment methods where dependentCreditRequired=true, a dependent refund instruction is created. For each dependent refund instruction value object, a new attribute linkedPaymentInstruction is introduced which associates the refund instruction with the original payment instruction.
2. For those payment methods where dependentCreditRequired=false, or is not configured, an independent refund instruction is created.
If the refund amount cannot be totally applied to those qualified payment methods, an exception is thrown to report this error situation.