Payment methods and refund methods are defined in the WebSphere Commerce business policy database tables. These policies are described in the tables shown in this topic. These payment business policies are available for use right away for the payment methods supported in WebSphere Commerce.
If the available payment methods and business policies do not meet your needs, new payment/refund methods can be added and new payment business policies can be defined. Site Administrators can configure event-driven payment rules for a store and can configure the payment plug-in to support the new payment method. If you are adding a new payment method or refund method for use with event-driven payments, you must update the WebSphere Commerce database tables that contain information about the payment methods or refund methods that your store will use.
The database tables you will update are POLICY and POLICYDESC. The POLICY table contains information about the payment methods used by a store or store group, and any special properties used. The POLICYDESC table stores the descriptive names of the policy (such as the short and long description). This database table information is required regardless of the type of store or business model you are using.
When the WebSphere Commerce Accelerator is used to add a payment (or refund) method to a store, a new entry for the method is automatically created in the POLICY table.
The business policies used by the event-driven payments subcomponent are:
- Payment - Defines a payment method that flows through event-driven payments
- ReturnPayment - Defines a refund method that flows through event-driven payments
The Payment and ReturnPayment policies are similar in type to the policies used in a standard order processing environment (as described in Defined payment business policies). However, these policies have unique IDs and properties associated with them that make them different from the payment business policies used with standard order processing. If a Payment policy or ReturnPayment policy has the property paymentConfigurationId, the policy is an advanced orders processing payment or refund method. If no paymentConfigurationId property exists, the policy is a standard order processing payment or refund method. A paymentConfigurationId value of 'default' refers to a directory with default payment method or refund method configurations.
The business policy tables can be updated by using the massload utility (the Loader) which loads an input XML file to the target database. Instructions on how to use the massload utility are provided in the "Load utility" topic in the WebSphere Commerce information center. (As an alternative, you can enter SQL statements to load the data, but use of the massload utility is recommended to avoid having to supply unique ID values for the new records.)
The business policy tables do not contain information about the type of payment or refund actions or rules the payments subsystem will use. They merely identify the payment and refund methods. The actual payment and refund actions are defined by configuring XML files for event-driven payments.
The following table lists the supported business policy configuration for the payment and refund methods for event-driven payments. Whenever a new payment or refund method is added to a store, a business policy with the Payment or ReturnPayment type must be created in the business POLICY table (with corresponding entries in the POLICYDESC table). For every new entry added to the POLICY table, the value for the Business Policy Name field must match the payment (or refund) method ID configured in event-driven payments (the paymentMethod value in the PaymentMethodConfiguration.xml file, or the refundMethod value in the RefundMethodConfiguration.xml file).
The removal of a Payment or ReturnPayment business policy can result in a broken payment terms and condition because the relationship to the policy is removed.
Note: If you are using the line of credit payment method in both a standard and advanced order processing environment, you should ensure that the POLICY table has two entries, one for each type of order environment, and that the business policy name is not identical for both policy entries. For example, the policy name is LineOfCredit for advanced order processing, but Credit (for the CreditLine policy) for standard order processing.
Payment business policies for advanced order processing (policy type = Payment)
Refund business policies for advanced order processing (policy type = ReturnPayment)
Policy ID | Business policy name | Short description | Long description | Properties* |
---|---|---|---|---|
-2001 | UseOriginalPayment | Refund using original payment method | Refund using original payment method | None
Note: This policy is the same as in previous releases. The Returns system identifies payment information from the original order and provides the information to event-driven payments. This is not a policy created specifically for event-driven payments. |
-8900 | Visa | Visa refund method | Visa Credit Card used as a payment method while requesting a refund in association with an RMA | attrPageName=StandardCreditCard excludeFrom=defaultTC requireExplicit=true paymentConfigurationId=value showQualifiedSensitiveData=false |
-8901 | Master Card | MC refund method | MasterCard Credit Card used as a payment method while requesting a refund in association with an RMA | attrPageName=StandardCreditCard excludeFrom=defaultTC requireExplicit=true paymentConfigurationId=value showQualifiedSensitiveData=false |
-8902 | AMEX | American Express Credit Card | American Express Credit Card used as a payment method while requesting a refund in association with an RMA | attrPageName=StandardCreditCard excludeFrom=defaultTC requireExplicit=true paymentConfigurationId=value showQualifiedSensitiveData=false |
-9806 | LineOfCredit | Line of Credit | Line of Credit used as a payment method while requesting a refund in association with an RMA | attrPageName=StandardCOD excludeFrom=defaultTC requireExplicit=true paymentConfigurationId=value |
*For descriptions of the properties, see the related reference topic on defined payment business policy properties.