Home
Reference
Payments subsystem
In WebSphere Commerce, payment processing uses the Payments subsystem.
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.
Early Approval payment rule
The Early Approval payment rule triggers Approve actions at both order capture and release to fulfillment, and a Deposit action at fulfillment. Deposits can take place as they occur, or they can be accumulated for deposit in a single transaction when more than one release is involved.

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.
    - No Validation or Reservation payment rule
      The No Validation or Reservation payment rule triggers a Deposit action when the order is fulfilled. No payment action is taken before the Deposit action.
    - No Validation with Approval on Reservation payment rule
      The No Validation with Approval on Reservation payment rule triggers an Approve action at release to fulfillment and a Deposit action at fulfillment. Deposits can take place as they occur, or they can be accumulated for deposit in a single transaction when more than one release is involved.
    - No Validation with Deposit at Reservation payment rule
      The No validation with Deposit at Reservation payment rule triggers Deposit actions at both release to fulfillment and fulfillment. When more than one release is involved, the amounts are deposited as they occur and are not accumulated to be deposited at once. This rule might not be considered legal in some countries or regions.
    - Early Approval payment rule
      The Early Approval payment rule triggers Approve actions at both order capture and release to fulfillment, and a Deposit action at fulfillment. Deposits can take place as they occur, or they can be accumulated for deposit in a single transaction when more than one release is involved.
    - Validation with Deposit at Reservation payment rule
      The Validation with Deposit at Reservation payment rule triggers an Approve payment action at order capture, and Deposit actions at both release to fulfillment and fulfillment. Deposits can take place as they occur, or they can be accumulated for deposit in a single transaction when more than one release is involved. This rule might not be considered legal in some countries or regions.
    - Early Deposit payment rule
      The Early deposit payment rule triggers Deposit payment actions at order capture, release to fulfillment, and fulfillment. Deposits take place as they occur. When more than one release is involved, the amounts are deposited as they occur and are not accumulated to be deposited at once. In this rule, funds are captured as quickly as possible. You might want to use this rule if you are not concerned about incurring extra transaction fees for doing early deposits. This rule is recommended if your store sells fairly expensive goods and you have a low tolerance for risk. This rule might not be considered legal in some countries or regions.
    - Credit card validation in WebSphere Commerce
      When an order is submitted, the CheckCCNumberCmd command is automatically called. This command checks information in the CCCHECK table to determine the validity of the credit card number. This table is empty by default and if no entry is found in the table, the basic credit card error checking command DoLuhnCheckCmd is started.
  - 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

Early Approval payment rule

The Early Approval payment rule triggers Approve actions at both order capture and release to fulfillment, and a Deposit action at fulfillment. Deposits can take place as they occur, or they can be accumulated for deposit in a single transaction when more than one release is involved.

Common usage: The payment method that is commonly associated with this rule is:

Credit card

Target states: This rule specifies that the following payment actions should take place for a mapped payment method:


Payment event	Target state of payment	Description
prime payment	APPROVED	The payment is approved when the order is captured.
reserve payment	APPROVED	The payment is approved when the order is released to fulfillment. Specifically, ensure the payment is in the APPROVED state. If it is, take no action. If it is not, approve it. If it is only partially approved, ensure that the difference is approved.
finalize payment	DEPOSITED	The payment is deposited when the order is fulfilled.

Example: Credit card payment with multiple releases

A customer places an order for two items that total 300 Euro: item A costs 100 EUR and is in stock. Item B costs 200 EUR and is not in stock but will be available in two days. The customer uses credit card brand X to pay for the order.


Payment event	Validation amount	Reservation amount	Finalization amount	Back-end system
Payment event	Validation amount	Reservation amount	Finalization amount	Amount approved	Amount deposited
prime payment (order capture) The initial amount is 100 EUR because only one item is available.	100	0	0	100	0
Release A
reserve payment (release to fulfillment) The total amount of this part of the order is 100 EUR.	100	100	0	100	0
finalize payment (shipping)	100	100	100	100	100
Release B
reserve payment (release to fulfillment)	0 The validation amount is zero at this stage because no validation activity is occurring.	200	0	200	0
finalize payment (shipping)	0 The validation amount is zero at this stage because no validation activity is occurring.	200	200		200