The task being to identify how to handle two params for initial creation of a new subscription at Recurly.
These could be settings options (either in Recurly core or in each plugin module) depending on how user's want to configure the creation of a new subscription in a global sense. In addition these params could be attached to each specific plan (like trial period) rather than a global setting.
I believe it is possible to update a subscription with a set total_billing_cycle 'at_renewal' which extends the total_billing_cycle for another term. However it is not clear whether this parameter is ever possible to alter after it is initially set, i.e. will passing this in the case of updating a subscription do anything to it's lifespan? (it's not listed as a param you can pass to update a subscription) And furthermore, when the total_billing_cycle is met, the subscription goes into an expired state, which means the user has to repurchase a subscription. In most cases user's will want to just use the default 'unlimited', but just to be thorough I wanted to address this.
As for the 'first_renewal_date' this is being used with Commerce Recurly. I'm using it currently as a global setting in the payment method callback to offer to start all subscriptions on the first of every month. This is obviously helpful for accounting and certain user scenarios.
Comments
Comment #1
quicksketchThe "total_billing_cycles" is already configurable at the plan level via the Recurly.com interface, I think assuming to leave that a the default time period is going to be fine for most sites. Considering neither of these options is over-rideable for the "Hosted Pages" approach, I think the implementation of each of these options should belong in the payment module you've chosen for your site (recurly_hosted, recurlyjs, or commerce_recurly), otherwise we would present options that didn't have any effect for users of the recurly_hosted module. The recurlyjs module provides both options as a FAPI property #total_billing_cycles and #first_renewal_date if you want to set those manually right now. Considering first_renewal_date MUST be set by the API, it would probably make sense to have that as an option in the module (just like enable coupons, add-ons, and billing information level that we have already in RecurlyJS).
Comment #2
blasthaus commentedOk we're on the right track then. In terms of handling the total_billing_cycles in recurlyjs and commerce_recurly, this brings up some conditions that need to be considered. Specifically, if someone's subscription term is about to expire, they should know about that in Drupal. In Recurly's Dunning settings for email templates there is a token
{{subscription_expires_at}}which can be implemented into the emails that get sent. It turns out that getting this information from a subscription or account is not an easy task. The main goal is to retain customers and encourage them to renew in this case, set a message a month out from the expiration date when they view their account or login. This is a small detail I know, but just to bring it up. I plan to store that date on the subscription entity in commerce_recurly FYI.Comment #3
quicksketchThe API documentation seems to indicate that all subscription objects/requests include an "expires_at" property (http://docs.recurly.com/api/subscriptions#lookup-subscription), though the docs only state it applies to canceled accounts (not necessarily non-renewing accounts). We'll need to investigate this further.
Totally agreed about giving users warning beforehand if their subscription is coming to an end. My use-case is for indefinite subscriptions, so some things like this aren't coming across my radar.
Comment #4
blasthaus commentedFollow up to see if this issue may in fact be fixed with Include a past due status on user-facing subscription page or if that only fixes past_due messages and not 'expires_at' messages.
One more thing to note, even though most users will likely opt to not use a limited lifespan subscription. Consider a use-case like a hosting provider (with 1 year, 3 year, 5 year plan) where the customer can actually set the option to automatically renew or not. I think there actually may be quite a few examples like this.
Comment #5
quicksketchYeah this problem is still not addressed, either in warning users about subscriptions coming to an end or allowing users to choose indefinite or fixed cycles (though you can still form_alter() the Recurly.js element to set this to another value).
Comment #6
quicksketchRecurly offers some interesting thoughts on the difference between monthly billing and annual billing. Seems like they basically recommend having two entirely separate subscriptions for month-to-month vs. annual, since they're likely to be priced differently also (a discount given to annual subscribers for example). http://docs.recurly.com/upgrades-downgrades
Taking that approach total_billing_cycles would possibly not be needed (overriding the defaults) since you would simply have different plans for each type of billing.
Comment #7
blasthaus commentedThat's how I am dealing with it. For what it's worth, the add-ons can also be built into the subscription offerings although you can very quickly start to accumulate many different product combinations. This main benefit of this approach is that you will avoid the additional Recurly fees since they do a separate transaction for any add ons. (along with a separate fee of course:0)
Comment #8
quicksketchI think solving this problem by implementing different plans (as @blasthaus has done) is the right approach here. If someone is interested in building out more advanced support for different length subscriptions please reopen this issue or file a new one.