Payment actions
The behavior of Payment Rules processing is dictated by how payment methods and refund methods are configured and what Payment Rules those configurations use.
The Payment Rules define what the target state of a payment should be for each Payment Rules task command (PrimePaymentCmd, ReservePaymentCmd, and FinalizePaymentCmd).
The core behavior of payment actions is dictated by the contents of the CorePaymentActions xml file. You should not have to update or create this file when configuring payment processing for your store if you are using the payments functions provided with WebSphere Commerce.
In the Payment Rules subcomponent, payment actions are the operations that appear in the following list. Not all actions shown are configurable for every business event.
- Approve
- Verifies that the customer should be allowed to make the purchase to reduce the merchant's risk of not receiving payment for the order. The approve action helps to ensure that a customer has adequate funds available to make the purchase. Depending on the payment type and business policy, varying actions will be performed. For example, in the case of credit cards, a credit card authorization request is sent and a transaction is approved, thereby ensuring the merchant will receive payment. A positive approval results in an authorization code being generated, and those funds being set aside. The cardholder's credit limit is then reduced by the authorized or approved amount. The intention is that payment problems that are detected can be communicated back to the customer while the customer is online. The approve action does not apply to all payment methods. For instance, it would not make sense for an approve action to occur for electronic check (ACH) transactions. The approve action can occur during the following task commands: PrimePaymentCmd, ReservePaymentCmd, and FinalizePaymentCmd.
- ApproveAndDeposit
- Verifies that the customer should be allowed to make the purchase and captures payment for the order. Some payment systems do not implement an approve payment action by itself and instead use a process that performs both the approval and deposit as a single process (for example, electronic fund transfers and electronic checks). This action can occur during the following task commands: PrimePaymentCmd, ReservePaymentCmd, and FinalizePaymentCmd.
- ReverseApproval
- Voids an approval. Only full reversals are supported; the reversal of partial amounts is not supported. This action can occur during the following task commands: ReservePaymentCmd, FinalizePaymentCmd, CancelOrderCmd and EditCmd.
- Credit
- Issues a refund to return money to the customer, usually as a result of returning merchandise that was purchased. This action can occur during the following task commands: FinalizeRefundCmd.
- Deposit
- Captures a payment for an order. In general, communication with a payment back-end system or payment processor occurs at this stage. This action can occur during the following task commands: PrimePaymentCmd, ReservePaymentCmd, and FinalizePaymentCmd.
- Error
- Generates an error message to indicate that an exception situation has occurred and the transition from the current payment state to the target payment state is not valid.
- ConsumeAmount
- Updates amount information in the Payment Rules database tables but does not cause any direct payment action with a payment back-end system (information update only). For example, this action keeps track of increments made against the total payment reservation amount. The ConsumeAmount action is invoked implicitly when other actions are used by the CorePaymentActions.xml file. Note: To support the payment methods migrated from previous releases, ConsumeAmount action is mapped to CheckPaymentAcceptCmd and Approve action is mapped to DoPaymentCmd or CheckPaymentAcceptCmd depending on whether ORDPAYMTHD table is already populated for this order.
The following payment actions, which exist in WebSphere Commerce, are not supported by the Payment Rules subcomponent:
- DepositReversal
- CreditReversal
(C) Copyright IBM Corporation 1996, 2006. All Rights Reserved.