The behavior of event-driven payment 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 business event (primePayment, reservePayment, and finalizePayment).
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 event-driven payments subcomponent, payment actions are the operations that appear in the following list. Not all actions shown are configurable for every business event.
Note: Some business events are also associated with a "Validation" payment action, meaning that a local validation of the data is performed. The validation is done locally in the payment instruction data by the payment plug-in with no involvement with a back-end system.
The Validation action is not a true payment action and cannot be configured in the CorePaymentActions.xml file as a valid payment action name.
- 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 business events: primePayment, reservePayment, and finalizePayment.
- 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 business events: primePayment, reservePayment, and finalizePayment.
- ReverseApproval
- Voids an approval. Only full reversals are supported; the reversal of partial amounts is not supported. This action can occur during the following business events: reservePayment, finalizePayment, cancelOrder and edit.
- 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 business events: finalizeRefund.
- 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 events: primePayment, reservePayment, and finalizePayment.
- 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.
- ConsumeAmounts
- Updates amount information in the event-driven payments 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 ConsumeAmounts action is invoked implicitly when other actions are used by the CorePaymentActions.xml file.
The following payment actions, which exist in WebSphere Commerce, are not supported by the event-driven payments subcomponent:
- DepositReversal
- CreditReversal