public class DoPaymentActionsPolicyCmdImpl extends BusinessPolicyCommandImpl implements DoPaymentActionsPolicyCmd
DoPaymentActionsPolicyCmd
implementation class for payment
processing component being used. When
PaymentEventListenerCmdImpl
listens a payment event raised by
payment rules component. It will call this class to execute
the corresponding payment action through calling the API of payment
processing component according to the payment/refund action data.
This class is used with payment processing component.
Modifier and Type | Field and Description |
---|---|
static java.lang.String |
COPYRIGHT
IBM copyright notice field.
|
defaultCommandClassName, NAME
Constructor and Description |
---|
DoPaymentActionsPolicyCmdImpl() |
Modifier and Type | Method and Description |
---|---|
ActionResults |
approve(PaymentActionData actionData)
This method executes the approve action.
|
ActionResults |
approveAndDeposit(PaymentActionData actionData)
This method executes the approveAndDeposit action.
|
ActionResults |
deposit(PaymentActionData actionData)
This method executes the deposit action.
|
EDPResults |
getEDPResults()
This method gets the payment action execution results, which indicates
the payment action execution results is successful, pending or failed.
|
java.util.Locale |
getLocale()
This method gets the current locale to be used in the action.
|
java.lang.String |
getOrderChannel()
This method gets the current order channel, which will be put into
payment context where there is a corresponding attribute.
|
java.util.List |
getPaymentActionDataList()
This method gets the list of payment action data that contains the
necessary information for the payment action.
|
java.lang.String |
getPaymentGroupId()
This method gets the current payment group id, which will be put into
payment context where there is a corresponding attribute.
|
java.util.List |
getRefundActionDataList()
This method gets the list of refund action data that contains the
necessary information for the refund action.
|
java.lang.Integer |
getStoreId()
This method gets the store id, which will be put into
payment context where there is a corresponding attribute.
|
void |
performExecute()
This method performs the payment actions through calling the API of
payment processing component by per action data type.
|
ActionResults |
refundDeposit(RefundActionData refundActionData)
This method executes the refund action.
|
void |
reset()
This method is called after a command has been executed.
|
ActionResults |
reverseApprove(PaymentActionData actionData)
This methods executes the reverse approve action.
|
ActionResults |
reverseDeposit(PaymentActionData actionData)
This method executes the reverse deposit action.
|
void |
setLocale(java.util.Locale localeLocal)
This method sets the current locale, which will be put into payment
context where there is a corresponding attribute.
|
void |
setOrderChannel(java.lang.String string)
This method sets the current order channel, which will be put into
payment context where there is a corresponding attribute.
|
void |
setPamyentContext(PaymentContext ctx)
This method sets the payment context on this action.
|
void |
setPaymentActionDataList(java.util.List dataList)
This method sets the list of payment action data that contains the
necessary information for the payment action.
|
void |
setPaymentGroupId(java.lang.String string)
This method sets the payment group id, which will be put into
payment context where there is a corresponding attribute.
|
void |
setRefundActionDataList(java.util.List list)
This method sets the list of refund action data that contains the
necessary information for the refund action.
|
void |
setStoreId(java.lang.Integer integer)
This method sets the store id, which will be put into
payment context where there is a corresponding attribute.
|
void |
updateActionStatusFromBackendResult(ActionData actionData,
ActionResults actionResult,
Result ppcBackendResult)
This method determines action result status based on the status in
backend result returned from payment processing component.
|
void |
validate()
This method validates if the payment action is valid.
|
getPolicyId, getRequestProperties, setPolicyId, setRequestProperties
accessControlCheck, checkIsAllowed, checkResourcePermission, createCommandExecutionEvent, execute, getAccCheck, getCommandContext, getCommandIfName, getCommandName, getCommandStoreId, getDefaultProperties, getExceptionInvokeParameters, getObjectSize, getPostInvokeParameters, getPreInvokeParameters, getResources, getUser, getUserId, isReadyToCallExecute, setAccCheck, setCommandContext, setCommandIfName, setCommandStoreId, setDefaultProperties, validateParameters
executeFromCache, getCaller, getEntryInfo, getId, getSharingPolicy, postExecute, preExecute, setCaller, setObjectSize, unionDependencies, updateCache
getCommandTarget, getCommandTargetName, getTargetPolicy, hasOutputProperties, setCommandTarget, setCommandTargetName, setHasOutputProperties, setOutputProperties, setTargetPolicy
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
getPolicyId, getRequestProperties, setPolicyId, setRequestProperties
executeFromCache, getCaller, getEntryInfo, getId, getSharingPolicy, postExecute, preExecute, setCaller, updateCache
getCommandTarget, getCommandTargetName, hasOutputProperties, setCommandTarget, setCommandTargetName, setOutputProperties
checkIsAllowed, checkResourcePermission, createCommandExecutionEvent, getAccCheck, getCommandContext, getCommandIfName, getCommandName, getCommandStoreId, getDefaultProperties, getExceptionInvokeParameters, getPostInvokeParameters, getPreInvokeParameters, getResources, getUser, getUserId, setAccCheck, setCommandContext, setCommandIfName, setCommandStoreId, setDefaultProperties, validateParameters
public static final java.lang.String COPYRIGHT
public EDPResults getEDPResults()
getEDPResults
in interface DoPaymentActionsPolicyCmd
public final java.util.Locale getLocale()
PaymentContext
, when an object of
PaymentContext
is tried to constructed, it will get the
locale to set it to the payment context object as the attribute locale through this method.public void setPamyentContext(PaymentContext ctx)
ctx
- The payment context to be used in the action.public void setPaymentActionDataList(java.util.List dataList)
setPaymentActionDataList
in interface DoPaymentActionsPolicyCmd
dataList
- The list of payment action data to be used in the actions.public java.util.List getPaymentActionDataList()
public java.util.List getRefundActionDataList()
public void setRefundActionDataList(java.util.List list)
setRefundActionDataList
in interface DoPaymentActionsPolicyCmd
list
- The list of refund action data to be used in the actions.public void performExecute() throws ECException
This method will be called by the PaymentEventListenerImpl that listens the payment event and executes the corresponding payment action.
There is the list of payment/refund action data contains the necessary information for payment/refund action that is passed to this command. Then this command executes each payment/refund action in this list, respectively.
performExecute
in interface ECCommand
performExecute
in interface com.ibm.websphere.command.TargetableCommand
performExecute
in class AbstractECTargetableCommand
ECException
- If something goes wrongpublic void updateActionStatusFromBackendResult(ActionData actionData, ActionResults actionResult, Result ppcBackendResult) throws CommunicationException
actionData
- The action data of the actionactionResult
- The results of the actionppcBackendResult
- The backend result coming from payment processing componentCommunicationException
public void validate() throws EDPException
EDPException
- thrown if payment id is nullpublic ActionResults approve(PaymentActionData actionData) throws EDPException, ECException
This action verifies that the customer should be allowed to make the purchase to reduce the 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.
The payment rules component decides the approve action should be executed through the payment rules configuration. And currently the payment cation name in payment action data equals "ApproveAction". Then this method is called, which calls the API approve of payment processing component. The payment processing component further calls the API approve of Plugin to actually execute the approve action.
Regardless of the results of the approve action, this execution will be stored in the database to record the history the payment/refund action.
actionData
- The action data of the actionEDPException
ECException
public ActionResults deposit(PaymentActionData actionData) throws ECException, EDPException
The deposit action 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.
The payment rules component decides the deposit action should be executed through the payment rules configuration. And currently the payment action name in payment action data equals "DepositAction". Then the this method is called, which calls the API deposit of payment processing component. The payment processing component further calls the API deposit of Plugin to actually execute the deposit action.
Regardless of the results of the deposit action, this execution will be stored in the database to record the history the payment/refund action.
actionData
- The action data of the actionECException
EDPException
- thrown in the event of any failurepublic ActionResults approveAndDeposit(PaymentActionData actionData) throws ECException, EDPException
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. It uses 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.
The payment rules component decides the approveAndDeposit action should be executed through the payment rules configuration. And currently the payment action name in payment action data equals "ApproveAndDepositAction". Then this method is called, which calls the API approveAndDeposit of payment processing component. The payment processing component further calls the API approveAndDeposit of Plugin to actually execute the approveAndDeposit action.
Regardless of the results of the approveAndDeposit action, this execution will be stored in the database to record the history the payment/refund action.
actionData
- The action data of the actionECException
EDPException
- Thrown in the event of any failurepublic ActionResults reverseApprove(PaymentActionData actionData) throws ECException, EDPException
The reverseApprove action 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.
The payment rules component decides the reserveApprove action should be executed in the specific business events. And currently the payment action name in payment action data equals "ReverseApprovalAction". Then this method is called, which calls the API reverseApproval of payment processing component. The payment processing component further calls the API reverseApproval of Plugin to actually execute the reverseApprove action.
Regardless of the results of the reverseApprove action, this execution will be stored in the database to record the history the payment/refund action.
actionData
- The action data of the actionECException
EDPException
- thrown in the event of any failurepublic ActionResults reverseDeposit(PaymentActionData actionData) throws ECException, EDPException
Voids a deposit. Only full deposits are supported; the reversal of partial amounts is not supported.
The payment rules component decides the reserveDeposit action should be executed in the specific business events. And currently the payment action name in payment action data equals "ReverseDepositAction". Then this method is called, which calls the API reverseDeposit of payment processing component. The payment processing component further calls the API reverseDeposit of Plugin to actually execute the reverseDeposit action.
Regardless of the results of the reverseDeposit action, this execution will be stored in the database to record the history the payment/refund action.
actionData
- The payment action data of this actionECException
EDPException
- thrown in the event of any failurepublic ActionResults refundDeposit(RefundActionData refundActionData) throws ECException, EDPException
The refundDeposit action 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.
The payment rules component decides the refundDeposit action should be executed in the specific business events. And currently the payment action name in payment action data equals "Refund". Then this method is called, which calls the API credit of payment processing component. The payment processing component further calls the API credit of Plugin to actually execute the credit action.
Regardless of the results of the credit action, this execution will be stored in the database to record the history the payment/refund action.
refundActionData
- The action data of the actionECException
EDPException
- thrown in the event of any failurepublic java.lang.String getOrderChannel()
public java.lang.String getPaymentGroupId()
public void setLocale(java.util.Locale localeLocal)
setLocale
in interface DoPaymentActionsPolicyCmd
localeLocal
- The current locale.public void setOrderChannel(java.lang.String string)
setOrderChannel
in interface DoPaymentActionsPolicyCmd
string
- The current order channel.public void setPaymentGroupId(java.lang.String string)
setPaymentGroupId
in interface DoPaymentActionsPolicyCmd
string
- The current payment group id.public java.lang.Integer getStoreId()
getStoreId
in interface ECCommand
getStoreId
in class AbstractECTargetableCommand
public void setStoreId(java.lang.Integer integer)
setStoreId
in interface DoPaymentActionsPolicyCmd
integer
- The current store id.public void reset()
AbstractECTargetableCommand
reset
in interface com.ibm.websphere.command.Command
reset
in class AbstractECTargetableCommand
Command.reset()