Recurring Payments

I maintain uc_recurring which adds recurring functionality to ubercart. I am interested in seeing better abstraction to payment gateways but not sure that having pay or webform_pay modules triggering the recurring payments is going to be the best way to go. This might be better handled in a separate module - pay_recurring.

There are various different methods that gateways can provide recurring functionality, but generally they are divided into to classes:
1) Hosted - where you send the details of the payment and recurring interval and the gateways does everything. In some cases gateways will send back notifications on renewal attempts so you can respond to these events (e.g. Paypal WPS subscriptions, Authorize.net ARB)

2) Triggered/tokenized - these are gateways where you just send the payment details, credit cards and a token is returned. When a payment needs to be processed you can use this token to trigger payments.

There is a third:
3) Store credit cards details yourself and use the normal (requires addition PCI compliance), in reality one of the better way to implement this would be to setup your own tokenized system (as in 2 above) separate from the normal web database and have a secure method to trigger payments. That way you can restrict access to the sensitive details.

The first step in pay is having a method for gateways to expose what functionality they implement. One option could be through the use of PHP interfaces:

/**
 * A recurring interface for gateways that support the ability to setup a recurring payment.
 */
interface pay_recurring() {
  public function setup_recurring();
}

/**
 * A tokenized payment is one where we can store a token and charge payments when we like.
 * 
 * This type of gateway also allows supporting general recurring functionality so we can extend that interface.
 */
interface pay_tokenized extends pay_recurring() {
  public function token_payment();
}


class MyGateway extends pay_method implements pay_tokenized {
  public function setup_recurring() {
    /* create a token for future payments */
  }
  public function token_payment($amount) {
     /* charge a payment using the stored token */
  }
}


/* In our application code we just wrap specific function in conditional statements */
if ($gatway instanceof pay_tokenized) {
  $gateway->charge_token(100);
}

/* so in billing application could do something like */
global $user;
$payment_method = pay_load_payment_details($user); // attempt to find a payment method for that user
if ($payment_method instanceof pay_tokenized) { // check that we can process a payment
  $gateway->charge_token(100);  // charge the payment
}
else {
  // throw an error.
}

This is not just limited to recurring payments, any payment feature can be implemented this way, where an interface is created to define a set of methods required to use that features. So this could be done for "refunds".

I am looking at creating a pay_recurring module, to go with a module that I maintain: http://drupal.org/project/listing . If anyone has any code already started then it would be appreciated if you could send it along.

Thanks

I'd like to implement a recurring feature for the Realex payment gateway (pay_realex module), but am unsure how to proceed. It uses the tokenised method as described in comment #2 above.

I agree that the module providing the payment form (e.g. webform_pay) should not be responsible for triggering the recurring payment. However, unsure whether it should be the Pay module that is responsible or the payment gateway module. Maybe the Pay module should provide the framework, but allow each payment gateway module to implement their own variation as required?

I'm happy to work on a patch for this if we could agree on how best to go about it.