Reference > Payments subsystem > Payments subsystem > Payments subsystem architecture


Payment actions

A payment action moves a payment state to a target state. Payment actions are triggered by payment rules based on the payment method, payment event, and payment state.

The following list shows some payment actions:

The CorePaymentActions XML file specifies payment actions. Not all actions are configurable for every payment event.

The following list summarizes all possible payment actions:

Approve

Verifies that the customer is allowed to make the purchase. 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.

To support the payment methods migrated from previous releases, the Approve action is mapped to the DoPaymentCmd or the CheckPaymentAcceptCmd depending on whether ORDPAYMTHD table is already populated for this order.

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.

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; 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, typically as a result of returning merchandise that was purchased. This action can occur during the following task commands: FinalizeRefundCmd.

Error

Generates an error message to indicate that an exception situation has occurred. The move 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.

To support the payment methods migrated from previous releases, ConsumeAmount action is mapped to CheckPaymentAcceptCmd. The ConsumeAmount action calls CheckPaymentAcceptCmd to check whether the current authorization has expired. If it has expired then another authorization against same payment method is triggered.


Related concepts

Payment rules engine

Related reference

Payment configuration files

CorePaymentActions XML file


+

Search Tips   |   Advanced Search