Payment Subsystem

The WebSphere Commerce instance (Server1) contains payment information. The Payments subsystem connects to Payment Service Providers by using payment plug-ins.

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 Flow at a glance

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.

 Payment Lifecycle

There are three stages to payment processing: 

• validation
• reservation
• finalization

 The payment life cycle is related to the order life cycle stages: 

• order capture
• release to fulfillment
• shipping

validation

Ensures that a customer has enoughfunds to make the purchase. The payment action depends on the customer's payment method. For instance, when a customer pays for a purchase using a credit card, a credit card authorization is sent and if it is valid, the transaction is approved. This process occurs during an order submission.This authorization can be 1$ or full $ auth. It depends on the business needs.

reservation

Ensures that funds are available before shipment of the goods. The reservation amount is the sum of all order release amounts. This process occurs during a release to fulfillment.

finalization

Payment finalization is typically driven by a shipment confirmation message from or on behalf of the fulfiller. This process occurs when the goods are shipped for the order release.

An order can have multiple releases if items in the order must be shipped from different warehouses or use different carriers, or if some of the items need to arrive at different times, such as for an expedited item. Additionally, a customer can group order items in the same order to ship together, including backordered items or future shipments.

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

Order and Payment Subsystem Flow

Once items are added to cart, an order is created in the ORDERS table with status as pending “P”. Items in the shopping cart are added to ORDERITEMS table which has an ORDER_ID reference to the ORDERS table. Correspondingly, a payment order record is created in the EDPORDER table. Once the customer selects payment method and proceeds for payment, for each payment method in the order, there is a payment instruction record created in the EDPPAYINST.

Using the payment instruction returned, you can get the details like amount, payment method, etc.

There is a PPCPAYINST table which stores the value object Payment Instruction in WCS which contains information for payment plugins to process the final payments. Payments for a specific payment method can only be charged upto a maximum specified by the AMOUNT column in PPCPAYINST table. PPCEXTDATA contains non-standard data specific to a payment method. For example, paymentexpress might have some non-standard protocol data which is stored in here.

Tables

EDPOrder is the part that handles the payments part only. Every order has an entry in EDPORDERS.

EDPPAYINST contains the list of all payment instructions associated with an order. To fetch ths list we have to come through EDPORDER.

PPCPAYINST contains the detailed information required to process financial transactions. BACKPIID of EDPPAYINST points to PPCPAYINST.

PPCEXTDATA stores the non-standard protocol data required in the financial transaction which goes beyond the standard attributes defined in the payment instruction

EDPPAYHIST keeps the payment activity history for all operations on payment instructions and financial transactions. 

Click here to know How to create a new payment method ?

Click here to know about Payment Processing Flow.