Financial Transactions in Websphere Commerce

HOME






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.

The Payments Plug-in Controller supports the following transaction types:

• approve
• deposit
• approveAndDeposit
• credit
• reverseApproval
• reverseDeposit
• reverseCredit

Depending on the transaction type, the following are different attributes of the financial transaction.

• Response Code
• Reason Code
• Reference Number
• Tracking ID

Payment Actions in Websphere Commerce

HOME




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:

• A credit card payment method and the PrimePayment payment event (triggered during the order capture phase) result in an Approve action.
• A credit card payment method and the ReservePayment payment event (triggered during the release to fulfillment phase) result in a Deposit action.
• An electronic check (ACH) payment method and the PrimePayment payment event (triggered during the order capture phase) result in a Deposit action.

The CorePaymentActions XML file specifies payment actions.

Payment events and Task commands in webspehere commerce

HOME




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

The following table shows the main order life cycle phases and the corresponding payment events and task commands.

Order life cycle phase	Payment event	Task command
Order Capture	Prime Payment	PrimePaymentCmd
Release to Fulfillment	Reserve Payment	ReservePaymentCmd
Shipment Confirmation	Finalize Payment	FinalizePaymentCmd

Explain Payment Instructions in WCS?

HOME




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

A shopper adds a payment instruction during the checkout flow. When the payment instruction is added, the PIAdd command runs and persists payment information to the payment tables. A payment instruction is created in the EDPPAYINST and PPCPAYINST tables. The protocol data is stored in the PPCEXTDATA table.

Explain Payment Business Policies in WCS?

HOME




1.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 your needs, you can add new ones. However, do not remove a Payment or ReturnPaymentbusiness policy; this could result in a broken payment term and condition.

1.1.The tables used are

1.1.1.POLICY

Defines the payment and refund methods that are used by a store or store group.

1.1.2. POLICYDESC

Stores the descriptive names of the policy (such as the short and long description).

1.1.3.POLICYCMD

Defines a set of payment command implementations for each payment policy.

Explain Refund Methods in Websphere Commerce?

HOME




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

refund methods are

1.1.Credit card

• AMEX
• Mastercard
• VISA

1.2.Line of credit

In a B2B direct store, the contract specifies available refund methods.

Explain Payment Methods in WCS?

HOME


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

Payment methods have the following properties: payment method name, priority, ability to be edited (whether the amount can be changed by an administrator, or by the system), and amount limits. The payment policy is specified in the POLICY and POLICYDESC database tables. The properties are defined in the PaymentMethodConfigurations.xml file.

A shopper can use more than one payment method to pay for an order. The priority determines which payment method should be used first. For example, if a gift certificate has a high priority and a credit card has a medium priority, the gift certificate is used first.

By default the following payments methods are available.

1.1.Credit cards

• AMEX
• MasterCard
• VISA

1.2.BillMeLater

Offline transaction, customer is billed

1.3.Check

Electronic check or automated clearing house (ACH) transaction

1.4.COD

Cash on delivery

1.5.LOC

Line of credit

1.6.PayLater

Offline transaction. for example, the customer provides payment information later by fax.

In B2B direct stores, available payment methods are defined in a contract as a payment term and condition (PaymentTC).

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.

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

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

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

4. 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:

1. 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.
2. 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.
3. Calls Plugin.Approve(). In this case, PaymentechPlugin.Approve().
4. 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 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

Messaging Subsystem in Websphere commerce suit

HOME




1.Messaging Subsystem

The WebSphere Commerce messaging system allows you to manage all aspects of defining and sending messages generated within WebSphere Commerce. It allows you to control the manner in which administrators, customers, back-end and fulfillment center systems are notified of various events, such as customer orders or system errors.

To configure the outbound messaging system use the Administration Console. The messaging system can send messages using transports such as e-mail using SMTP and file using UTF-8 encoding. For e-mail the supported outbound protocol is SMTP, the message encoding depends on the preferred language of the user, and the store/site default language. Optionally, you can configure the messaging system to send messages to a back-end or fulfillment center system using IBM MQ.

2. Features of the outbound Messaging environment

2.1.Composition service

Some of the WebSphere Commerce messages use the message composition services. Through the use of JavaServer Page files, the composition services generate a message before it is sent through the transport. You can modify the message templates just as you would any other JavaServer Page.

2.2.Multiple message transmissions support
2.3.Multiple notification messages over the same transport
2.4.Send a broadcast email to multiple recipients.
2.5.Support for three processing types:

• sendTransacted:-Use for messages sent upon successful completion of the current transaction.
• sendImmediate:-Use for messages sent when the event takes place in WebSphere Commerce. The message is sent whether the transaction commits or not.
• sendReceiveImmediate (Request-reply):-Use for messages that require a response message from the back-end system.

You may like

Trading Subsystem in WCS

Messaging Subsytem in WCS

Trading subsystem in WCS

Catalog Subsystem

Websphere Commerce suit subsytems

Websphere Commerce suit Organizational structure

Trading Subsystem in Websphere Commerce suit

HOME

1.Trading Subsystem

The trading subsystem in WebSphere Commerce provides the logic, function and data relevant for negotiating the price and quantity of a product or set of products between the buyer and seller organization. The trading subsystem includes auctions, contracts, and Request for Quote (RFQ) components that are used to carry out specific transactions between organizations.

2.Terminologies used in Trading subsystem

2.1.Business Relationship Management

To customize what a customer can do in a store use the business relationship management system. By using this system, you can entitle customers to various aspects of a store such as what products they can purchase, the price they pay, and what payment methods a store accepts.

Customer entitlement is controlled by business accounts, contracts, and business policies.

The default customer entitlement is defined by a store's default contract. This default contract typically specifies that customers can access the master catalog and purchase products at standard prices.

2.2.Contracts

Contracts enable a customer organization to purchase products from a store at a specified price for a specified time under specific conditions. You can use WebSphere Commerce Accelerator to manage contracts. Specifically, you can create, change, deploy, suspend, resume, and unlock contracts. 

A contract consists of the following elements.

2.2.1.Profile 

The contract profile contains the identifying information for the contract. This information includes a unique name for the contract, a short description, and a time period for which the contract is valid.

2.2.2.Participants

Contract participants are the organizations that take part in the contract. There is a buyer organization, a seller organization, and contacts at both organizations.

2.2.3.Terms and conditions

Contract terms and conditions are the rules that cover the actual implementation of the contract. Contract terms and conditions cover such information as product pricing, returns and refunds, payment, shipping, billing, and order approval.


2.2.4.Attachments

Contract attachments cover any information that is not covered by the previous elements such as file attachments that provide additional information about the contract and any general remarks about the contract. WebSphere Commerce uses the Universal Resource Identifiers (URIs) for contract attachments, not the actual attachments.


2.2.5.References

A contract can refer to another contract to share its terms and conditions. For example, contract A can refer to contract B. Thus, a buyer who is entitled to contract A is entitled to all the terms and conditions from contract A, and to all the terms and conditions in contract B.

2.3.Business Policies

Business policies are sets of rules followed by a store that define business processes, industry practices, and the scope and characteristics of a store's or group of stores' offerings.

Business policies are enforced with a combination of one or more business policy commands that implement the rules of the business policy. Each business policy command is a Java class. A business policy command can be shared by multiple business policies. The behavior of the business policy command is determined by the parameters that are passed to the command.

Parameters affecting the function of a business policy command can be introduced in three places:

• The contract term and condition, which refers to the business policy
• The business policy definition
• The business policy command that enforces the policy

2.3.1.Catalog business policies

Catalog business policies define the scope and characteristics of the catalog of products for sale in a store which includes the prices and the categorization of products in a store's catalog.

2.3.2.Payment business policies

Invoicing, payment, and refund business policies define how a store accepts payments, pays refunds, and the format of a store's invoices.

2.3.3.Returns business policies

Returns business policies define whether refunds are accepted, the time period they are accepted for, and any restocking fees that are applied to returns.

2.3.4.Shipping business policies

Shipping business policies define the shipping providers a store can use and the charges that are associated with each type.

2.3.5.Referral interface business policies

Referral interface business policies define the relationship between a proxy store and a remote store.

2.4.Request for Quote

A buyer can create a Request for Quote (RFQ), by using the WebSphere Commerce Accelerator, for unique variations of goods and services that are offered in a catalog. If buyers cannot find a product or category that match their needs within a catalog, they can select attributes from the personalized dictionary to precisely define the product specifications. A buyer can also create an RFQ by using the contents in their shopping cart, or add a shopping cart to an existing RFQ.


There are three RFQ notification messages: The RFQ was submitted successfully; The RFQ was closed successfully; and The RFQ was completed successfully.



Messaging subsytem in WCS


Catalog Subsystem


Subsystems in WCS


Organizational Structure in WCS

Websphere Commerce suit Subsystems

• Catalog Subsystem
• Order Subsystem
• Member Subsystem
• Trading Subsystem
• Marketing and Merchandising subsystem
• Payment Subsystem

You may like

Messaging Subsystem in WCS

Trading Subsystem in WCS

Catalog Subsystem in WCS

Organizational structure in WCS

HOME

Websphere Commerce suit Organizational structure

• Consumer Direct

• B2B Direct

• Demand chain

• Extended Sites

• Supply chain

You may like

Messaging Subsystem in WCS

Trading Subsystem in WCS

Catalog Subsystem in WCS

Subsystems in WCS


HOME