Payment Rules in WebSphere Commerce
Payment rules
Payment rules are the set of behaviors that define the payment actions that should occur during the processing of the orders in WebSphere Commerce. Because the rules can be configured for specific times of the order life cycle, the use of Payment Rules and payment plug-ins offers distinct advantages over the traditional use of DoPayment and other WebSphere Commerce task commands to achieve payment integration. For a review of the advantages, refer to Advantages of using Payment Rules and payment plug-ins.
The payment rules provided in WebSphere Commerce support payment actions. The action moves a payment amount to a desired target state. Examples of Payment actions are as follows:
- Payment approval (authorization)
- Deposit (payment capture, where money changes hands)
- Refund (credit)
- Reversal or cancellation (approve reversal)
Payment rules can vary by payment method and business event or phase, or store, and can trigger different types of actions based on the actual situation.
The payment rules can be viewed as templates, where the payment method and business event determine the payment action taken:
- A credit card payment method and order capture event result in an approve action.
- A credit card and fulfillment event result in a deposit action.
- An electronic check (ACH) payment method and order capture event result in a deposit action.
- An electronic check and fulfillment event result in no payment action, since a deposit already occurred.
Payment Rules can also carry restrictions. For example, they can limit edits on specific payment methods (for example, ensure that gift certificates are fully consumed rather than partially consumed so that the payment amount captured is not less than the amount of the gift certificate).
Payment Rules can also handle payment authorization reversals differently. For example, if your goods are expensive, you can reverse payment authorizations immediately when necessary so that the customer does not have an authorization for an amount which will not be used. If the items your store sells are inexpensive, you can let payment authorizations expire by themselves. Because the payment reversals will occur the same way for all types of products, independent of the amount, the system honors one configuration or the other but not both at the same time.
Payment Rules provided in WebSphere Commerce
The Payment Rules provided in WebSphere Commerce are:
- No Validation or Reservation payment rule
- No Validation with Approval on Reservation payment rule
- No Validation with Deposit at Reservation payment rule
- Early Approval payment rule
- Validation with Deposit at Reservation payment rule
- Early Deposit payment rule
A payment rule actually has two parts:
- The payment rule - the definition of the payment target states as shown in the previous list
- The payment action - the configuration of how the target states are achieved
When the system does payment processing, parameters in the payment rule are evaluated. When they are determined to be "true," a predetermined list of actions is triggered.
Although you cannot change how these rules function (Payment Rules are provided as read-only in WebSphere Commerce), you can change what payment rule should be used with a particular payment method.
Various forms of payment and refund methods are supported in WebSphere Commerce, and others can be added. Payment rules are already configured for these common forms of payment and refund methods. You can change what payment rule a payment method uses by changing the XML file containing the configuration for the payment method (the PaymentMethodConfiguration XML file). The behavior of payment processing changes when modifications to the PaymentMethodConfiguration XML file are made. When a different payment rule is specified in the PaymentMethodConfiguration XML file, the actions the system takes also change.
Note: You cannot change the Payment Rules associated with refund methods because the rules are not configurable for refund methods.
(C) Copyright IBM Corporation 1996, 2006. All Rights Reserved.