Reference > Payments subsystem > Payments subsystem

Payments subsystem architecture

Overview

The Payments subsystem contains three main parts:

• Payment rules engine
• Payment plug-in controller
• payment plug-ins

Concepts...

• Payment methods
• Refund methods
• Payment, refund and return payment business policies
• Payment instructions
• Payment events and task commands
• Payment actions
• Financial transactions

The Payments subsystem contains three main parts:

Payment rules engine

The Payment rules engine determines which action to take based on the payment instruction, payment method and the payment event.

Payment plug-in controller

The Payment plug-in controller is a component of the Payments subsystem. It determines which plug-in to use (based on the payment method) and which plug-in API method to call (based on the action).

Payment plug-ins

A payment plug-in is a self-contained software component that serves as a proxy for a payment back-end system.

Payment processing flow

The following diagram shows how a payment is processed by the Payments subsystem.

1. The shopper or CSR completes an order. When the order is submitted, the OrderProcess command runs, then invokes the PrimePayment payment task command.

2. The Payment rules engine determines the payment action that needs to be performed, for example, Approve.

3. The payment action is wrapped into an event, which is passed to the Payment plug-in controller. For example, for the approve action, the Payment plug-in controller API Approve is called.

4. The Payment plug-in controller determines which plug-in to use.

5. The payment action is invoked against the plug-in. For example, for approve action, the API approve of the corresponding plug-in is called.

6. The plug-in interacts with the Payment Service Provider.

7. The plug-in sets the transaction state according to the transaction execution results with the Payment Service Provider. This transaction state will return to the Payment plug-in controller.

8. The Payment plug-in controller updates the payment related records in the database according to the state of transaction execution returned by the plug-in.

See

• Payment instructions
  A payment instruction is the instance of a payment method with the details necessary to perform payment actions. For example, if a payment method name is Visa, then the payment instruction consists of Visa, the payment amount, cardholder's name, billing address, account number, and expiration date.

• Payment methods
  Payment methods are the means by which payments are made. Payment methods include credit card brands, electronic checks, gift certificates, and manufacturers' coupons. The shopper selects the payment method on the Order Summary page.

• Refund methods
  Refund methods are the means by which money is credited to customers returning merchandise. Refund method are configured in the POLICY database table by Payment policy types. For example, for a credit card payment method, the refund method is also a credit card.

• Payment, refund and return payment business policies
  Payment methods and refund methods are defined in the POLICY, POLICYDESC, and POLICYCMD database tables. If the predefined payment methods and business policies do not meet the needs, you can add new ones. However, do not remove a Payment or ReturnPayment business policy; this could result in a broken payment term and condition.

• 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.

• Payment rules engine
  The Payment rules engine determines which action to take based on the payment instruction, payment method and the payment event.

• Payment plug-in controller
  The Payment plug-in controller is a component of the Payments subsystem. It determines which plug-in to use (based on the payment method) and which plug-in API method to call (based on the action).

• Merchant feature
  You can use the merchant feature to manage merchant information by storing and managing the store-specific properties from the Payment perspective.

• Payment events and task commands
  Payment events correspond to order life cycle phases and task commands.

• Payment configuration group
  A payment configuration group is a set of XML files that is associated with a specific payment method. For example, if the store will accept checks, cash on delivery, and two brands of credit cards, four payment configurations are required. A payment configuration group is an identifier for a group of payment configurations for different payment methods. The same payment method can have different payment configurations in different payment configurations groups identified by a different payment configuration group ID. A payment configuration ID is the mechanism by which the Payments subsystem identifies the set of configuration files to use for a given payment method. It is a string value that represents the folder or directory name where the XML configuration files are located. A payment configuration ID is used by the payment business policy in the POLICY database table. Payment business policies have the policy type "Payment."WebSphere Commerce provides a default configuration group for every payment method it initially supports (for example, for brands of credit cards, check, COD, Bill Me Later, and line of credit). You can use this configuration as it exists or create new ones manually. The "default" payment configuration group refers to a directory with default payment method configurations.

• Extended data in payments or credits
  Some payment plug-ins require extra protocol data or keywords to communicate with a back-end system. This extra protocol data called extended data is in addition to the standard attributes defined in the PaymentInstruction definition. Extended data is any data other than the currency, amount of the payment instruction, and the payment method name. For example, credit card number, expiration, and billing address are extended data.

• Financial transactions
  A financial transaction is either a single individual payment or a credit transaction. A payment financial transaction corresponds to a payment action in the Payment rules engine and a credit financial transaction corresponds to a refund action. Every time the Payment rules engine decides the payment or refund action that needs to be run, the corresponding financial transaction is then run in the Payments Plug-in Controller with the Payments Plug-in.

• Payments subsystem advantages
  The Payments subsystem offers many advantages compared to the WebSphere Commerce Multipayment Framework.

Related concepts

Payment plug-in controller

Payments subsystem

Payment events and task commands

Payments subsystem advantages

+

Search Tips   |   Advanced Search