S2Member Subscription Limitations

Until now I have been using some simple implementations of s2member for charging people. As I am looking to use s2member a bit further I’ve come across some concerns and am looking for some guidance as to how s2member is meant to function.

Below are a couple scenarios:

1 – I setup a recurring payment w/ trial period. Upon processing, I notice 2 transactions in the log. The first is the trial amount, which is charged through a regular transaction. The second is the creation of the recurring transaction.

Questions:

A – Where in this process is the trial period being managed? Authorize.net has a trial period area within it’s ARB functionality, but it doesn’t seem to be used.

B – I’ve tested an instance where the trial amount transaction goes through and the subscription creation fails, dumping the user back to the checkout page with the generic error “Error. Please contact Support for assistance.”. If for some reason there is an error while processing (general error) and only one transaction goes through, how do you communicate with the customer what has happened to avoid them being billed for something that looks as though never occurred?

2 – Suppose I have multiple packages that all have their own unique subscription terms and users who have purchased the base package can now purchase these optional packages.

Questions:

A – It seems the current functionality when it comes to modifications is to cancel the existing subscription and create the new one (with new terms). So if someone wants to modify their account mid-cycle, an appropriate method would be to pro-rate until the end of their cycle and then start the next cycle with an increased amount. This assumes the terms of the subscription do not change and it is just an increase (or decrease) in the sub amount. I would have to do this by setting the new terms to match the existing and calculating out a trial period that matches the pro-rated terms. Is this the only way to accomplish this and am I confined by s2member to only have one set of terms per account?

B – The above scenario does not work well with levels. Since users can pick and choose what they want, custom capabilities fits much better. However, adding a CC with subscription terms isn’t exactly offered here. I can get what I want by selling another set of terms at the same level that includes the CC’s, but again everything falls into one bucket, preventing me from controlling terms separately. Is there any other way to accomplish adding CC’s with recurring terms?

As you can see, I’m testing out how customized I can get with subscriptions. If the functionality works as I’ve described above, is this being looked at for the next release of s2member to improve the flexibility of subscription management?

I will need to leave the first scenario and the associated questions for the lead developer to address, as I’m not very familiar with how the Authorize.net code works with regards to trials. I’ll send Jason an email about this, but keep in mind that he’s currently head-deep in work on the next major release of s2Member, so he may be a bit slow to respond. Thank you for your patience.

2 – Suppose I have multiple packages that all have their own unique subscription terms and users who have purchased the base package can now purchase these optional packages.

Questions:

A – It seems the current functionality when it comes to modifications is to cancel the existing subscription and create the new one (with new terms). So if someone wants to modify their account mid-cycle, an appropriate method would be to pro-rate until the end of their cycle and then start the next cycle with an increased amount. This assumes the terms of the subscription do not change and it is just an increase (or decrease) in the sub amount. I would have to do this by setting the new terms to match the existing and calculating out a trial period that matches the pro-rated terms. Is this the only way to accomplish this and am I confined by s2member to only have one set of terms per account?

Yes, that is currently the only way to handle this scenario. You will need to do your own calculations to pro-rate things, if that’s what you want to do. The s2Member Button and Pro-Form shortcodes use attributes to define things like recurring term, trial period and amount, etc., so you can dynamically set those after using some PHP to make the necessary calculations (see this thread for more info on dynamic shortcode attributes).

Regarding multiple terms: I assume by that you mean multiple subscriptions. Currently s2Member is only capable of supporting one subscription per user, however we’re working towards supporting multiple subscriptions in the next major release of the plugin.

B – The above scenario does not work well with levels. Since users can pick and choose what they want, custom capabilities fits much better. However, adding a CC with subscription terms isn’t exactly offered here. I can get what I want by selling another set of terms at the same level that includes the CC’s, but again everything falls into one bucket, preventing me from controlling terms separately. Is there any other way to accomplish adding CC’s with recurring terms?

