Tattvamasi : Payment subsystem in Websphere Commerce

www.tattvamasigroup.com

https://www.youtube.com/channel/UC4Eu5FMElRqUVZX7g8QV3iA/playlists

HOME

1.Payment Subsystem
The Payments subsystem was introduced in WebSphere Commerce Version 6.x.

2.Payment Subsystem Architecture
The payment subsystem contain three parts

2.1.Payments Rule Engine

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

2.2.Payment Plugin 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).

2.3.Payment Plugins

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

3.Payment Processing Flow

The shopper or CSR completes an order. When the order is submitted, the OrderProcess command runs, then invokes the PrimePayment payment task command.
The Payment rules engine determines the payment action that needs to be performed, for example, Approve.
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.
The Payment plug-in controller determines which plug-in to use.
The payment action is invoked against the plug-in. For example, for approve action, the API approve of the corresponding plug-in is called.
The plug-in interacts with the Payment Service Provider.
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.
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.

4.Payment subsystem architecture

Orders---->PaymentRulesEngine---->PaymentPluginController----->Plugin--------- >PaymentService Provider

The Payments subsystem contains three main parts:

4.1.Payment rules engine

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

The following example shows the steps completed by the Payment rules engine when a customer pays for an order using a Visa credit card.

Determines the payment action rule.
The Payment rules engine reads the Payment system mapping (PaymentMappings.xml) file.
```
<Mapping paymentMethod="VISA"  
paymentConfiguration="CreditCardOnline"    
paymentActionRule="Early Approval"/>
```
paymentMethod

The payment method name as defined in the POLICY table.

paymentConfiguration

The payment method is associated to a payment back-end system as defined in PaymentMethodConfigurations.xml file.

paymentActionRule

The payment actions behavior for the payment method as defined in PaymentRules.xml file.
Determines the target state.
The Payment rules engine reads from the PaymentRules.xml file. This is a read-only file that configures the payment rules for a store or store group. Each entry defines the target state of the relevant payment amount for each payment event in the order.
```
<PaymentRule name="Early Approval">
     <PrimePaymentEvent targetState="APPROVED" />
     <ReservePaymentEvent targetState="APPROVED" />
     <FinalizePaymentEvent targetState="DEPOSITED" />
</PaymentRule>
```
Determines the actions.
The Payment rules engine reads from the CorePaymentActions.xml file. This read-only file defines how the required target state of the payment is achieved in terms of payment actions defined by the payment back-end system.
```
<TargetApproved>
     <CurrentDNE>
          <Action name="Approve" amount="requested" target="new"/>
     </CurrentDNE>
</TargetApproved>
```
Creates and raises an event for the actions. In this example, the event will consist of a single action: Approve.

4.2.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).

The Payment plug-in controller completes the following steps:

Creates a financial transaction.
- A FinancialTransaction is used to track the progress of the Action as it is processed.
- It is populated with data associated to the Action and the Payment Instruction.
- The FinancialTransaction object will contain attributes such as:
```
state:               new 
requested amount:   359.000 
processed amount:   0.00000 
reference number:   ... 
response code:      ...
payment ID:         10001
...
```
- The transaction data is stored in the PPCPAYTRAN table.

Determine which plug-in to use based on the Payments configuration files:

Use the PaymentMappings XML file to get the payment configuration based on the selected payment method.

<Mapping paymentMethod="VISA"
 paymentConfiguration="CreditCardOnline"
 paymentActionRule="Early Approval"/>

Use the PaymentMethodConfigurations XML file to get the payment system name based on the payment configuration.

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

And finally, use the PaymetSystemPluginMapping XML file to get the plug-in name based on the payment system name.

<PaymentSystemName name="Paymentech" >
     <Mapping paymentConfigurationId="default" pluginName="PaymentechPlugin" >
          <Keyword name="cc_cvc" mask ="-" plain="0" removeAfterApproval ="true"/>
          <Keyword name="cc_nameoncard" mask ="*" plain="0" removeAfterApproval ="true"/>
          <Keyword name="account" mask ="*" plain="-5" searchable="true"/>
     </Mapping>
</PaymentSystemName>

Then the payment method configuration CreditCardOnline will be mapped to the payment system Paymentech in PaymentMethodConfigurations.xml, and the payment system Paymentech will be mapped to the payment plug-in PaymentechPlugin in PaymentSystemPluginMapping.xml.

Calls Plugin.Approve(). In this case, PaymentechPlugin.Approve().
Persist the up-to-date payment states with corresponding payment information in the payment related tables.

4.3.Payment plug-ins

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

A payment plug-in is responsible for these actions: approve, deposit, credit, reverse approval, reverse deposit, reverse credit. The steps are:

Receives data about a financial transaction
Sends the request to the payment back-end system
Receives a response from the back-end system
Decides what data should be stored
Populates the financial transaction with the response data
Returns the appropriate information to Payment plug-in controller

Although some plug-ins are provided in WebSphere Commerce, a Payment plug-in specification is available to enable plug-in writers to develop their own plug-ins. Plug-ins can be simple in nature (serving as a proxy to a payment back-end system) or more complex, such as an interface to an accounting system, or some other system that serves a particular purpose (for example, a gift certificate processing system).

www.tattvamasigroup.com

https://www.youtube.com/channel/UC4Eu5FMElRqUVZX7g8QV3iA/playlists

Tattvamasi

Sunday, 28 February 2016

Payment subsystem in Websphere Commerce

2 comments: