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. :-)

[rossagrant]

@raamdev - fantastic - I'll keep my eye out on this ticket - and hopefully patch it before the next release.

I'm all set with my pro-forms integration, so as soon is this is patched, I can go live with it.

Thanks again! :)

[davidsandbrand]

@rossagrant FYI, My workaround was to set a 1-day trial. Then, once someone signs up, I tell that there's a bug that is causing a 24-hour delay in the billing. Of course, I'm not totally being truthful, except that there is a bug, and their charge will be done 24 hours late. The downside to this temporary work-around is that the s2 checkout page shows that they'll be billed $0 today, which is true, but not ideal.

Meanwhile, I have three clients that are essentially broken in stripe - billed, but trialing. and as a result, they don't even show as clients in my profitwell.com dashboard. :(

@raamdev I'd love a patch for this asap, let me know if I can help in any way.

thanks.

[davidsandbrand]

I believe I've found another aspect of this bug;

checkout code of; [s2Member-Pro-Stripe-Form level="1" ccaps="" desc="$34 CAD/month billed monthly" cc="CAD" custom="URL.com" ta="0" tp="1" tt="D" ra="34" rp="1" rt="M" rr="1" coupon="" accept_coupons="0" default_country_code="CA" captcha="0" success="URL.com/congratulations-and-welcome/" /]

specifically note rp="1" rt="M", meaning a 1-month recurrence schedule.

sent the following to stripe; "plan": { "id": "hidden", "object": "plan", "amount": 3570, "created": 1488311455, "currency": "cad", "interval": "day", "interval_count": 30, "livemode": true, "metadata": { "recurring": "true", "recurring_times": "-1" },

meaning this is now a 30-day plan, not a 1-month plan. Not a huge difference, but not what my customer was expecting, and not what I promised.

[jaswrks]

I just wanted to note that I've been following along here. What's changed is simply the label that Stripe applies to a Subscription that has an offset start date.

s2Member intentionally charges the first payment in real-time to avoid passing the first charge off to Stripe as a part of the Subscription. Then a Subscription is created that is set to start X days later, according the billing plan configured by a site owner.

In the past, Stripe did not apply the 'Trialing' label and there was no confusion. The new 'Trialing' label is what's adding this confusion. s2Member adds trial days, but not for the purpose of creating a 'Trial', it's simply to have the Subscription start at a specific point in time that is always in the future, because s2Member handles the first charge by itself.

I am reaching out to them for help on this. If they are unable or unwilling to alter the label on their side, s2Member may need to create a Subscription and let Stripe take over on handling the first payment. I would like to avoid doing this however, as the first payment being charged in real-time allows s2Member to gain more control over the events taking place in real-time; i.e., a charge that succeeds or fails is generally a better approach than to create a Subscription, let a customer in, and then moments later the first charge fails.

My experience with Subscriptions in the past is that they don't always report failure on the first charge in real-time, which is why it's not done that way. However, if I can get confirmation from Stripe that this will be the case, then I will update it.

What would be even better is for Stripe to support the ability to have a Subscription start in the future using an API configuration parameter other than trial_period_days, which is all that's available at present. So they might be able to help us in that way too. https://stripe.com/docs/api#create_subscription

[jaswrks]

Just to clarify, there's nothing I'd call 'broken' in this integration, because the schedule is proceeding as intended and as configured by a site owner. The problem is that 'Trialing' label and the confusion that it creates, because it's NOT a trial and should not be referenced as one. We charged the customer for the first time already. The intention is just to offset the start date of the 'Subscription'. That's done using trial_period_days, because it's the only option we have in terms of altering the start date. Stripe is now interpreting this always as the intention being to have them in 'Trial' mode; i.e., it results in that 'Trialing' label in the Stripe Dashboard.

[jaswrks]

Hi there! :-)

Jason over here with s2Member for WordPress. We have a fairly popular integration with Stripe.

Recently, this issue came up. https://github.com/websharks/s2member/issues/1052

I just left a new comment here after having a closer look. https://github.com/websharks/s2member/issues/1052#issuecomment-294831137

QUESTION:

Is there a way to have a Subscription start the first payment at a date in the future? i.e., Other than with trial_period_days, which results in a 'Trialing' label in the Stripe Dashboard and that leads to confusion for many of our merchants — as outlined in that issue I referenced.

Or, is there a way to avoid having the 'Trialing' label applied to a Subscription that has been given trial_period_days? To clarify, we add trial_period_days to simply adjust the start date, NOT to provide a trial period that will show up in the Stripe Dashboard as being a 'Free Trial'. We charge the first payment separately, so it's not a free trial.

[jaswrks]

Stripe replies...

Hey,

Nice to hear from you.

Unfortunately, the only way to start a Subscription at a set date is to use the trial_end-argument; this will also always make a "Trialing" label appear in the dashboard.

I know that's probably not the answer you wanted, but I do hope it still helped. Please let me know if you have any more questions or concerns I can address for you. I'm always happy to help where I can.

• Korben

[davidsandbrand]

@jaswrks, just for clarity - this isn't just an issue with a label being applied incorrectly.

Stripe has many integrations, and the ones that provide analytics, like BareMetrics.io or profitwell.com (which is the one I use because, free) or any of the others (see https://stripe.com/works-with/categories/analytics for the list) simply ignore any users with a 'trialing' designation.

So in other words, this bug causes incorrect metrics elsewhere.

[rossagrant]

@jaswrks - thanks for the updates Jason!

Just wondering if you have any plans for changing anything here, or whether we just have to roll with the trialling label for the first payment.

For me, once the customer pays their 2nd sub payment, the trialling label is replaced with 'active' - so it eventually irons itself out.

I'd like to go live with Pro-forms soon, so just wondered if you had plans for changing S2's behaviour?

Ross :)

[rossagrant]

Sorry to leave another message here @jaswrks - just wondered if there were any updates on this? Thanks so much! 👍

[jaswrks]

I think the best course of action here is to make this configurable, in much the same way we did with PayPal Subscriptions. That way a site owner can choose to have the first charge go through in real-time, separately, as it's handled now. And just deal with the trial label for the time being. And then another option that hands it all over to Stripe so the first charge is a part of the Subscription.

I think making the first charge a part of the Subscription should be the new default, as that seems easier to grasp, and it follows the way s2Member works with PayPal Pro also. Then site owners who have mission-critical implementations can change this if they'd like.

[rossagrant]

Sounds great to me @jaswrks! Let me know if I can help you test any of this - I'm more than happy to patch my installation and test Stripe for you in a live environment. Stripe is all ready to go for me, but I'm still using PayPal. I can easily test it though! Keep me posted! :)

[rossagrant]

Just gone LIVE with Stripe forms - which I'm finding brilliant - but just wondering if the plan on this part of s2 was still to make it configurable @jaswrks?

Let me know if you ever need anything testing regarding this - I'm more than happy to help in any way I can! 👍