Plug-in exception handling and transaction roll-back

If a payment transaction fails, and that failure results in a WebSphere Commerce transaction roll back, then the payment transaction data is not in the WebSphere Commerce database.

When transaction rolls back, there are two actions you can take. The transactionCompensationAction parameter in the PaymentMethodConfigurations.xml determines the action:

<PaymentMethodConfiguration 
                 name="CreditCardOnline"
                 paymentSystemName="Paymentech" 
                 systemEditable="true"
                 humanEditable="true"
                 refundAllowed="true"
                 minimumAmount="0"
                 maximumAmount="Unbounded"
                 priority="MEDIUM"
                 partiallyConsumable="true"
                 transactionCompensationAction="track"/>

reverse: The default value. Reverse the successful payment transaction.
track: Track the successful payment transaction. Write to the database after the transaction rolls back.

Consider the two following scenarios:

transactionCompensationAction set to reverse

A customer pays for an order using a gift card and Visa card. The gift card has higher priority than the Visa card.

The order is submitted.
First, redemption against the gift card is called successfully. The gift card is redeemed by the third-party service provider.
Next, validation against the Visa card is called and fails.
This failure causes the WebSphere Commerce transaction to roll back.
No information from the two payment transactions persists to the WebSphere Commerce database.
The UndoPaymentActionsCmd command reverses the payment action that has been successfully run.

The redemption against the gift card was successfully run and the third-party payment service provider tracked this transaction; however, WebSphere Commerce does not have information regarding this transaction since the transaction rolled back. The UndoPaymentActionsCmd runs the compensate payment or credit transactions for those successfully run transactions at the overall WebSphere Commerce transaction rolling back.

The corresponding implementation class runs reverseApproval transaction for a successful authorization transaction. For other transaction types, a tickler is created. With the ticklers created, Customer Service Representative can manually process the reversed transactions for all the transaction types including authorization transaction if reverseApproval fails.

UndoPaymentActionsCmd extension points:

handleUndoPaymentActionForApproval()
handleUndoPaymentActionForApproveAndDeposit()
handleUndoPaymentActionForCredit()
handleUndoPaymentActionForDeposit()
handleUndoPaymentActionForReverseApproval()
handleUndoPaymentActionForReverseCredit()
handlUndoPaymentActionForReverseDeposit()

transactionCompensationAction set to track

A customer pays for an order using a Mastercard card and a VISA card. VISA card has higher priority than the MasterCard.

The order is submitted.
First, validation against the VISA card is called successfully.
Next, validation against Mastercard fails.
This failure causes the WebSphere Commerce transaction to roll back.
No information from the two payment transactions is persisted to the WebSphere Commerce database.
The TrackPaymentActionsCmd command tracks the related payment data for the payment transaction that has been successfully run within the transaction. The information is written back to database.

Validation against VISA card succeeded. Payment Service Provider tracked this transaction. However, WebSphere Commerce does not have information regarding this transaction since the transaction rolled back. Sometimes, it is necessary that the payment data for successful transactions are recorded in the WebSphere Commerce database. The data in the WebSphere Commerce database is consistent with the data on the Payment Service Provider. Successful actions do not need to rerun. TrackPaymentActionsCmd retrieves all related payment data for successful payment transactions when the overall WebSphere Commerce transaction rolls back. The command also restores data to database when the overall transaction rolls back.

By default, an overall implementation is not provided in the implementation class, TrackPaymentActionsCmdImpl. The implementation class provides basic payment data retrieval and restoration logic implementation. For example, data is restored to these tables EDPPAYINST, PPCPAYINST, EDPATMPAY, PPCPAYMENT, PPCPAYTRAN.

TrackPaymentActionsCmd extension points:

retrievePaymentData()
restorePaymentData()