Expiring roles and recurring fees for subscriptions

53 replies [Last post]

Submitted on Sat, 10/04/2008 - 01:50

Joined: 09/11/2008

Juice: 163

We recently implemented Ubercart using Authorize.Net and the Recurring Fees functionality for subscriptions. When a user subscribes to the site, he or she will have membership for one month.

In the features for the product, I entered the following:
* Recurring fee amount of $30
* Initial charge to take place in 1 month
* Regular interval to be 1 month

What I don't understand is when someone purchases a subscription, the expiration date for the role seems to be not what I would expect. For example, a purchase made on September 23, 2008 for a one month subscription says the "paid membership" role will expire on November 23, 2008.

Why would this be the case? It should expire on October 23, 2008. I'm assuming this has something to do with the initial charge option? Any help would be appreciated.

#1 Submitted on Mon, 10/06/2008 - 12:47 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

I'll look into it... not entirely sure what's going on. Also, not sure if this is related to what you're doing or not, but there is an inherent limitation in the way recurring fees work alongside of role promotions atm... there is no default way to match one up to the other so that the recurring payment "renews" that role.

Can you verify that you're on UC 1.4?

#2 Submitted on Tue, 10/07/2008 - 07:23 Top View page

benthroop

Joined: 10/06/2008

Juice: 8

Hey Ryan - does that mean that if the user cancels their subscription then it will not demote their role? I'm in the midst of using UC for D6 for the same thing.

OP: I'm a noob with UC - is the problem that the system is counting the beginning of the subscription as 1 month from when they signed up? So they are free until then, then they are charged for a month, so the end is a month after that.

#3 Submitted on Tue, 10/07/2008 - 08:14 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

OP: I'm not sure about that particular issue - we tested on a D5 site and it worked fine, though maybe some issue exists on D6 that we haven't gotten to yet. The role promotion expiration shouldn't assume any sort of trial period.

Regarding subscriptions - you're correct. It doesn't mean it's impossible, because there is a hook getting called when a fee get's cancelled... it's just that right now it doesn't directly tie to other things like role promotions.

#4 Submitted on Wed, 10/08/2008 - 10:34 Top View page

benthroop

Joined: 10/06/2008

Juice: 8

Ryan -

I'm new to the community here. What would be the best way to go about shoring up the site subscription functionality in UC for Drupal 6? Would it be good for me to generate a feature list or is it obvious?

I was about to post in bounties but thought you might have some guidance. I'm totally willing to contract someone to to it and will put the resulting code back to the project. I'm also willing to code myself but would prefer someone who knows what they're doing in UC land.

#5 Submitted on Thu, 10/09/2008 - 08:25 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

benthroop wrote:

I think in general the features of subscriptions are obvious, but the trick is deciding what's already in place, what needs to be rewritten, what needs to be done, and how different pieces of core should work together. I think some of this could be answered without programming knowledge, but that certainly helps.

Quote:

We've worked with other companies to give special attention to parts of core that were lagging for their use. We'd happily chat about sponsored development, or if you can find someone w/ good knowledge of Ubercart who can submit patches that'd be good, too.

#6 Submitted on Thu, 10/09/2008 - 10:35 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Ryan wrote:

Can you verify that you're on UC 1.4?

Yes, I can verify we're on UC 1.4. I'm not sure I understand your comment regarding "no default way to match one up to the other so that the recurring payment 'renews' that role"?

Our process is meant to work as follows --

User pays for a "subscriber" role, which can be one month or three months.
Within 7 days of expiration, a message is sent to the user notifying them their subscription will be automatically renewed unless they take action.
If no action is taken, user credit card is charged again and role is renewed for the same time length of the original subscription. There is no 'promotion' to a different role, just extension of the same role.

Am I describing anything in this process which UC recurring fees cannot handle? Are you saying it is not possible to automatically renew roles, and this requires manual intervention?

This is rather important for me to understand, so please reply as soon as possible.

#7 Submitted on Thu, 10/09/2008 - 10:39 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

