If an ubercart product is set up to create a new account upon checkout, the uc_payflowpro_recurring_profiles table does not get a reference to the user's new id.

We added a custom workflow (wokflow-ng) that, once an order has been placed, takes the order's uid and order-id and updates the table so the recurring profile shows up in the new user's recurring payments page.

The workflow trigger was "Customer completes checkout"

Here is the custom php we added to the workflow action:

db_query("UPDATE {uc_payflowpro_recurring_profiles} SET pfp_uid = %d WHERE order_id = %d", [order:order-uid], [order:order-id]);

hope this helps someone else.

Comments

kwinters’s picture

kwinters commented
Title: New accounts created in checkout don't get tied to the payflowpro profile and can't be viewed by the user after checkout » Automatic New Account Recurring Profile Access
Version: 5.x-1.x-dev » 6.x-1.1-beta1
Component: Miscellaneous » Code
Assigned: Unassigned » kwinters
Status: Active » Patch (to be ported)

The fundamental problem with the old code flow is that recurring profiles were created before the order was final. This resulted in all sorts of inconstancies when a user was created during uc_cart_complete_sale, and although the trigger change in the issue does help some, it doesn't really address the root problem and all possible consequences.

I've fixed up the D6 version to only create the recurring profile after the order is final using a Conditional Action, and released a new beta since this was important.

Since the change was major and I can't really tell whether it will work right in D5, I've marked this issue as patch needs port.

Full list of changes:

* Remove the result argument from uc_payflowpro_recurring_charge_process because it is now only called on success.
* As a side effect, issues with correct result checking before processing the recurring charge have been fixed.
* Added file uc_payflowpro.ca.inc which contains the Conditional Action hooks.
* Add an admin note to the order reflecting the result of the recurring profile save attempt.

I also fixed a typo in the recurring class, but it's not related to the original issue.

Also worth noting: both before and after this patch (and really just inherent to the idea of a recurring charge), it's entirely possible that the recurring profile will either not be created or never be charged any money, or even just end before the full term is up (credit card expiration date changed, etc.) so be aware of this and its implications for a subscription model. So, only base subscription data on periods that have been actually payed for instead of potentially payed for.

kwinters’s picture

kwinters commented
Version: 6.x-1.1-beta1 » 5.x-1.0-beta2

Changed to correct version (the issue is only in D5 now, and will remain so until someone with a D5 install can provide a backport patch).