Stripe trial should be 0 days/no trial, instead is 365 days.

[davidsandbrand]

EXPLANATION OF THE ISSUE

I've recently dropped my trial period to zero, so users should be immediately charged with no trial. However, s2Member is sending 365 days as the trial period to stripe.

here's the shortcode I'm using;

[s2Member-Pro-Stripe-Form level="1" ccaps="" desc="$24 CAD/month billed as $288/year" cc="CAD" custom="URL.com" ta="0" tp="0" tt="D" ra="288" rp="1" rt="Y" rr="1" coupon="" accept_coupons="0" default_country_code="CA" captcha="0" success="https://URL.com/congratulations-and-welcome/" /]
(real url is not "URL.com")

Stripe API version is the most recent, 2017-01-27
WordPress version is the most recent, 4.7.2
s2 version is the most recent, Version 161129 + s2Member Pro v161129

STEPS TO REPRODUCE THE ISSUE

I've tested removing the following options from the shortcode;
ta="0" tp="0" tt="D"

I've also changed the tt="D" to be tt="Y", while keeping the other two values as zero.

but in all cases, the plan that is created includes a 365 day trial. The customer is billed in stripe, but they show as in a trial.

BEHAVIOR THAT I EXPECTED

customer is billed, and not shown as a trial user.

BEHAVIOR THAT I OBSERVED

Strangely, in stripe, the customer is shows to have been billed, but no invoice is generated - or rather, an invoice of $0.00 is shown. I believe this is because stripe is receiving conflicting info: trial, but bill.

[raamdev]

@davidsandbrand Thank you very much for the bug report. We'll try to reproduce this on our end and if there's a bug here, we'll work on fixing it.

[davidsandbrand]

Here's some info I've just received from Stripe support;

============
Hey David,

Paddy from Stripe here.

I've had a deeper look into your subscription issue and I've discovered why your trial periods are behaving unusually. It appears that your subscription plans are being made with a 3 day trial period, and then a separate invoice item is being created to charge your customers. When a subscription for a yearly billing period is created, any trial period applies to any invoices created within that period. Since the invoices are being created with the 3 days of the trial (the one which was set up when the plan was created), new trial periods are being created which last for the entire duration of the invoice; a year. The result is that the customer is being charged, followed by a year-long trial period.

I'm afraid that I haven't been able to find a way to correct the existing subscriptions without charging your customers another time. Setting "trial_end" [1], either through your dashboard or through the API, will overwrite the current billing period. This will lead to the customer being charged again if the trial period is set to zero.

From what I can see, the trials you mentioned end on the same day as their respective billing cycles. This means that your customers should be billed as intended with the current trial setup. They will appear as trialling on your dashboard in the mean time. I've included a link to one of these subscriptions on your dashboard that you can check out:

[link to one of my customers]

The above subscription was made on 2017/02/13 and is trialling until 2018/02/13. Once the trial period expires this customer will be billed again and will appear to be as normal on their statement.

I think the best option here is to get in touch with s2Member. They will be able to adjust your subscriptions in future so that they don't include the invoice during the trial period. I appreciate it is frustrating that I'm asking you to look elsewhere for this solution, but your subscription plugin will be in a good position to adjust your settings. You can reach out to s2Member through their helpdesk here:

https://s2member.com/support/

I really hope this information helps clarify your situation. Please don't hesitate to get back to me if there's anything else I could do for you, either regarding these subscriptions or anything else Stripe-related. It would be my pleasure to help out.

All the best,

Paddy

============

I hope that clears up exactly what I'm talking about.

Thanks,

David.

[rossagrant]

Just to say, I'm currently integrating Stripe Pro forms and my first monthly subscription is showing a 30 day trial too.

It appears that S2 is setting up the recurring subscription, the user is being charged upon creation - so no problem with payment - but rather than create a subscription with an 'active' 30 day cycle - it is instead giving the user a 30 days trial.

So, in short, the billing periods are the same as the trial periods - but I'm guessing it would be better for S2 to create an 'active' sub, not a 'trialing' one, to stop any confusion.

Shout up if I can help test anything.

Ross :)

[renzms]

@raamdev @jaswsinc

Bug Confirmed

Tested Using:

WordPress Version: 4.7.2
Current WordPress Theme: Twenty Seventeen version 1.1
Theme Author: the WordPress team - https://wordpress.org/
Theme URI: https://wordpress.org/themes/twentyseventeen/
Active Plugins: s2Member v161129
PHP Version: 7.0.10-2+deb.sury.org~xenial+1
MySQL Version: 10.0.29-MariaDB-0ubuntu0.16.04.1
Stripe API Version: 2017-01-27

Shortcode Used:

[s2Member-Pro-Stripe-Form level="1" ccaps="" desc="$30 USD / Monthly (recurring charge, for ongoing access)" cc="USD" custom="renz.domain.net" ta="0" tp="0" tt="D" ra="30" rp="1" rt="M" rr="1" coupon="" accept_coupons="0" default_country_code="US" captcha="0" /]

Extended Testing Variables:
Active Plugins: s2Member Pro v170126-RC
Stripe API Version: 2016-07-26 [Rollback to last known API Version]

In all tests with recent s2Member Pro versions and Stripe API, all subscriptions are stuck in a trial mode, denoted in Stripe as Trialing rather than the normal Active status.

Reviewing older subscriptions show that this only seems to be an issue with Subscriptions made in 2017, all older subscriptions that were previously Active are unaffected.

[raamdev]

Thanks for the additional testing and information, everyone. I'll add this to the pipeline to be worked on for the next release (the current development cycle closed a few weeks ago, so this will go into the next one).

[rossagrant]

@raamdev - great stuff - I'll hang back for a fix until I go live with pro-forms for now then.

Do you have a rough ETA for the next release, where this will be fixed?

Thanks :)

[raamdev]

@rossagrant The we just started a new development cycle and the next Release Candidate is targeted for March 27th, 2017. There will likely be a patch available before then, however, as soon as this particular issue is fixed in the development branch. Keep your eye on this GitHub issue for updates. :-)