If you choose to enable a store for advanced order processing, you can take advantage of event-driven payment processing. If a store is enabled for standard order processing, you cannot access the benefits of event-driven payments. The advantages of using event-driven payment processing are:
- Payment rules
- Payment actions are not hardcoded; rather, actions are based on order business events and configurations. Payment rules are already provided in WebSphere Commerce that you can apply to your store's business practices through configurable XML files. Payment rules 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 event-driven payments 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 desired target states for the payment.
- Advanced orders
- 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). 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 (for example, backordered items) a week later when that part of the order ships. 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 for one or more orders. For example, a single refund transaction can occur for orders 1234 and 4567, rather than as two transactions. Refunds can be issued with or without associated Return Merchandise Authorizations.
Darwyn: The event-driven payments subcomponent also supports exchanges (using funds associated with a return as a credit towards another order). Cross shipping is also supported (shipping an order item to a customer while the customer is sending another order item back as a return). Payment instructions can also be stored for use when customers cannot fulfill their obligations in the returns process (payment collateral).
- Edits
- Information can be edited to update payment amounts and other payment information (such as the zip code in a payment instruction, or a new credit card if the original credit card was reported as stolen).
Darwyn: Changes can also be made to an order after it is released to fulfillment, but before the order ships (in effect, to enable a last-chance edit).
- Payment plug-ins
- If you need to 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 event-driven payments subcomponent to communicate with the traditional WebSphere Commerce Payments multi-payment framework and cassettes though a lightweight payment plug-in for the multi-payment framework. Or, 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. The Payment Plug-in Controller 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 event-driven payments subcomponent is configurable by developers. It is J2EE compliant and is built as a stateless session bean. Because it is J2EE compliant, it provides high-availability and cloning options not available with the WebSphere Commerce Payments component. Also, because the event-driven payments subcomponent does not rely on the use of task commands, it simplifies payment systems integration with WebSphere Commerce.
- Clustering
- Unlike WebSphere Commerce Payments, event-driven payments are supported in a clustered WebSphere Commerce environment.
- Promotional offers and exchanges
- You can offer promotional items at no charge or modify an existing order to be processed and shipped without requiring payment information from the customer. An order with a zero total payment can be submitted by a customer for items offered at no charge, orders that have no charge due to an equal exchange of a previously ordered item, or adjustments to orders made by the Customer Service Representative.