Add a form handler selection for views.  This provides a user-selectable list of pay_form handlers during views configuration.

When querying for a list of payment forms filtered by handler, ensure that the subclasses of that handler are also included.  This allows you to be extend a pay_form handler without having its entries omitted from the list.

Update handling of currency-setting.  Allow users to update global currency _only_ if there are no existing transactions that use the currency.  This means you can futz with currencies all you like, until you've started creating transactions.

Add a set_currency() function to pay_transaction.  Defaults to $pay_form's currency (which in turn probably defaults to the globally-selected currency).

Add a currency_list() method for payment forms.  By default, this will only return the globally-available currency.  If an as-yet-unwritten module variable_sets pay_currency, it will also return a list of currencies supported by its payment methods.

Rewrite pay_currency_list() so that it's not using a hard-coded list of USD & EUR (how presumptuous!)

Instead, create a superset of all currencies supported by all payment method handlers installed on the site.

Add an available_currencies() method to pay_method.  The expectation is that all payment methods implement this to identify the currencies that they support.

- Always save transactions when an activity fires

As it turns out, we do use the 'authorize' action for more than just pay_method_gateway.  Re-add it to pay_method, and re-remove it from pay_method_custom.

Move some functions around for cleanliness.  Make sure that payment method values get sent to the gateway provider correctly.

Refactor the form_submit function for direct payments: Do not assume that all submissions will use this payment activity, and do not rely on form submissions to collect and store values.

Add set_direct_pending(), which will do most of what a gateway needs it to do - which is save its submitted data and set the current activity to 'pending'.  

The expectation is that the 'response' will create a second activity after the customer has completed payment on the gateway site.

Optionally pass in an array of values to payment actions.  On pay_form submissions, populate this with the values submitted for a particular payment method.

Implement views handling for payment transaction states, which allows filtering/sorting/aurgumenting/fielding of said states.

Add some helper functions to pay.module to help facilitate this.

Complete work on actions-handling.  Pay now implements 3 transaction actions via hook_action_info(): delete, complete, and cancel.  It also supports views_bulk_operations module so that these actions can be completed from a view display.

Add a 'cancel' action.  Don't allow cancel to work on completed transactions, and don't allow refunds on canceled transactions.

Ensure that a pay_method always has an activity before we processes *_action and/or execute().  This is much better than passing $activity around.

Do not make the assumption that a transaction_total will always equal the attempted total.  This is only true on 'capture' transactions, so only set it there.

Add useful values to a re-billed transaction and make sure those values get sent through the transaction.

Derive that a 'complete' activity is actually meant to capture a prior authorization if there's an authorization in the transaction's history.