Request payment authorization, thereby mitigating the risk of not receiving payment for the order.
Perform the tasks necessary to obtain payment authorization for an order being processed. Depending on the payment type and the business policy for the payment type, varying actions will be performed. The intention is that any payment problems that can be detected while the customer is still online are detected and communicated back to the customer. For certain credit cards, for example, a LUHN check is performed and any errors are surfaced as problems with the credit card.
Input to the process is an order requiring payment authorization. If successful, output is an order with the payment authorized. Sometimes, the authorization does not complete right away; in this case, the output will be an order with payment authorization requested.
If payment authorization has already been requested (this will be the case for processing a backorder or and order for which remote fulfillment failed), then check the existing payment status and update the order appropriately. This could result in an order with payment authorized, a canceled order, or an order still requiring payment authorization (no change).
If payment authorization has not already been requested, then do the following:
The following tasks are then performed:
This will result in an order with payment authorized, an order with payment denied, or an order with payment authorization requested.
Payment authorization
WebSphere Commerce Payments
Line of credit
External accounting system integration
Purchase-order support
Integration with back-end payment systems
Professional, Business Edition
Task | Description | Role |
---|---|---|
Validate business account |
Assure that the business account being used is valid. |
System |
Check TA spending limit |
Check the trading-agreement (TA) spending limit to see whether or not it has been exceeded. An order may include order items that are purchased under different trading agreements, and different trading agreements may have different spending limits.
Records for the purchase amount and refund amount for purchases and refunds against a trading agreement with a RightToBuy-by-amount TC are kept in the same currency specified for the RightToBuy-by-amount TC. These records are kept in separate tables, TRDPURAMT and TRDREFAMT respectively. Note that the currency of this RightToBuy TC must not change once the trading agreement has been activated and purchases have been made against the trading agreement. Purchases can be made using a currency that is different from the currency specified for the RightToBuy-by-amount TC.
The purchase amount of an order item is the sum of the ORDERITEMS.TOTALPRODUCT plus ORDERITEMS.TAXAMOUNT plus ORDERITEMS.SHIPCHARGE plus ORDERITEMS.SHIPTAXAMOUNT minus ORDERITEMS.TOTALADJUSTMENT. (Similarly, the purchase amount for the whole order consists of the sum of ORDERS.TOTALPRODUCT plus ORDERS.TOTALTAX plus ORDERS.TOTALSHIPPING plus ORDERS.TOTALTAXSHIPPING minus ORDERS.TOTALADJUSTMENT. This is the same as the total amount passed by the caller.) |
System |
Handle payment authorization denied |
Display an error view to the buyer if the PO number is not valid or the PO spending limit has been exceeded. |
System |
Cancel order |
Update the order state to canceled (X). |
System |
(C) Copyright IBM Corporation 1996, 2004. All Rights Reserved.