Home » Forums » Ubercart » Support

uc_recurring.module w/ Manually Created Orders

Submitted by JaceRider on Wed, 05/14/2008 - 09:52
JaceRider

Posts: 32
 Joined: 03/17/2008

Hello,

I've been doing some testing with the uc_recurring.module the past day or two and thus far have found it to be excellent. I did find an issue (I'll list that at the end) but I do have a question.

Does this module currently, or are there plans in the future, to make this work with manually entered orders? I have everything working perfectly if the order is placed from the frontend. However, if an order is placed from the admin, nothing is entered into the recurring_fees table.

As for the small issue I have come across -- if nothing or a 0 is entered into the "Number of billing periods:" field in Product->Edit->Features->Recurring fee... the items appears to be correctly setup to bill indefinitely. However, when that item is purchased and I go to Orders->Recurring Fees I am given a Recurring Fee that does not have a "Next" bill date. This makes it so that a fee is never charged. This is obviously not a huge issue but I'm pretty sure this is not working as intended.

Once again, thanks for another wonderful plugin to a wonderful module.
permalink #1 Fri, 05/23/2008 - 15:52
Ryan

Posts: 4368
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Regarding your two questions here...

  1. I do believe the plan was for it to work w/ manually entered orders, since there's a setting to not process recurring fees in checkout. What I'm doing is adding a checkbox to the order update form on the view page that will let you add the recurring fees to the order. The box will only appear if none of the fees have been added, so for any given order you'll need to make sure you add all the recurring fee products and process them at once. This was simple to add in and a functional bug since it was missing. I'll be committing it shortly. Note: you must be in debug mode to manually process recurring fees b/c of the way CC data gets stored.
  2. The original plan included indefinite billing, but I decided that was a bad idea. Smiling As such, the module no longer accommodates that... it just had some stale messages that I've updated. There were just too many unknowns, esp. regarding expiring credit cards, that I couldn't accommodate with the 1.0 version of the module. I'll try to make this explicit. Maybe this can work in the future. Puzzled

Also, I'm tweaking the module just a little bit so that only the card number and expiration date will be encrypted and stored in normal CC processing mode. Debug mode will store what gets entered during checkout, but this will not be PCI compliant if it includes the card's CVV and therefore is not recommended for live use. I'm sure more can be done to customize what's stored in the future, but I'm trying to change the bare minimum so we can put out the 1.0 release.

permalink #2 Sat, 05/24/2008 - 16:08
torgosPizza

Posts: 1139
 Joined: 08/14/2007
Bug FinderEarly adopter... addicted to alphas.Getting busy with the Ubercode.

The original plan included indefinite billing, but I decided that was a bad idea.

D'oh! That's something we're going to need. Is it easier to write an additional module to accommodate this? Most subscription sites just allow you to keep getting billed until something happens. Most sites I'm a part of will give you a month or two warning that you have a credit card expiring. If the card expires than the subscription goes with it.

Hmm.

--

"Pain don't hurt." - Dalton

Mike Nelson's RiffTrax! www.rifftrax.com

permalink #3 Tue, 05/27/2008 - 09:25
Ryan

Posts: 4368
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Yeah, any recurring fee handler could be written to accommodate indefinite billing. I wouldn't recommend the core recurring handler for every situation anyways, especially when you're using a payment gateway that supports recurring billing. If you're using the core handler, you can always copy it and rename it in a custom module.

I think I was also having trouble figuring out how to handle the data in the DB at the time and someone else mentioned some difficulties w/ indefinite billing in the forums. Some of the trouble stemmed from the fact that the core handler is very basic and won't trap errors returned from the gateway to know what to do on failures.

Anyways, you could have your handler know that if the # of billing periods is set to 999, then treat it as indefinite. Of course, if you're collecting monthly payments, I can't imagine anyone's card is going to last 999 months anyways... well, not to mention their lives. Sticking out tongue