I'm working for a client on converting the uc_payflowpro module (http://drupal.org/project/uc_payflowpro) to work better with D6 and to work with this module. Can you point me to any documentation that exists for what functions I need to implement to support uc_recurring?

Thanks.

Comments

Matthew OMalley’s picture

I might be able to answer a few specific questions about this, but can't help directly since I'm working on a D5 site. But I have gotten recurring payments working on Payflow Pro (with a few caveats - see issues http://drupal.org/node/494606 http://drupal.org/node/494476 http://drupal.org/node/494492).

However, I did not use UC_Recurring to get this running, just used UC_PayflowPro and the recurring options within PayflowPro.

Best,
Matthew O'Malley

univate’s picture

jcfiala’s picture

Oh, that's great - I'm reading through now, although so far I'd pieced this together from looking at other bits of code. Glad to see I was getting it right so far.

kwinters’s picture

I'm the maintainer for uc_payflowpro and I've opened a separate issue for this in case of code commits: #525222: Integrate with uc_recurring

Jcfiala, have you gotten anywhere significant with the conversion?

For the moment, recurring products are probably OK as-is because I've fixed at least the majority of the bugs in D6 / D5 (including the ones Matthew listed above), but eventually I'd still like to start using this module instead of the current custom tables and such.

However, there are a couple of issues with the way these two modules are set up that may make it difficult to integrate with.

PayFlow provides a service / data structure where it can contain recurring "profiles" inside of their interface and database. If you create a profile using that feature, you don't have to worry about saving credit card info locally or anything like that. I can't really tell if that would mesh well with this module, so I may need to add both a hook for uc_recurring to handle the recurring payments as standard charges and also support actual "profiles" depending on how the admin wants to use it.

The biggest thing I'm worried about is the payment intervals, which is entirely different than the ones provided by uc_recurring. PayFlow supports 8 specific recurring periods (weekly, every 2/4 weeks, semi-monthly, monthly, every 3/6 months, yearly) and anything other than that won't work. I'm not sure what an appropriate way to handle that would be.

Also, you might be interested in the code from function _uc_pfp_calc_start_date in uc_payflowpro -- it handles leap years and such in a very predictable way, and has a simpletest as well.

kwinters’s picture

Status: Active » Postponed

Marking this postponed for now, since the original users have gone silent and the other module already has the functionality for recurring invoices.

When the new version of uc_recurring becomes stable I'll revisit this, and hopefully convert the recurring system to use uc_recurring and remove some complexity from uc_payflowpro.

univate’s picture

Status: Postponed » Closed (duplicate)
kwinters’s picture

Assigned: jcfiala » kwinters
Status: Closed (duplicate) » Active

De-duplicating for now, since this is a work in progress and you won't see the conversation in the PFP queue.

So far I've got the recurring profile creation and cancellation working, but I'm unclear on some of the other actions that can be taken on a recurring fee.

1) Customer is issued a new credit card with a new expiration date, etc. and want to maintain service. They need somewhere to type this in and have it propagate to PayFlow. Is there a universal callback for this, or do I have to do it entirely custom? "Edit" appears to be more for admins. uc_securepayau has a custom "Update" link that seems along the right lines.

2) I'm unclear on how the "renewal" process works. The pre-uc_recurring version of PFP worked like this:

* Drupal sends a request to create a recurring profile
* PayPal charges the card automatically, without any special action from Drupal (and would keep charging the card even if the Drupal site were deleted).
* Cron periodically requests updates from PayPal, updates local copy to reflect edits and cancellations, and adds an order comment if money was charged since last cron run

I don't know how that's supposed to work in uc_recurring at a high level. The uc_recurring cron should definitely not actually charge the cards, though.

Any guidance you can provide would be appreciated. Thanks.

univate’s picture

1) This is what the 'menu' item in the hook_recurring_info() defines the various operations that you want users to be able to perform on a recurring fee. So you just need to add a menu callback for your credit card update function. I would suggest just following how uc_securepay does this.

2) uc_recurring is designed to only take care of renewals if it is triggering them. If a gateway wants to take care of the renewals then its up to that gateway module to call the required functions to let uc_recurring know that a renewal has taken place. This is how the paypal code works with uc_recurring on the IPN callbacks. So in this gateway you are probably going to have to setup a cron function that still checks the state of things and calls the uc_recurring function to make a renewal or cancellation happen.

kwinters’s picture

Thanks, I'll see what I can pull from the normal Paypal module for #2.

kwinters’s picture

Looked into this further, and I've got some more questions.

Should I build off of uc_recurring_hosted? It seems like it's designed to provide some additional structure for external recurring profiles, but it's hard to tell from the outside whether it will be possible / useful to hook into that for PFP.

Should I set 'own handler' => TRUE? That is what all 3 of the "hosted" interfaces do, but I'm unsure of the logic that goes into it and what the consequences are (API docs are very brief on the topic).

Is this the right code flow? The cron calls uc_recurring_renew($fee), which calls the renew function defined in hook_recurring_info(), which in turn modifies the row / fee as needed.

Do I have to do anything special to make sure next_charge, remaining_intervals, charged_intervals, or attempts gets updated correctly in this setup? I'm not sure whether I'll be bypassing the normal logic for that.

What's the correct way to see if a fee has already been recorded in the cron? next_charge <= charge date returned from the gateway? Or maybe create a new table with that info? The cron needs to touch nearly all recurring fees daily, and since it's an expensive request I don't want to check any one recurring profile more than once a day. I expect this isn't something built into the uc_recurring core, but I wanted to double-check before reinventing.

Thanks again.

kwinters’s picture

Univate, I just wanted to check in and make sure you had seen this. If you're too busy that's fine, but let me know and I'll start experimenting myself. The end result will still probably be better with some insider knowledge, though. Thanks.

univate’s picture

uc_recurring_hosted is a module to put code for ubercarts core gateways, there is nothing special about the module, other then I didn't want that code in uc_recurring as its gateway specific.

"own handler" is just a flag to tell uc_recurring that you will be handling the renewals and not to automatically attempt renews. This is required by gateways like Paypal WPS that do all the recurring stuff external to your site and lets your site know via IPN when renewals have happened.

If you want uc_recurring to call you renew function (which happens on cron runs) then "own handler" should be FALSE.

If uc_recurring is handling renewals then you don't have to update any variables all you need to do in your renew callback function is call payment_enter if the payment has been received. If you handling renewals yourself (own handler) then you should call the uc_recurring_renew($fee) function when the renewal needs to happen and it will update everything for you.

If the next_charge is less then the time now and the number of intervals is not 0 (-1 means unlimited) then it means its currently due.

If you feel you need changes to uc_recurring to help make the gateway work better let me know so we can expand the capabilities of uc_recurring.

jayakrishnanj’s picture

Priority: Normal » Critical

I was Using uc_recurring module, But got stuck when i was unable to make it work with credit card(WPP) with recurring products (forgot the multiple Recurring products.).

So thought of using payflow pro...I have created a empty featured product and added recurring through "admin/store/settings/uc_recurring/schedules" interface, but no use. I am not able to see the profiles created for anyone. I have purchased the recurring product two times through creditcard with Card no :4(15)1's and some expiry year, status of the order is "completed". but there is no Profile.

Guys please help me out.

kwinters’s picture

Priority: Critical » Normal

Last post was cross-posted elsewhere and is a support request, reverting.

univate’s picture

Status: Active » Closed (duplicate)