Add recurring billing support to DPS Payment Express

I have prepared and test some changes that enable the uc_paymentexpress modules to provide recurring billing support. These changes work with recurring billing functions provided by the uc_recurring module.

The recurring billing support is implemented as a separate module "uc_dps_recurring" that should probalby be located in the uc_paymentexpress folder along with the other modules and associated files.

It is currently implemented only as an initial charge using the PxPay gateway hosted by DPS, and requesting a billing token to be returned. This billing token is stored with the recurring fee data and then presented to DPS (via the PxPost gateway) on all subsequent re-charging.

This approach is required because while the PxPay gateway can return billing tokens on request, is cannot accept them. Billing tokens can only be accepted by PxPost.

uc_dps_pxpost
I have had to make some changes to the uc_dps_pxpost module to configure the function "uc_dps_pxpost_charge" to behave differently when a billing token is included in the passed $data array.

When a billing token is passed, it will use this in preference to selecting the credit card details that are otherwise expected to be present in the $order->payment_details array.

I have also taken the opportunity to add two new fields to the form used for collecting configuration information. These fields allow a transaction reference prefix to be specified separately for transactions using captured credit card details and transactions using a stored billing token. This idea came from the similar functionality implemented in uc_dps_pxpay.

I have not yet been implemented functionality to use a PxPost transaction to capture credit card details and then request a billing token from DPS for future use, either with recurring transactions or for subsequent orders placed by the same client.

uc_dps_pxpay
This module contained a number of logic flow errors that prevented the natural completion of purchase transactions. Some of these errors had been corrected by duplicated code, but transactions were easily failed. I have tried to find and correct these.

The module now will make its first call to DPS to get the secure URL for redirecting the user to the hosted payment page once the cart checkout review form is submitted. If DPS does not provide this URL, an error is returned preventing the submit form succeeding. The secure URL is saved for later use, and other modules are then permitted to complete their order submit processing. This module modified the cart checkout review form to add a submit handler, which inserts a redirect to the DPS secure URL in place of the standard "/cart/checkout/complete" already added.

When DPS has captured the credit card details and confirmed the payment, it will return to the success URL provided, and the function "uc_dps_pxpay_complete" in file "uc_dps_pxpay.pages.inc" will be called. This performs the required processing and then redirects the user to "/cart/checkout/complete".

The module uc_dps_pxpay will, if module uc_recurring is enabled, identify transactions that have a recurring charge associated with them, and request a billing token from DPS automatically. Currently this ability to detect when a billing token is required does not include subscriptions. However, a facility exists to request a billing token for all transactions.

uc_dps_recurring
This is a new module that manages the required uc_recurring hooks to interface with the PaymentExpress payment modules.

Patches and module tar files will follow.