One other comment ... we are also using the Subscriptions 2008-04-11 module (http://www.ubercart.org/contrib/2851) along with UC 1.4. Does this make any difference? I thought the purpose of this module was to tie together recurring payments and subscription services.

#8 Submitted on Thu, 11/06/2008 - 16:09 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

No response on this thread? Was hoping to receive some feedback to my comments ...

#9 Submitted on Sat, 11/08/2008 - 07:00 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

An additional point ... there seems to be two separate issues. First, if "Show expirations on user page" is checked in "admin/store/settings/products/edit/features", it does not display on the user's account page. Neither the user or admins can see it.

Second, the 'uc_subscribe' module might also be adding an "Expiring roles" section if it is enabled. This may ultimately be the module which has an incorrect expiration date displayed (note, the date displayed is always one month further into the future, even though the actual expiration date for the role is stored correctly in the database).

#10 Submitted on Sun, 11/09/2008 - 12:35 Top View page

jblank

Joined: 08/25/2008

Juice: 56

I have also been having problems with the subscription module. I have it set up and can purchase a subscription but it does not auto-renew even though the auto-renew item is checked. My understanding is it is supposed to renew and create a new order to be fulfilled (in our case this would work great as it is a monthly physical product we are selling). I would also be willing to contribute to a bounty to shore this up a bit although I am on tight timeline.

#11 Submitted on Mon, 11/17/2008 - 16:43 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

jblank, are you still looking to get this fixed? Of of the major issues is with the Authorize CIM Gateway module (http://www.ubercart.org/contrib/2537).

I spent a significant amount of time testing CIM v0.90 with Ubercart 1.6 in the past week. I talked with Chad, the owner of the CIM module, and he is now aware of the issues. Here is what I found:

In a test environment, I am able to use uc_subscribe and uc_cim together to create auto-renew of subscriptions. When using an Authnet test developer connection, the transactions are processed perfectly every time.
In production, uc_cim is not working at all. It gives failure messages every time. Chad mentioned CIM v0.90 may work with an earlier version of Ubercart, but I cannot downgrade from 1.6 at this point.

When running production transactions, the following error messages were stored in watchdog:

Type:  php
Date:  Saturday, November 15, 2008 - 09:45
Location:  /cart/checkout/review
Referrer:  /cart/checkout/review
Message:  unserialize() expects parameter 1 to be string, array given in /sites/all/modules/ubercart/uc_cim/uc_cim.module on line 380.
Severity:  error

Type: CIM
Date: Saturday, November 15, 2008 - 09:45
Location: /cart/checkout/review
Referrer: /cart/checkout/review
Message:  Customer payment profile could not be created. User: 2923, Error: The transaction was unsuccessful.
Severity:  warning

Type:  uc_cim
Date:  Saturday, November 15, 2008 - 09:45
Location:  /cart/checkout/review
Referrer:  /cart/checkout/review
Message:  CIM Charge failure. Raw gateway response: . Raw CIM response: The transaction was unsuccessful.
Severity:  notice

Type:  uc_payment
Date:  Saturday, November 15, 2008 - 09:45
Location:  /cart/checkout/review
Referrer:  /cart/checkout/review
Message:  Payment failed: Credit card payment failed: The transaction was unsuccessful.
Severity:  warning 

If you are urgently trying to get this fixed let me know and we can see what we can do to make this happen. Thanks.

#12 Submitted on Tue, 11/18/2008 - 03:03 Top View page

jblank

Joined: 08/25/2008

Juice: 56

I was actually using just the test gateway. We were planning to use PayPal Pro for the actual gateway not Authorize.NET

I set up a subscription as a test that was supposed to expire after 5 minutes but automatically renew. I was running cron but the subscription just expired it did not renew and create a new order as I thought it was supposed to.

We are hoping to get this figured out this week if possible.

Josh

#13 Submitted on Wed, 11/19/2008 - 13:16 Top View page

torgosPizza

Joined: 08/14/2007

Juice: 3864

I don't think subscriptions works with anything except the credit module yet? Ryan, has that changed lately? I've been busy so I haven't been keeping up as much as I should

Help directly fund development: Donate via PayPal!

#14 Submitted on Wed, 11/19/2008 - 13:42 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

Well, there's some integration for recurring fees and Authorize.Net nowadays, but my understanding of this thread was that some contributed module wasn't functioning properly.

#15 Submitted on Wed, 11/19/2008 - 21:54 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

There are multiple things going on here ... we've been doing significant testing trying to find some method of a "subscription" model with auto-renew capabilities. Our testing has involved CIM (v0.83, then v0.90) with uc_subscribe (2008-04-11 version), standard Authnet gateway (1.3-1.6) with uc_subscribe (2008-04-11), and uc_recurring (1.4-1.6) with the standard Authnet gateway (1.4-1.6). Here is what we have found:

In "Test Developer" mode, CIM (v0.90) works perfectly with uc_subscribe (2008-04-11), using UC 1.6. When switched over to production, we get the error messages above and it fails every time. We have previously run CIM v0.83 with uc_subscribe (2008-04-11) and UC 1.3, and we did get it to work successfully in a production environment.
uc_subscribe can process transactions with the standard Authnet gateway (1.3-1.6), but cannot perform auto-renews. If a user selects the "auto-renew" checkbox under their subscription options, cron will run but the transaction is not processed. Makes sense, since there would be no recurring transaction information stored locally with this method.
uc_recurring (1.6) with the standard Authnet gateway (1.6) seems as though it's becoming a more viable option since the "cancel" link now works! The Recurring fees "cancel" link on the user profile page did not work until 1.6, we had a hard time justifying releasing it to customers. The one thing about uc_recurring is even with uc_roles installed, it's not as flexible with start/end date manipulation as is uc_subscribe. Obviously I can get to the right date by applying the +/- role expiration option, but would be much better if we could pick specific dates.

So different approaches exist to creating "recurring fees" ... either someone can use uc_subscribe/CIM (when it's working), or they can use uc_recurring/uc_roles/Authnet standard gateway (local storage of encrypted credit card data), and I'm guessing down the road uc_recurring/uc_roles/CIM would be an option.

I really need some understanding on the vision of where this is all headed. Is uc_subscribe functionality going to be pulled into uc_recurring/uc_roles? Will CIM just become another option within Authnet payment core?

My opinion right now is the transaction processing of Authnet standard is *far* more solid than CIM, while the functionality options of uc_subscribe are *slightly* more flexible than uc_recurring/uc_roles.

I want to know which horse I should hitch my wagon to so we're not having to completely rebuild this at some point in the future. Thanks.

#16 Submitted on Wed, 11/19/2008 - 22:07 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

FYI, we also have figured out what was causing the initial date problem. The previous developer of the site, when creating products, had installed both uc_subscribe and uc_roles.

Under the product features sub-tab, it is possible to add multiple features on the product. The developer had added a Role assignment for 6 months, and *then* he also added a "Subscription: Generic subscription" option for 6 months.

This made the role expiration additive ... therefore someone who had wanted to purchase a 6 month subscription actually got a total of 12. The uc_subscribe "Product subscription" tab on a user's profile would show the correct 6 month duration, but the "Expiring roles" area on the user profile was showing 12 months duration (6 months from uc_subscribe + 6 months from uc_roles).

If both uc_subscribe and uc_roles are going to exist separately, there needs to be something in place to ensure users do not accidentally add another feature which can extend the length of a role.

#17 Submitted on Thu, 11/20/2008 - 10:22 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

Thanks so much for taking the time to post this info up. I have quite a bit to tackle this morning, but I'm bookmarking your post so I can respond to it in full either this afternoon or tomorrow. Just wanted to let you know.

#18 Submitted on Thu, 11/20/2008 - 21:07 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

You're welcome. I wanted to make one further caveat to what I said previously. I made the comment, "In 'Test Developer' mode, CIM (v0.90) works perfectly with uc_subscribe (2008-04-11)".

I wanted to add that it was necessary for me to create a couple of Workflow-ng business rules to really get it to work as I fully expected. The base rules come included with the uc_subscribe module. The two rules I created from these base rules are "Site subscription has begun" and "Site subscription has expired":

Rule: Site subscription has begun

Invoked on event: New subscription has been registered
Conditions: User has role(s); User to test: Customer; Select role(s): Authenticated
Actions: Add user role; User whose roles should be changed: Customer; Select role(s): Subscriber

Rule: Site subscription has expired

Invoked on event: Subscription has expired
Conditions: User has role(s); User to test: Customer; Select role(s): Subscriber
Actions: Remove user role; User whose roles should be changed: Customer; Select role(s): Subscriber
Second Action: Execute Custom PHP Code -- we give subscribers access to several "paid only" Drupal Simplenews newsletters. When the subscription ends, we need to ensure the user no longer has access to the newsletters. We run through some PHP code to delete records in the database.

When using the uc_recurring/uc_roles modules in place of uc_subscribe, I was able to replicate the same type of rules by pointing to the "order" rather than the "customer" data.

#19 Submitted on Thu, 11/20/2008 - 23:28 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

I'll add one more comment regarding uc_recurring ... it does a great job if we're always on a model where a user renews their order at a specific time each month (or year, etc.).

However we have a number of users who either want to renew their subscriptions early (beneficial to us because it gets more revenue in the door sooner rather than waiting for their recurring fee to come due), or they wish to upgrade to a longer term plan (instead of buying our 1 month subscription product, they want to upgrade to 3 months), prior to the existing subscription coming due.

The uc_subscribe module does some of this (with the 'renew' and 'reorder' options), but is incomplete. It doesn't allow for mid-subscription upgrades. The uc_recurring / uc_roles combination doesn't really do it at all as far as I can see. Having insight into the long-term goals for these things would be extremely helpful. Thanks.

#20 Submitted on Fri, 11/21/2008 - 08:01 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Ok, while I'm looking at things, let me add one more comment that references back to the original post. In this scenario, I'm using uc_recurring and uc_roles, with standard Ubercart AIM gateway.

As a test, I just created a simple product called "One Month Extension". I gave it a title, a price, and saved it. Then edited the "Features" tab of the product, and added a "Role assignment" (uc_roles) as a feature. The role assignment has the following items:

SKU: 8 (SKU of the product)
Role: Subscriber (unique user role)
Expiration: 1 month(s)
Shippable: No
Multiply by Quantity: Yes

No recurring fee, nothing else ... just a one month subscription. Fairly straightforward, eh? I then make a test purchase for one month, only have one of them in the shopping cart (so multiply by quantity is not an issue), complete the purchase, and the transaction adds TWO months to my role expiration.

Why? What is causing the role assignment to be doubled? If I purchase a three month subscription, it adds SIX months to my role expiration. Frustrating ...

#21 Submitted on Fri, 11/21/2008 - 22:59 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Ryan -- Getting any closer to some thoughts? Our client is getting a bit concerned with the direction of the product, and I really need to reassure that we're on the right path.

#22 Submitted on Sat, 11/22/2008 - 15:39 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Well since I'm not hearing anything about these issues, I'm starting to do some troubleshooting. I have placed some database inserts in the _get_expiration_date function in uc_roles.module, so I can see what's being written to the DB.

When I process a transaction, the function is called twice, when I'm sure it should only be called once. In the database, I get the following two writes for a one month subscription:

+1 month 1227385170 (Nov 22, 2008)
+1 month 1229977170 (Dec 22, 2008)

So the routine in uc_roles adds one month to today's date (Nov 22) as it should, *then* it returns and adds another month to Dec 22, getting us the end result of Jan 22 as the role expiration date.

Obviously something wrong here!

#23 Submitted on Sat, 11/22/2008 - 17:01 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Ok starting to make more headway ... I see what is happening. The product I am purchasing has a "Role assignment" of one month, and it has a "Recurring fee" which will happen one month from now, and then each successive month.

The comments generated on the order tell the story. The customer is granted the user role of "subscriber" from the role assignment (+1 month), then when the recurring fee is created, it also adds a month!

Why would it work this way? If a recurring fee is set to happen one month from now, and then each successive month, the user should not receive site access until the first recurring fee payment is made. See the information below I copied from the order:

11/22/2008
4:52:39 PM 2923 Customer granted user role subscriber.
11/22/2008
4:52:39 PM - Recurring fee 254 added to order.
11/22/2008
4:52:39 PM 2923 Customer user role subscriber renewed.
11/22/2008
4:52:39 PM - Order created through website.

#24 Submitted on Sat, 11/22/2008 - 18:06 Top View page

ryanschmidt

Joined: 11/17/2008

Juice: 123

ron_s, any update on this project? I am creating a subscription based newsletter as well. Your input has been very helpful to me.

#25 Submitted on Sun, 11/23/2008 - 03:38 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

A bit more information. I think the way role assignments and recurring fees are currently designed, they are not compatible with one another.

When I go to the Features sub-tab on my product, I currently have two features:

Role assignment: Role - subscriber; Expiration - 1 month
Recurring fee: When product is purchased, add a fee for $20 charged first after 1 months and every 1 months after that.

But (and this is a huge "but"), on the recurring fee edit screen under the "Initial Charge" it says the following: "Specify the time to wait to start charging the recurring fee after checkout. Remember the product price will be charged at the time of checkout."

I believe the "product price will be charged at the time of checkout" is the killer statement. The role assignment attempts to add a role on the account, and then recurring fee attempts to do the same.

This intuitively doesn't work the way it should, and I think it's a fundamental problem with the module. I need further guidance from others.

#26 Submitted on Sun, 11/23/2008 - 08:40 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

I don't have time to research this any more at the moment, but here is some more information.

The problem is associated with the uc_roles_order function in the uc_roles.module file. What happens with a new order is it first completes the "else" part of the "if (!is_null($existing_role->expiration))" conditional, to grant a user the role for a given amount of time.

Then shortly thereafter, the uc_roles_order function is run again, this time the "if (!is_null($existing_role->expiration))" part of the conditional. This renews the expiration time on the order, effectively doubling the role expiration length.

What doesn't make sense is it seems as though the uc_roles_order function is being called twice. I would have expected it is only being called once as the order is set to "Completed". However when I look at the Order Log, maybe this has something to do with it:

Sun, 11/23/2008 - 09:17 2923 Order status changed from In checkout to Completed.
Sun, 11/23/2008 - 09:17 2923 Order status changed from Completed to Completed.

Seems like maybe the hook_order is being fired twice, once for "In checkout to Completed", and a second for "Completed to Completed". If this is the case, then it might be that it runs through uc_roles_order a second time. Since the expiration date is already set, it automatically is going to treat it as a renewal and add the time to the end of the role expiration.

#27 Submitted on Sun, 11/23/2008 - 22:20 Top View page

ryanschmidt

Joined: 11/17/2008

Juice: 123

It would be great to get some help in this thread.

I guess a simple way of putting all of this is: How do you setup reoccurring subscriptions in Ubercart that grant access roles on purchase and take them away on subscription expiration?

#28 Submitted on Mon, 11/24/2008 - 14:04 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

ryanschmidt wrote:

How do you setup reoccurring subscriptions in Ubercart that grant access roles on purchase and take them away on subscription expiration?

I think ron_s is getting at this... the gist of it is, you can't with core alone. This is an unfortunate side effect of the roles module being developed 6 months before the recurring module was actually put in core. So what we have are two systems that should work together but don't. I'll respond more to ron_s's posts directly here in a bit, but basically what you can do is either accommodate this in a custom recurring fee handler or work through an existing one. For example, I integrated Auth.Net's ARB service in the core Auth.Net module. I invoke a hook whenever an ARB payment is received, so a custom module could implement that hook and update a user's roles accordingly.

However, as is apparent in this thread, core really really needs to have a way to associate a role promotion with a recurring fee. It also needs to better understand what to do when a payment fails... when do you decide a payment is late and should reactivate a previous role w/ an extension or a payment should be considered as repurchasing an expired role? Perhaps ron_s's idea of creating a new order when a recurring payment comes in could solve this.

@ron_s - regarding your bug from uc_roles_order(), I fixed a similar bug in the files module but didn't think to check this module (they were written by the same developer). I'm going to go do that right now and will come back to this thread. I'm running behind on a project and need to devote a few hours to it atm.

fwiw, associating roles to recurring fees is something that is on my radar and will be possible in the 2.0 release.

#29 Submitted on Sat, 02/07/2009 - 14:34 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Ryan, earlier in this thread (back in November) you said this:

Ryan wrote:

@ron_s - regarding your bug from uc_roles_order(), I fixed a similar bug in the files module but didn't think to check this module (they were written by the same developer). I'm going to go do that right now and will come back to this thread. I'm running behind on a project and need to devote a few hours to it atm.

I never heard back from you. What is the status? Did this get fixed in 1.7?

#30 Submitted on Tue, 02/17/2009 - 14:48 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

Hey Ron, sorry for my lag time. I did get the fix in for the 1.7 release. I've also got another developer who's been focusing on understanding and cleaning up those modules, esp. on the 2.x branch.

#31 Submitted on Thu, 03/12/2009 - 05:14 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Ryan wrote:

Hey Ron, sorry for my lag time. I did get the fix in for the 1.7 release. I've also got another developer who's been focusing on understanding and cleaning up those modules, esp. on the 2.x branch.

Hey Ryan, I hate to say it, but this issue did not get fixed in 1.7. We're in the process of reviewing 1.7 in the test environment, and unfortunately it's more of the same. I see this as a rather critical problem, and effectively makes the uc_roles module unusable.

Here is an example of what I did:

Created a new product called "One Month Subscription".
Added a feature to the product of "Role assignment"; set the role assignment length to be "1 Month" for the role name of "Subscriber".
Proceeded through the normal checkout process, purchasing a one month subscription on today, March 12, 2009.
Order completes successfully.
Go to My Account page, and it says I have a new Expiring role that will expire on MAY 12, 2009. Not "April" as it should be, but MAY. It *always* doubles the length of the role expiration.

What is the plan for getting this fixed? As I said, the uc_roles module is pretty much unusable given this issue.

#32 Submitted on Thu, 03/12/2009 - 06:23 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

I want to reiterate what I said back in post #27 ... the issue is the uc_roles_order function in uc_roles.module is getting called twice. The first time it is as a new order, therefore $existing_role->expiration is null and the customer is granted the role for the first time.

The second time through the expiration date has already been set, so $existing_role->expiration is NOT null and it notes that this is a role renewal. Therefore you end up with orders that look like this:

03/12/2009
6:14:05 AM 1 Authorization and capture
ACCEPTED: This transaction has been approved.
03/12/2009
6:14:06 AM 1 Customer granted user role subscriber.
03/12/2009
6:14:07 AM 1 Customer user role subscriber renewed.
03/12/2009
6:14:07 AM - Order created through website.

It should not be performing the "renewal" step. This is why we're having role durations that are doubled in length.

#33 Submitted on Fri, 03/13/2009 - 01:39 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Sorry Ryan, I was wrong. The 5.x-1.7 version does fix the issue (so far ... still some more testing to do). I was troubleshooting uc_roles.module, then uc_order.module, and finally uc_cart.module. From this review I was able to connect the dots and see that the reason why it was executing the code twice was because of Workflow.

One of the core workflows provided by Ubercart had been modified a long, long time ago (before I was involved), and the action was to set the order to "Completed". Therefore the order was running through its "Completed" steps twice -- once for the core workflow, and a second time for the secondary workflow that had been modified.

I still haven't run this with production Authnet, so that will be the true test. Previously it ran successfully in test but failed when we migrated to production. I'll give an update once we have performed this step.

#34 Submitted on Wed, 03/25/2009 - 09:53 Top View page

rdtechteam

Joined: 03/25/2009

Juice: 2

So in 5.x-1.7, are there instructions for making this work that i missed? I want endusers to be able to set up recurring subscriptions based on whether they continue to pay recurring fees. If they cancel their fees, their subscription to a role should cancel. This is functional? Anyone have a tutorial or step-by-step instructions already done.

#35 Submitted on Mon, 11/24/2008 - 15:27 Top View page

webmasterkai

Joined: 08/09/2007

Juice: 229

I'm not sure how I missed this thread but I'll jump in now. I am now responsible for uc_subscriptions and I have updates for uc_subscriptions that need to be posted. I'd like to see uc_subscriptions work its way into core and I'm willing to do the code. uc_subscriptions works with workflow_ng. If you want a user to have a role when the subscription is created create a workflow_ng event for that. If you want the role removed when the subscription is canceled or expires create a workflow_ng event for that. uc_roles isn't required. If a subscription is renewed it will add the amount of time to the expiration, regardless of when it happens. I'm not sure why that wouldn't be working.

Biodiesel * (ubercart + drupal) = Sundays Energy

#36 Submitted on Mon, 11/24/2008 - 17:30 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

webmasterkai wrote:

If you want a user to have a role when the subscription is created create a workflow_ng event for that. If you want the role removed when the subscription is canceled or expires create a workflow_ng event for that. uc_roles isn't required. If a subscription is renewed it will add the amount of time to the expiration, regardless of when it happens. I'm not sure why that wouldn't be working.

I couldn't agree with you more, I don't understand why it's not always working. I tried to use the "Generic subscription" feature on its own on the product. I found that at times the role got applied, other times the order was processed and no role was given. Even better yet (and this one was a killer on the site for several months), we saw people who's orders were "Pending", or that were sent to Authnet and came back with a "Declined" credit card, and the user was given access!

We had a woman a couple of months ago who swore up and down that she should continue to have her access to the site because she paid for an annual subscription. Our records clearly show she *attempted* to subscribe, but the credit card number was invalid. The "Generic subscription" feature gave her the subscription role even though it was not supposed to do so.

I've just run into a bunch of situations like this where uc_subscriptions doesn't always work as intended. FYI, there also needs to be some type of rule in place that does not allow users to create another order if they are already a subscriber. I've done some things in Drupal to block access to subscription and order pages if someone is a paid subscriber, but this is problematic from what I'm about to write in the next post ...

#37 Submitted on Mon, 11/24/2008 - 18:03 Top View page

ron_s

Joined: 09/11/2008

Juice: 163

Ok all of this discussion about roles, recurring fees, and subscription functionality has brought to light another problem which I consider to be fairly serious.

Right now, no matter which approach is used, there is no good method for a user to upgrade to a longer subscription term. For example, someone is on a one month subscription, is a few days before expiration, and wishes to renew but this time with the three month product. Let's look at how this works in each scenario:

uc_subscriptions: With this approach, a user has a "Renew" link on the "Product subscriptions" tab. If they click renew, it just adds the same term they already had. So if they had one month, they are adding another one month term. This really shoots us in the foot in regards to revenue generation, when we've got customers willing to spend more money more quickly, but have no method for capturing this.
The only options available to users with the uc_subscriptions approach is as follows:
1. Wait until the subscription expires, then purchase a longer-term subscription.
2. Go through the renew process, but rather than "Checkout", click the "Shopping Cart" link at the top of the page. This allows a user to add multiples of any given product in their shopping cart. For example a user could modify the order to be three 1-month subscriptions. However without a discount module installed, there is no easy way to credit users for buying longer term subscriptions.
A couple of nice features of uc_subscriptions are users can toggle autorenew on and off as they wish, and the subscription expiration date is not set in stone. If a subscription is renewed, the expiration date is automatically extended and updated. With uc_recurring / uc_roles, an invoice is immediately created for the next month, causing a lock in of the "expiration date". Also there is no notion of an autorenew on/off switch. Either a recurring fee is listed in the future, or it is canceled and no longer exists.
uc_recurring / uc_roles: The options available to users with the uc_recurring / uc_roles approach is as follows:
1. Out of the box, the uc_recurring / uc_roles method is rigid when it comes to extensions. Either a user can renew on the current product, or he/she can cancel the product and start over again by purchasing a longer term.
2. One workaround might be to build a set of "subscription extension" products for users. These products would have a role assignment for a given length of time, but no recurring fee. It would be a one-time charge which adds to the current subscription timeline. The issue is the code should be smart enough to say, "if a user already has a subscription, and adds an extension, then automatically update the upcoming recurring fee due date".

I want to make sure it is very clear the problem this causes, so let me provide an example. Say a user purchases a recurring fee subscription which adds a $20 fee on the 27th of each month. On December 24, 2008, the user decides he wants to upgrade to a three month subscription. We can offer a "subscription extension" product for him to purchase, which immediately adds three months to his expiration date. His role expiration is now set to March 27, 2009. However, there is *no* update to the recurring fee. On the account page, it still says the next recurring fee due on December 27. If a user gets charged on 12/27 for another one month renewal, the immediate reaction will be, I just bought three months!

We need to have some reconciliation on all of this. I think two of the most common needs for any subscription site will be the ability of users to control their auto-renew status, and to upgrade/downgrade their accounts ... and in turn have the system understand what implications this has for role expiration dates.

#38 Submitted on Mon, 11/24/2008 - 18:12 Top View page

ryanschmidt

Joined: 11/17/2008

Juice: 123

ron_s wrote:

ron_s, it's like I write that post myself! I am having the exact same issues. Luckily, I am still in the testing phases of the site so I do not have to worry about complaining customers just yet. I have noticed that the roles are assigned sometimes and then not assigned others. Sometimes the admin comments on the order will say "subscription not registered" or something like that and other times it will work perfectly.

I will look into the Authorize.net solution, thanks Ryan. I would really love to offer paypal to my subscribers though. It almost seems like it should be standard this day in age.

#39 Submitted on Mon, 11/24/2008 - 21:33 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

ryanschmidt wrote:

I would really love to offer paypal to my subscribers though. It almost seems like it should be standard this day in age.

There are actually a couple of funding possibilities to sponsor PayPal support in core that I need to follow up on. I should almost just make it a Chip In widget and then get to work once it's full.

#40 Submitted on Tue, 11/25/2008 - 11:36 Top View page

webmasterkai

Joined: 08/09/2007

Juice: 229

Paypal is working with uc_subscriptions via this module http://www.ubercart.org/contrib/4218

The ability to renew subscription and change the renewed duration is something being working on right now. We are changing the logic of a subscription a bit to work with just about anything. For example a customer might buy a monthly retainer of 3 customer support hours. The customer will be able to buy more hours and apply it to the subscription and/or buy more time. You could also sell a subscription of simple 3 hours of support time. The subscription would expire or renew when those three hours are used. Another example is hosting. Because we offer monthly hosting many customer buy one month and want to upgrade both hosting package and length (usually to one year). However, if the subscription expires the hosting account is suspended, so we are creating a way to apply an order to a subscription. Also in development is a way to extend subscription expirations beyond simply buying more. In our tests we are creating ways for hosting customers to link to us and have their hosting expiration extended per click. Or referrals, or blog posts, or answering a support request in the forum...

uc_subscriptions generic subscription doesn't grant the roles. The role is granted using workflow_ng. You can add another condition like "order ballance = 0" if users are granted roles without payment. Subscriptions are registered on a specific order status. If the set to activate status is set to
pending all subscriptions will be registered, paid or not.

Biodiesel * (ubercart + drupal) = Sundays Energy

#41 Submitted on Thu, 10/09/2008 - 10:59 Top View page

jserulneck

Joined: 10/08/2008

Juice: 12

Hey,

Does anyone know how to setup autorenewal on Ubercart? Also, how are subscriptions sold? Is it with the purchase of the digital file? I'm looking to sell subscriptions to the entire site.

Thanks!

Justin

#42 Submitted on Mon, 11/24/2008 - 14:17 Top View page

ryanschmidt

Joined: 11/17/2008

Juice: 123

This is horrible news. I am going to have to rethink my entire project. I have a deadline of January to have a full subscription based newsletter site up and running.

*Back to the drawing board*

#43 Submitted on Mon, 11/24/2008 - 14:42 Top View page

Ryan

Joined: 08/07/2007

Juice: 15046

I mean... I'm not sure it requires rethinking your entire project. Like I said, you can create your own recurring fee handler or work through Authorize.Net and make sure roles stay active. I'm not talking weeks of development work here... maybe just a couple hours to write the little bit o' code and do some testing. I'm working on a solution right now that uses the Auth.Net system, and as soon as it's solid I can provide more info... Don't wanna derail this thread too much.

#44 Submitted on Mon, 11/24/2008 - 14:51 Top View page

benthroop

Joined: 10/06/2008

Juice: 8

ron_s and Ryan -

Thanks for your attention on this! I'm really interested in a solution and at some point in the very near future I may be able to contribute as well. I too have a January deadline.

#45 Submitted on Sat, 12/06/2008 - 12:20 Top View page

jaykali@drupal.org

Joined: 12/06/2008

Juice: 31

I've been working on a module for sometime that uses Authorize ARB and deals with role promotion:

http://drupal.org/project/role_subscription

I decided to build it outside the scope of ubercart initially bc I thought recurring billing (not invoicing) wouldn't integrate well with ubercart which essentially deals with single payments (and recurring payments).

Anywho I suppose I'm wrong bc I see Authorize ARB integration and recurring billing in Ubercart, now I'm thinking I may need to rethink this bc if all I need to worry ab is role promotion then maybe that's the way I want to go as Ubercart is much more feature rich and better supported than my more barebones recurring billing module.

#46 Submitted on Tue, 12/09/2008 - 15:51 Top View page

ryanschmidt

Joined: 11/17/2008

Juice: 123

jaykali@drupal.org wrote:

I've been working on a module for sometime that uses Authorize ARB and deals with role promotion:

http://drupal.org/project/role_subscription

This sounds interesting. Any updates on this thread? It's about time for me to button this shopping cart, role promotion, subscription service up.

#47 Submitted on Thu, 12/11/2008 - 20:54 Top View page

jaykali@drupal.org

Joined: 12/06/2008

Juice: 31

it seems to do what i set up my module to do which is grant roles with a certain type of subscription. i did some tests last week and sure enough it granted me a role based on a subscription, it will be difficult to test renewals/cancellations/etc to see if it removes expired/canceled roles correctly or if that's something I'll have to code. i also wonder ab updating the prices of subscriptions if it has any mechanism for updating existing subscriptions in authorize which is one of the things i did in my module. it's tricky bc it means you have to make potentially a bunch of API calls when you update a subscriptions terms/price and some terms you can't change in ARB once a subscription is created. that is something as well i suppose i could code. with any subscription you know there are going to be price changes from time to time, so that has to be handled well.

#48 Submitted on Wed, 02/18/2009 - 06:56 Top View page

mike

Joined: 02/18/2009

Juice: 2

I seem to be in the same boat as everyone else here: I'm trying to set up role based subscriptions using CIM.

I've been looking at uc_recurring and uc_subscription for a few hours now, and there seem to be iproblems in both cases. For the sake of reference, I'm documenting the ones I've run across here:

Problems with uc_subscribe:

uc_subscribe doesn't leverage any of the existing recurring_fee callbacks. Instead, it handles the details of different payment methods internally, which means that it doesn't benefit from any of the ARB code in uc_authorizenet.
Additionally, because it doesn't have specific integration with uc_cim, there's a chance it will bill the wrong CIM profile if a user has defined more than one.

Problems with uc_recurring:

The workflow-ng actions aren't usable out of the box to do subscriptions. uc_recurring is focused on billing a particular number of payments rather than on billing for a particular period of time. For example, the "expire" workflow action fires after the last charge, rather than after a subscription runs out.
The workflow-ng events are triggered in uc_recurring_charge. uc_authorizenet doesn't seem to use this -- the charge is actually being processed by ARB -- which means that the workflow-ng events probably don't work right.
On the other hand, the uc_arb_payment callback could be a reasonable workaround.
It isn't possible to configure a recurring charge to run indefinitely.
uc_authorizenet only supports uc_recurring with ARB.
uc_recurring doesn't create a new order when it charges customers, which is a problem if you're selling subscriptions for a physical product (because it doesn't integrate with the uc_shipping workflow).

For now, I'm using uc_subscribe with uc_cim and fixing problems as I go.

In order to make uc_cim work with current versions of Ubercart, change the block of code at line 378 to:

  $payment_profile_id = $order->cim_ppid;
  if ($data) {
    if (!is_array($data))
      $data = unserialize($data);
    if ($data['ppid'])
      $payment_profile_id = $data['ppid'];
  }

In order to add (some) uc_cim integration to uc_subscribe, add the following code at line 375:

  if ($order->payment_method == 'cim') {
    $obj = db_fetch_object(db_query('SELECT * from {uc_payment_cim} WHERE order_id = %d', $order_id));
    $neworder->cim_ppid = $obj->cim_ppid;
  }

#49 Submitted on Thu, 02/26/2009 - 15:47 Top View page

Axel_Pressbutton

Joined: 11/30/2008

Juice: 96

Hi all,

I am looking for a solution that allows me to have recurring fees for roles on my UC 2.x/D 6.x build

Can anyone tell me the state of play with this for UC 2.x? I'm struggling to get to grips with what I need to get/do to get this working. Is it a case of grabbing uc_subscribe and carrying out the patch to it (which sounds as though it in itself may have issues?)

I currently have a product created that has a role associated to it which expires after one month, I just need to take care of recurring fees and allowing the user to cancel this whenever they wish - I've tried the 'Recurring Product' on the UC 2.x Livetest site...it all seems to work ok but I didn't really get any sense that it would be a recurring charge on the cart/checkout pages and I didn't see an option that allowed me to cancel the subscription.

Many thanks

#50 Submitted on Fri, 04/10/2009 - 20:33 Top View page

univate@drupal.org

Joined: 03/27/2009

Juice: 313

mike wrote:

uc_recurring doesn't create a new order when it charges customers, which is a problem if you're selling subscriptions for a physical product (because it doesn't integrate with the uc_shipping workflow).

Good to see someone agrees with my thoughts - http://www.ubercart.org/forum/ideas_and_suggestions/10133/uc_recurring_t...

I have already created a patch to prove to myself how much better everything would be if a recurring payment created a new order on renewal - at the moment it only works on the test_gateway - http://drupal.org/node/426466

This patch doesn't need to change uc_roles to get uc_recurring playing nice with it, just make a new order when a payment is renewed and the conditional actions takes care of it (I am using the 6.x-2.x series)

	User login
	Log in using OpenID: What is OpenID? Username or e-mail: * Password: * Remember me Log in using OpenID Cancel OpenID login Create new account Request new password

Ubercart

Expiring roles and recurring fees for subscriptions

Navigation

User login