With the current version of the software, there is no other way. The limitation comes from only being able to have one subscription per account, as mentioned above. You can certainly use Custom Capabilities to add/remove features and use the Billing Modification form to change their subscription based on what Custom Capabilities you want to add/remove, but you will still need to maintain a single subscription and do all your pricing calculations ahead of time. If you want to sell Custom Capabilities on a one-time basis (i.e., non-recurring), we provide the Dashboard -› s2Member® -› Authorize.Net® Pro Forms -› Capability (Buy Now) Forms for exactly that.

As mentioned earlier, we recognize these limitations and we’re working towards improving them in the next major release of the software.

Thanks for the reply. I figured that I would need to develop workarounds in order to continue using s2member and the sales model I envision.

I look forward to seeing the next update. Hopefully there will be added flexibility so I don’t have to keep adding in my own hacks.

Thanks for the heads up on this thread.

A – Where in this process is the trial period being managed? Authorize.net has a trial period area within it’s ARB functionality, but it doesn’t seem to be used.

That is correct. Authorize.Net (like many other payment gateways), has some issues with the handling of a trial period. For instance, Authorize.Net may allow a customer to gain access initially, but then fail to collect charges a day later on the initially declined card. This is NOT a good thing for most sites.

In short, if s2Member chose to process trial periods via ARB exclusively, it would have very little control over how initial declines are handled (whether they be authorizations or captures).

s2Member’s solution is to make the initial charge (if there is one), as a direct pay transaction that is collected (i.e. authorized/captured in real-time), instead of doing it all together as an initial charge into the ARB configuration. If the initial charge declines for any reason, the ARB subscription is not created, and access is denied until the customer provides a card that has sufficient funds to cover the initial charge.

If there is a trial period, or a different initial charge amount, the ARB subscription is configured to start on a delayed scheduled that matches the time allowed in the initial term. In other words, the ARB subscription is used ONLY to handle future billing, and everything else is handled by s2Member.

B – I’ve tested an instance where the trial amount transaction goes through and the subscription creation fails, dumping the user back to the checkout page with the generic error “Error. Please contact Support for assistance.”. If for some reason there is an error while processing (general error) and only one transaction goes through, how do you communicate with the customer what has happened to avoid them being billed for something that looks as though never occurred?

Yes, this can happen under special circumstances. We have found that it’s very rare for this to happen, but you’re not the first person to report this to us. The issue (as I explained above), is that s2Member processes the initial charge, and if that goes through, the ARB subscription is created to cover any future charges. s2Member’s code assumes that a fully authorized/captured card, with full billing details and other important info, will not have any issue passing through the Authorize.Net ARB service API. And this is indeed the case 99% of the time. However, if for some odd reason (i.e. it’s a rarity), the ARB subscription fails to be created, this leaves the customer with an error on-screen, but a charge that actually went through.

We’re working on a fix to correct this issue for a future release.

A – It seems the current functionality when it comes to modifications is to cancel the existing subscription and create the new one (with new terms). So if someone wants to modify their account mid-cycle, an appropriate method would be to pro-rate until the end of their cycle and then start the next cycle with an increased amount. This assumes the terms of the subscription do not change and it is just an increase (or decrease) in the sub amount. I would have to do this by setting the new terms to match the existing and calculating out a trial period that matches the pro-rated terms. Is this the only way to accomplish this and am I confined by s2member to only have one set of terms per account?

B – The above scenario does not work well with levels. Since users can pick and choose what they want, custom capabilities fits much better. However, adding a CC with subscription terms isn’t exactly offered here. I can get what I want by selling another set of terms at the same level that includes the CC’s, but again everything falls into one bucket, preventing me from controlling terms separately. Is there any other way to accomplish adding CC’s with recurring terms?

Yes, these are both limitations in the current integration between s2Member and Authorize.Net. We’re working hard to move past these limitations in a future release of s2Member. Until then, you can work around some issues related to “A” above, by calculating some things on your own, perhaps creating a shortcode dynamically, based on the needs of your site. Please see this related thread:
http://www.primothemes.com/forums/viewtopic.php?f=36&t=1604

See also: Dashboard -› s2Member® -› API / Scripting -› Advanced PHP Conditionals

Excellent response! Thanks, Jason.

I ended up writing my own shortcode to process timing and rates to input into the s2member shortcode. This workaround resolves my situation now. I look forward to seeing what you end up with in the new release.