Payment Rules and payment plug-ins
The use of new payment sub-system offers the following advantages:
- Rules for Payment
- Payment actions are not hard-coded but are based on order life cycles and configurations. Rules for payments that you can apply to your store's business practices through configurable XML files are already provided in WebSphere Commerce. Rules for payment execute different actions at different times based on the payment methods used by your store. If the provided rules do not suit your needs, you can also configure other Payment Rules through XML files and updates to business policy tables, but the rules must be within the bounds of what the Payment Rules subcomponent supports. Payment methods can be associated with the provided Payment Rules, and the core behavior of payment actions can be configured in terms of what actions should be taken to reach target states for the payment.
- Order Functions
- Payments can be processed for multiple releases of an order. For example, when part of an order ships to one address, and the rest of the order ships to another address. Additionally, more than one payment transaction can occur in an order. For example, you can charge a credit card for the part of an order that ships immediately, and charge the remaining items a week later when the backordered items ship. Customers can also use multiple payment methods or multiple payment instructions for an order. For example, a credit card can be used to pay for part of the order and a check for the balance.
- Refunds
- Payments can be processed to issue refunds for returns on one or more orders. For example, a single refund transaction can occur for orders 1234 and 4567, rather than two transactions.
- Edits
- Information can be edited to update payment amounts and other payment information, for example, the zip code in a payment instruction or a new credit card if the original credit card was reported as stolen.
- Payment plug-ins
- If integrate a payment system into WebSphere Commerce, payment plug-ins are easier to develop and test than payment cassettes. Because it should take less time to develop a plug-in than a cassette, payment plug-ins should be significantly less expensive to implement.
- You can use the Payment Rules subcomponent to communicate with the traditional WebSphere Commerce Payments multipayment framework and cassettes through a lightweight payment plug-in for the multipayment framework. Alternatively, you can use other new lightweight payment plug-ins such as the line of credit or SimpleOffline payment plug-in, or a third-party payment plug-in. WebSphere Commerce Payments handles the execution of payments actions and communication with the payment plug-ins responsible for processing financial transactions. Because you can modify how payment actions occur using XML files (rather than have to code to interfaces), the Payment Rules subcomponent is configurable by developers. It is J2EE compliant and is built using task commands by following WebSphere Commerce programming model. Because it is J2EE compliant, it provides high-availability and cloning options not available with the WebSphere Commerce Payments component. Also, because payments plug-ins is implemented as a stateless session bean and does not rely on the use of task commands, it simplifies payment systems integration with Payment Service Provider.
- Clustering
- Unlike WebSphere Commerce Payments, Payment Rules are supported in a clustered WebSphere Commerce environment.
(C) Copyright IBM Corporation 1996, 2006. All Rights Reserved.