Hello,
We're working to set up a subscription service that has a physically shipped product each month, with the option to subscribe for either 3 months or 6 months.
If we charge all 3 months upfront (via product price), and still want to have a new order generated for the following 2 months to for shipping purposes (UPS labels, tracking #'s, etc..) what will happen, code-wise, if the "Recurring Fee Amount" is set to zero dollars? Will uc_recurring attempt to place a charge with auth.net for $0 and possibly result in an error? Or will it skip the charge step and replicate the order for fulfillment?
Also, if a product is checked out with a shipping method such as UPS, where a quote was received and applied to the order total, will that shipping charge be added to the "Recurring Fee Amount" each month? Or can you only have a shipping quote applied once, when they check out?
Thanks so much in advance! :)
Comments
Comment #1
univate commenteduc_recurring will still attempt to renew the order and as you stated probably will fail with the payment gateway if it doesn't allow a $0 payment.
I wonder if it should this be the payment gateways responsibility to check and not change if $0 or if uc_recurring can make that decision to not even both attempting to charge. I would need to think about whether there is anything that relies on a payment being processed.
For shipping the ideas was the uc_recurring would be able to work like any other order and so if shipping was required then it should be added. I'm not sure if that is working at the moment (but the intension is it should work like that).
Comment #2
univate commentedActually at the moment if you set the recurring amount to be 0 then uc_recurring is taking that to mean use the product price, as when you tick that box it stores 0 in that field.
Comment #3
mrmeech commentedHey Univate,
Thanks for your response. :)
Logistically, i guess i'm not sure it makes sense to ever try to submit a charge of $0 to a payment gateway:
- You're running more code than is necessary to complete the process. If all you are trying to do with the zero dollars is skip the charge step, then perhaps skip the charge code (or maybe even the payment processor(s) entirely) and finish the subsequent recurring steps.
- If charging $0 were an accepted practice even just to use a CC to confirm identity, then services that do that wouldn't put a temporary charge of 1 or 2 cents.
- A payment processor may freeze your account for trying to repeatedly charge $0, stating poor code construction or unusual behavior. It makes sense to us, in this situation why you'd have a $0 charge.. but to them i would imagine it's like, "What is going on here? This may be fishy."
Shipping:
When you say, "if shipping was required then it should be added.".. do you mean that the original shipping amt will be used? So, for example: When checking out you got a real-time quote from UPS. When the recurring step happens it will use the amount that was used for shipping during original checkout?
And i'm not sure if this is related, but i did try creating a recurring subscription with a Flat Rate shipping amount and the Fake Recurring Payment Gateway and when it went to recur, it fails and does not make a new order. I'm not sure yet if this is related to having a shipping amount present in the order, or if it's something else. This is what's listed in my "Admin Comments"
10/09/2009
2:07:41 PM 1 Recurring fee 1 added to order.
10/09/2009
2:07:41 PM - Order created through website.
10/10/2009
6:44:13 PM - Error: Recurring fee 1 for product subscription_3_months failed.
Is there anywhere i can go to get more info on the cause of failure?
This is one of the few projects on the internet that's addressing recurring billing/shipping on an open source level, and it's awesome! Looking forward to your response. :)
Comment #4
mrmeech commentedAlso, to not have to wait a day for this to recur, how do i advance the clock? I'm guessing this is burried in the database?
...actually, here's an idea: Adding a "Recurring Time Interval" of "Minute(s)" - If not just being a help to developers, then it would also help folks who are trying to get up and running and want to test things out in an expedited fashion. :)
Comment #5
univate commentedI agree there is no need to send a $0 payment to the gateway, but uc_recurring doesn't actually process the payments its up to each payment gateway module (e.g. uc_authorizenet) to process payments, so my question is should it be up to those modules to handle $0 payments - I wondering if some gateways modules may want to check the card details or do something else on a payment request even if its $0 and they don't send the payment request to the actual gateway?
Other then recurring payments, $0 payments probably don't make much sense anywhere else in ubercart, so they probably haven't been considered much.
Shipping...
I just mean that recurring orders are designed to be exactly the same a normal orders, so of the original order for the product includes shipping then the recurring order should also add on shipping at the time of renewal (I don't know if its actually doing this). My argument here is that if this is not the case then you are not really renewing the same product you have different products any maybe they should be treated as separate product and possible combined in an order using a product kit?
You can change the next_charge field in the database to bring forward when the next renewal will be attempted and then you just need to run cron. Another method is If you enable the test_gateway it provides a 'charge' operation next to the list of recurring fees which you can run to process a renewal straight away.
Comment #6
creslin commentedHi,
Our solution depends on seeing payments for 0.00 being presented to the gateway where we invoke further processing based on this, ranging from checking the card is still valid, billing details still marry to card, update to uc_recurring tables etc.
I agree that management of 0.00 payments should be for the gateway code and not uc_recurring to manage in a different manner.
In many subscription cases I would consider an initial payment of 0.00 is processed as an incentive to subscribe now and begin payments later.
- Cres
Comment #7
mrmeech commentedCres,
Good in-production input. :)
Comment #8
mrmeech commentedSo, is there any easy way around this so that when a product recurs its only function is to duplicate the order without attempting a charge? Or, if nothing else, going for the $0 charge actually at $0 instead of the product price?
Comment #9
phen commentedAn answer to this question would still be of interest! We are billing for monthly usage of our service, and if there is no usage the charge is zero. We take care of modifying the amount with a custom module, but it is still problematic when it is zero. With authorize.net, charges of $0 usually fail... I don't think it is desirable to attempt (and fail) the charges at $0 because after repeated failures the recurring fees expire, which in this case is not desirable. Would be nice to be able to set it up so that $0 recurring fees don't get submitted. I might have to write a patch to make uc_recurring do this...but has anyone else come up with a solution in the meantime?
Comment #10
phen commentedThanks!
Comment #11
mattcasey commentedUsing Authorize.net, I am offering the first month free with a 100% discount coupon on recurring product orders. We also have subscriptions that are paid up front, so this method works on $0.00 renewals too.
I posted my updates to the payment gateway for a related issue here.
Comment #12
bob.hinrichs commentedGood discussion.
1) It sounds like this is something that people want both ways. In our case, we wish the $0 payments to simply return 'true' and skip processing. In other cases, it is clear you would want the order processed as a payment with the payment gateway and have it recorded, payment profile stored, etc. This latter case may not currently be possible in all payment gateways, but sometimes it is configurable on the processor end, and/or new features can be introduced to allow it. In this case, could this be something the administrator controls via a configuration setting? This would be easy to code, see #1475644: $0 fees throw errors upon being processed; need way to bypass $0 fees.
2) I see the logic of handling this in the gateway. On the other hand, I can see some cases where you would want $0 payments to be handled differently depending on whether the case is a recurring fee versus another type of payment.
In other words, whether this is done in the recurring fee module or the payment gateway, we may 'fix' this issue but break someone's system.