There's a setting in the recurring payment settings form that comes from the 1.x branch to choose the desired workflow for failed processing of recurring fees during checkout:

Action to take if a recurring fee fails to process during checkout:
* Return a failed message and do not complete checkout.
* Return a failed message but complete checkout.
* Show no message and complete checkout.

The problem is this value doesn't seem to be checked any more. Instead, uc_recurring_order() will always halt checkout if recurring fees fail to process... so really it's always the 1st option. Unfortunately, if the payment for the order has already passed, the order is moved to Payment received and will no longer operate as the cart order - so the checkout form appears blank. Users then would resubmit their information and be charged for the order a second time.

Is there a reason this setting is being disregarded now? If I alter my UC Recurring module's weight will that allow it to stop any other payments from processing if recurring fee processing fails?

CommentFileSizeAuthor
#9 fail_on_expiry.patch650 bytesbpirkle

Comments

univate’s picture

univate commented

No reason, this probably fell by the wayside at some point.

rszrama’s picture

rszrama commented

Alrighty, I'll likely see about recovering the functionality in a patch... waiting to hear back from the client on the current fixes.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Subscribe.

cwithout’s picture

cwithout commented

rszrama, have you done any work on this yet? I've checked the code and identified what needs changed. I'm finishing up my project and may have some time to put this patch together if you haven't done it yet.

ksin’s picture

ksin commented

Subscribe.

bpirkle’s picture

bpirkle commented

I'm also seeing this issue. I'm happy to try putting a patch together. I see that a couple of you have already delved into the code and have a pretty good idea what needs to be done. Could one of you give me a brief description of what you learned? That'd save me some investigation time. I can make the changes, test it on my site, and post the .patch file here.

bpirkle’s picture

bpirkle commented

Hrm, just noticed this bug was reported on alpha4. I'm on alpha5, if it makes a difference.

I'm looking in the uc_recurring_order.module file, function "uc_recurring_order_process_order", and I see a "uc_recurring_invoke" call on the fee handler. It looks to me like I could simply zap the "return FALSE" case for that to allow the order to process even in the face of an error creating the recurring fee. Can anyone familiar with the code comment on whether I'm reading this right?

Also, I notice that if all goes well, the "uc_recurring_order_process_order" function returns "$return". I can't find where "$return" is set to anything, so I assume the function is returning an uninitialized value on success. Am I looking at this wrong?

bpirkle’s picture

bpirkle commented

Well, that was close. Seems that, for my store configuration at least, I needed to zap the "return FALSE;" from the similar area of the similar function "uc_recurring_product_process_order" in file uc_recurring_product.module.

I'll run with this change for a while, see if there are any negative consequences, and post a patch if all works out well.

bpirkle’s picture

bpirkle commented
StatusFileSize
new fail_on_expiry.patch650 bytes

Here's the patch. The only functional change is to comment out one single line. (I also added a comment block, to explain what I was doing.)

It does *not* restore the original functionality of the admin options form. It simply causes failed recurring fee processing (usually due to credit card expiry too soon) not to break checkout.

It was also created agains 6.x-2.0-alpha5, not alpha4.