Background tasks are provided in WebSphere Commerce to periodically clean up unfinished orders, including those associated with event-driven payments. These cleanup tasks must be scheduled to handle orders remaining in a stale or incomplete state. For instance, orders can become stale if merchandise is no longer available because the product is never restocked. Or, an order can be blocked indefinitely if a failed payment operation prevents the order from completing normally. The scheduled tasks clean up these orders by putting them in a canceled or finalized state.
These cleanup activities are triggered by scheduled WebSphere Commerce commands (or through the WebSphere Application Server Scheduler Service).
Advanced orders The event-driven payments subcomponent relies on the following commands to clean up orders:
- To cancel stalled orders: OrderCancel controller command. Additionally, a PayCleanupCmd controller command cleans up orders in a decline state (payments that have not been approved).
- Process pending payments (EDPDepositableAmountProcessCmd). This controller command deposits amounts that have been approved and could have been deposited but were not yet deposited. This command is unique to the advanced orders environment.
The following example shows why a pending payment would be processed.
Suppose an order exists for $100 and the initial amount associated with the order items in stock was $100, but there are two releases of the order because the customer wants the items shipped to two different addresses. One release is for $40 and the other release is for $60. The event-driven payments configuration calls for payment deposits to accumulate rather than occur with every release. The target states for the payment are: primePayment event - Approve, reservePayment event - Approve, finalizePayment event - Deposit.
During the primePayment event, $100 is approved. During the reservePayment event, nothing happens because the order is already approved. During the first finalizePayment event, $40 should be deposited, but because the payment rule configuration is set up to accumulate deposits, no deposit is executed. During the second finalizePayment event, $60 should be deposited. Since all $100 is ready for deposit, a deposit of $100 occurs.
If, after approval of $100 the order item for the second release ($60) becomes unavailable permanently, the deposit would never occur. In this case, a scheduled controller command must be run to execute the deposit of $40 for the item that was available.