Subscriptions - Add ability to retry failed credit card subscription rebills like Stripe already does...
I use the Stripe Payment Gateway for subscriptions and love the fact that Stripe attempts to rebill a customer up to 4 times before cancelling their subscription.
Stripe Screenshot: http://www.screencast.com/t/Gi72ROXRQjm
This feature dramatically improves our bottom line - saving customers that are very expensive to acquire and generating tons of revenue that would have been lost.
Sometime people's cards just get full - like around the holidays. When given a few days, often the charge will go through successfully.
Would REALLY love to see this feature integrated either into the Subscriptions or Stripe extension. :-)
@michael, Subscriptions does have some dunning already in that it will email customers when a payment fails and request they login to complete payment for the renewal. A little more info here: http://docs.woothemes.com/document/subscriptions/renewal-process/#section-6
You can implement more aggressive dunning using an extension like Follow-up Emails to email the customer a few days later, then another week later.
What Subscriptions doesn't do at the moment is automatically retry a payment after it has failed (this used to be left up to the payment gateway when PayPal was the primary gateway, but now that more advanced gateways, like Stripe, are being used more often, it makes sense to add automatic retries to Subscriptions).
You can keep an eye on the roadmap for Subscriptions here: http://docs.woothemes.com/document/subscriptions/feature-roadmap/
As mentioned there, version 2.0 is scheduled for November and this feature is currently slated for a later release, so it's unlikely it will be available in November.
There are ways to achieve something like this at the moment, but they would require custom development. That said, the code required to do it on a single site tailored to your requirements will be *much* easier to create than building a system which works with as almost any payment gateways and is configurable from the administration interface.
Michael Broukhim commented
This is hugely important. We're evaluating migrating from a custom php site using recurly to Woo + Subscriptions, and "dunning" (re-trying billing automatically), would probably be a dealbreaker if it doesn't exist / isn't easy to implement. We have nearly 20k active subscribers, so doing this manually wouldn't be feasible. Any update on likelihood of this happening by November (or sooner?) ...also, any work-arounds in the meantime?
@tevya yep, this has enough votes that it will definitely be added in future version.
I'm not sure we'll be able to get it done for version 2.0, but if not, it will be in 2.1 which will hopefully be not too long after 2.0 is released.
I'll have to look at implications for physical/virtual products to figure out how to handle the schedule after a retry. I think the most intuitive behaviour will be to keep the original schedule for future payments, rather than updating it based on a success date..
Tevya Washburn commented
While you may be right that the OP somehow boosted the numbers initially (I'm not associated with them in any way), there's a lot of votes now. This would be really helpful. It would also be super nice if the original subscription date could be kept. So if their charge was on June 5th, but something happened and the charge didn't go through on July 5th, but 3 days later the plugin tried again, and it worked, it would still charge again on Aug 5th, not Aug 8th. In my business there's no connection between my store and the services I provide, therefore they just get 3 days free, if the original schedule is not kept.
Dan Baritchi commented
First, thanks for your help and effort on the Subscriptions Importer beta... happy to report we've been fully migrated and operating fully on WooCommerce for some time now.
I wanted to follow up on this thread as it's been a couple months since we migrated to WooCommerce & Subscriptions and have a good feel now of how it's operating, etc.
Most of my input below was focused on the automatic re-try of failed billings, but toward the bottom I included a very brief suggestion for a "retry this payment now" button in the subscriptions listing - alongside "on hold" subscriptions.
It would be really helpful to have that “retry this payment now” button next to failed payments… allowing for an easy manual retry so that we don’t have to go to Stripe directly and do that, thus circumventing the WooCommerce system for that payment...
To explain: currently we regularly re-try failed payments manually. That means going into WooCommerce to find the "on hold" subscriptions, then going to that order to get the customer details, then opening the Stripe website and searching for that customer, then manually attempting to process a payment in the amount last tried by WooCommerce. If that billing attempt succeeds, we manually re-activate the WooCommerce subscription. If it fails, then from the Woo order page, we send off a billing attempted/invoice email to the person. As you can see, the process is more than a little tedious and time consuming, and also error prone. :-)
It would be REALLY nice and a BIG time-saver for this to be one-click option on subscriptions that failed billing... since the information for all of it is already in WooCommerce.
Is this "retry this payment now" button/selection something that could possibly be made available before the full auto retry feature is rolled out?
Thanks for your input Dan. Very comprehensive and immensely valuable for designing the feature.
RE: migration, we have a Subscriptions Importer in beta at the moment. If you'd like test it out, shoot me an email through here: http://brent.io
Dan Baritchi commented
First, very impressed with WooCommerce, and the Subscriptions add-on. It seems to be very solid and “just work”.
We’re attempting to migrate hundreds of live subscription customers from Stripe into WooCommerce, so it’s quite a handful. But I’m very relieved that this idea is looking to be possible, and hoping it’s soon. :-)
Per your comment below, I wanted to provide some additional feedback of what we've seen in the wild on this… our experience has been similar to what Tevya described.
We’ve been using Stripe subscriptions (created via Gravity Forms) for about 1.5 yrs. It’s very common for a subscription payment to fail the 1st, 2nd, or even 3rd time, but eventually go through.
Of course it depends on what schedule you have set up for the retries…
As for how to implement the retries, I think the way Stripe does it is very well thought out, and it works…
I like that they let us (the user) select how many days to wait between retries… so a drop-down for each retry option, with how many days to wait after the last failed retry… then a drop-down for what to finally do after the final retry.
Screenshot of Stripe retry settings: http://www.screencast.com/t/Gi72ROXRQjm
Alternatively you could implement this like the rules in the Newsletter add-on, i.e. add a rule for retry after X number of days, then add another rule, then another. but that seems overly complicated…
I would think the simplest option is indeed similar to how Stripe does it… maybe with 5 drop-downs for “retry after X number of days” or “do nothing” in each one, and a separate drop-down for what to finally do if all failed so far.
For each retry, I would also re-send the same “your rebill attempt failed” email… you could provide a checkbox next to each retry drop-down for whether to send the email, or just a checkbox above the retry drop-downs that applies to all of them for enabling/disabling the email on each retry.
This separate item is far less important, but It would also be nice to have a “retry now” button next to failed payments… allowing for a manual retry so that we don’t have to go to Stripe directly and do that, thus circumventing the WooCommerce system for that payment... I’ve seen this topic in the wordpress support forums as well:
Sometimes a customer payment failed and they contact us and ask us to retry the payment, and it doesn’t make sense to way X days until the next scheduled retry. :-)
Let me know if you need any more feedback or data on what we’ve seen in the wild on this.
Thanks for you input on this Tevya - always appreciated.
It will almost certainly make it in eventually (at least for Stripe and other token based gateways). That's based on the votes for this idea, the feedback I see in support and a general sense of how to provide more utility in the plugin.
Input like that which you provided does help us greatly understand how to best implement it so as to meet your expectations and real-world usage (e.g. even just knowing waiting up to a week to retry is OK).
For others who come to this idea, similar feedback will be greatly appreciated. :)
Tevya Washburn commented
Brent, great extension (one of the very best). I love it.
I can't speak for the 1st 13 votes, but now that I've stumbled across it (a big problem with this kind of voting system--just because people haven't voted, doesn't mean they don't want it, maybe they just haven't found it, or have time to go searching for the one that matches their desires) it's definitely one I could see a lot of people wanting. I'd really like it if I could have it try at least once more at a pre-set number of days later, before sending the client the notice. Or perhaps doing both. Eg. "we're sending you this notice because your payment failed. We will try again in XX days, unless you login to your account and update your payment information before that time." Something like that.
I've personally gone in and re-tried a client's payment manually and had it go through a week or 2 after the initial failure. My experience is that most clients (maybe it's just my clients?) ignore the email notification. Not sure why, but it might be because they assume we will retry it later, and they know funds will be available at that time. They may assume that since most ecommerce places/solutions do automatically retry at least once.
I've just added an FAQ item with more information about this issue as it is reasonably complex: http://docs.woothemes.com/document/subscriptions/faq/#section-68
Note to self - this issue had 13 votes within hours of being created. That means those votes are most likely from the OP and/or people working on the same site, they are not unique votes.