Had a number of recurring payments fail due to expired credit cards and noticed that a new order was created each time a payment request was processed. After updating the bad card numbers the payments went through on the first retry but a new order was created and the previous failed order was left in status "pending". I think that payment retry attempts should not create a new order; they should modify the last order that failed.

I have added code that stores $fee->data['retry_order_id'] when a payment is not successfully processed. When CRON executes uc_recurring_renew() this value is checked to see if a new order should be created or if an existing order can be used to retry the payment. If the retry attempt is successful then $fee->data['retry_order_id'] is unset.

I personally think that this should be the standard operating procedure. If anyone disagrees I would be willing to add extra code to make this an option in the recurring settings form.

Patch is generated against dev version date 2011-02-25

CommentFileSizeAuthor
#3 uc_recurring-6.x-2.x-dev_retry_2.patch2.11 KBtinker
uc_recurring-6.x-2.x-dev_retry.patch2.54 KBtinker

Comments

tinker’s picture

tinker commented

This patch is working well on a production site for over a month. Any one have input on this feature? I would love for this to be included in the next release.

univate’s picture

univate commented

I am interested in functionality like this. Although I had a slightly different idea - #1026524: Separate payment processing from the recurring order generation

Also the patch would need to have all those extra comments removed before it can go in. The whole point of patches and a version control system is to tell you what lines are getting added and removed so theres no need to add all those comments.

tinker’s picture

tinker commented
Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new uc_recurring-6.x-2.x-dev_retry_2.patch2.11 KB

Trying to clear out old items from my issue queue. This feature is working successfully on a live since Feb 2011. The site has received over $1M gross most of which came through recurring payments without any issues. So I think I can say that it has been reviewed and tested. This patch provides and immediate fix to a major issue: an order should not get created on each retry attempt. It is a huge PITA to clear out hundreds of pending orders that go nowhere and this patch fixes that problem.

I agree with your logic to split out the payment processing from order generation but I see that idea has not moved forward. With the patch in place you could easily add triggers for when an order is created and when a payment retry is attempted because the logic is in there.

I have removed the //comments from the patch and attached the revision. This patch is old pre git format so there may be issue with it applying. Please let me know if further assistance is needed in getting this committed?

rickmanelius’s picture

rickmanelius commented

If accepted, it would be nice to get a D7 port of this as well. I can see if it's an easy patch, but only once merged.

mr.andrey’s picture

mr.andrey commented

subscribing.

univate’s picture

univate commented
Status: Reviewed & tested by the community » Fixed

thanks, committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

interestingaftermath’s picture

interestingaftermath commented

subscribe