Advanced orders Payment Plug-in Controller

The Payment Plug-in Controller is software in WebSphere Commerce that processes payments through the use of payment plug-ins. The following functions are the main functions of the Payment Plug-in Controller:

As an alternative to the traditional component known as WebSphere Commerce Payments, the Payment Plug-in Controller works with the event-driven payments subcomponent to handle payment actions when required. It defines the processing agreement for payment plug-ins and manages the life cycle of payment plug-ins. The processing agreement simplifies integration with a payment system and enables common payment and credit actions to occur for any payment method. The Payment Plug-in Controller is also designed to allow plug-ins to be transportable across operations systems and database tools.

When the Payment Plug-in Controller receives a request to perform an action, it finds the payment plug-in that is responsible for processing the request, and delegates the appropriate action to the plug-in. Validation of payment information is handled by payment plug-ins. The Payment Plug-in Controller then updates the necessary information and stores data in the WebSphere Commerce database to keep a record of the payment activity.

Refer to Financial transaction execution flow to see an example of how a financial transaction flows through the system.

The Payment Plug-in Controller has a global view of all of the payments and credits that are processed for a given payment instruction. In contrast, from a Payment Plug-in Controller perspective, a payment plug-in only has information about what needs to be processed at a particular point in time.

To understand this concept, review the following example:

A customer purchases two pairs of pants ($60 U.S. dollars) and a shirt ($40); the total cost of the order is $100. The pants can be delivered the next day but the shirt will be delivered three days later. The event-driven payments subcomponent calls the Payment Plug-in Controller to create a payment instruction in the amount of $100, and approve $100. It also calls the Payment Plug-in Controller to deposit $60 for the pants. A few days later it deposits $40 for the shirt.

The Payment Plug-in Controller records the fact that the payment instruction has a $100 total amount, with a single approval of $100 and two deposits--one for $60 and one for $40. However, the payment plug-in does not retain this information; it processes the individual actions as they occur. Because it treats these actions separately, it does not store information about all three transactions. The Payment Plug-in Controller and event-driven payments subcomponent keep track of the actions performed under a particular payment instruction.

The Payment Plug-in Controller has a default state transition and defines state transitions for payments and refunds (credits). At a low level, a payment state moves from Approving to Approved with a successful authorization, and moves from Approving to Failed with a denied authorization. Depending on what is happening with the order (such as cancel order, order edit, and so on), a payment state can also be Canceled. Because multiple deposit transactions can occur for a payment, there is no Deposting or Deposited state in the Payment Plug-in Controller. Instead, the terms depositingAmount and depositedAmount are used to identify whether the payment has a pending deposit or has a processed deposit, respectively. Credit states can be: Crediting, Credited, Canceled, or Failed.

If you are writing your own plug-in, you can change some of the behavior of the state transition by setting status fields of the financial transaction objects for the payment or credit being processed. The states of financial transactions are:

Feedback