PAYMENT METHODS FOR GROUPS

In addition to the ability to sort the methods, you can restrict any of the methods to specific price group(s) customers. Each method can have its own list of acceptable or unacceptable price group customers. The default displays the methods without regard to the price group the customer is in.

You can restrict the payment methods to specific countries. You decide whether you will tie it to the ship to or bill to address. Then you can create a list of acceptable or unacceptable countries. The default displays the methods without regard to countries.

You can further restrict payment methods to a specific subtotal range of products. For example, if you did not want to accept checks for product subtotal over $50, you would setup the range for check payments as 0.00 to 50.00. The default displays the methods without regard to order subtotal.

You can also restrict payment methods based on categories of products that are in the basket. Thus, if you have certain categories of products that you do not want to allow a specific payment method, you would enter the category codes into the input. If any of those categories of products were in the basket, the method would be hidden.

Each method can have a different configurable message (text or html) which is displayed using tokens. This message can be displayed on the order payment screen (the screen after payment method is selected) and on the invoice screen. It can also be in the customer and merchant notification emails if they can implement module tokens in the format %module|paygroup|html_message%. This eliminates the need to install a separate, custom module for checkout messages or rely on the payment module to have the message capability (many do not have it).

The store owner can use the default select list layout or use a template for the layout of the payment options. The template can use either select inputs or radio inputs.

This module is compatible with both the MMUI and OpenUI. The MMUI requires minor editing and recompiling (with mivascript compiler) of the mmui.mv file. Therefore, unless you have access to the compiler, OpenUI is required.

The module can use OpenTokens instead of hook points within OpenObjects. The OpenDesigner screen lists the OpenObjects which can replace all or some screens within the OpenUI user interface. The OpenObjects provide a template screen which contains the existing hook points (backward compatibility), OpenToken capability, and the ability to move output around within the OpenObject screen.