Recurrence problem on Stripe!

#1

Hi,

I read several topics about the fact that Stripe designates as the “trial period” the first recurrence of a s2Member subscription even without a trial period, but for me it’s not just a designation…
My problem is that despite the following metadata guidelines: “recurring”: “true”, “recurring_times”: “2” sent to Stripe for a 3 month subscription without trial, Stripe charges 4 times instead of 3 (1 time during the initial purchase, normal, then 3 recurring payments instead of 2… which makes 1 payment too much and gives access 1 month too much before the automatic EOT access.
The shortcode used is however in the same configuration as the one for the PayPal platform which works perfectly well.
I think there is a real problem in the configuration with Stripe, which creates a trial period when there should not be any…
Here is my used shortcode:
[s2Member-Pro-Stripe-Form level=‘1’ ccaps=’’ desc=’ Formule 3 mois’ cc=‘EUR’ custom=‘mywebsite.com’ ta=‘0’ tp=‘0’ tt=‘D’ ra=‘10’ rp=‘1’ rt=‘M’ rr=‘1’ rrt=‘2’ coupon=’’ accept_coupons=‘0’ default_country_code=‘FR’ captcha=‘0’ accept=’’ cancel=‘0’ modify=‘0’ register=‘0’ update=‘0’ success=’/bienvenue/?prenom=%%first_name%%&email=%%payer_email%%’]
Can you help me to solve this very serious problem for my customers?

Thanks in advance, best regards. Brice.

#3

Hi Brice.

So you get 4 charges instead of a single one? I have seen other threads where a couple of charges are seen, but don’t remember these many. Are some 0 EUR charges or all for the 10 EUR? Just trying to get more info.

Do you have logging enabled? What log entries do you get for a new subscription purchase? You can test with a 1 cent per day subscription.

#4

Hi Cristian,

I get 1 immediate payment of 10 € and a first recurring charge of 0 € during the initial order, then 3 recurring charges of 10 € (1 per month following) instead of 2 expected by my shortcode…
For information, my PayPal shortcode with exactly the same configuration causes only the following 2 recurring charges, not 3… so that comes from information sent to Stripe that creates a recurring charge of too much!
Unfortunately, I can not enable logging because my site and commerce is already completely online and vulnerable to possible attacks to my customers.
It seems fair to think that the s2Member shortcode for Pro Stripe Payment configures a trial period of a duration equivalent to the “rp” and “rt” mentions even when this trial period is not desired via the mentions “tp” and “tt” of the shortcode and that causes a shift in the beginning of the subscription and therefore in its total duration…
Please have a look at this side in the Stripe API code implemented in s2Member.

Thanks so much for your help. Best regards, Brice.

#5

Gotcha. I’ll look into that. Thanks for the heads up! :slight_smile:

Did you try reproducing this in a clean installation of WP with just s2Member Pro? If you try this, please enable logging, so we can see more details about what is being sent to Stripe.

#6

I suspect it may be related to this: https://github.com/wpsharks/s2member/issues/1052#issuecomment-294831137

1 Like
#7

Hi,

Sorry for my bad english, I’m french lol…
The post above seems to talk about the problem that I get but the shift they speak about does not seem to generate too much recurring payments when it’s precisely what bothers me the most.
My problem is not that the label is named “trial”… My problem is that the subscription starts a month later than expected and so ends a month too late (the unexpected month is also charged in too much to customers).
Maybe I can help you in these investigations (I’m a programmer) if you tell me where I can find the exact files of Stripe API built into s2Member that causes this communication with Stripe after payment.

Thanks. Cordially. Brice.

#8

I didn’t mean the main topic of that thread, but what Jason explained about how he did the Stripe integration:

“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.”

“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.”

“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.”

I wonder then if this offset could be causing a problem with a subscription set for a number of payments, like you’re experiencing, instead of an ongoing one until cancelled.

This line seems related to it: s2member-pro/src/includes/classes/gateways/stripe/stripe-utilities.inc.php

'trial_period_days'    => $trial_period_days ? $trial_period_days : $interval_days,

You’re very welcome to look into it. The Stripe integration files can be found under s2member-pro/src/includes/classes/gateways/stripe/

I look forward to your update. :slight_smile:

1 Like
#9

I think you understand everything about my problem: the offset of the subscription’s beginning mentioned by Jason causes a complete shift of subscriptions that are set for a fixed number of payments like my shortcode’s configuration…

I will try to help you by looking at the Stripe integration files that you quote, thank you for your valuable help, you know s2Member and Stripe much better than me!

Best regards, Brice.

1 Like
#10

Hi Cristian,

After a long search in the previously mentioned Stripe API s2Member files, and after activating the s2Member log files on a blank installation as you suggested, I did not identify a real programming or communication “problem” between s2Member and Stripe.

On the other hand, I understood from where comes the error that I get: when we set the shortcode for a subscription with a fixed number of payments, s2Member manages the first payment as an immediate purchase and creates a subscription which it shifts the start via a trial period equal to the recurring periods set in the shortcode.
However, the initial payment and this trial period is not counted in the subscription created by Stripe … The count of recurring payments requested (2 in my case) starts from the subscription period following the trial period…
In the end, because of this operation, I find myself with an initial payment when placing the order, followed by 3 recurring payments each month (1 at the end of the trial period, considered as the first of the subscription, then the 2 recurring payments requested in the shortcode) instead of the only 2 recurring payments normally expected.

To solve this, I think there are only 2 possible solutions:

  • Find another way to manage Stripe subscriptions on the s2Member side by integrating the initial payment into the subscription without a trial period.
  • Specify to all users of Stripe Pro Forms that they must deduct an additional recurring payment from their shortcode if they wish to obtain a recurring payment number corresponding to their expectations.

That’s it, I hope you’ll come to understand my explanation despite my level of very average English.

Sincerely, Brice.

1 Like
#11

Your english is very good. I understood everything you said, it was well explained. Well done on researching it and confirming the problem. What you described is what I suspected, and why I pointed you to it.

Yes, the integration has to be fixed so this doesn’t happen. The site owner should not be worried with this. If he sets it to 2 payments, then it should be 2 payments, whether s2 does its trick to get a faster result with the first payment or not, it should take into account the rrt value as well. Or have a setting to remove that immediate charge before the subscription, as is available in the PayPal options panel.

I have it added to my list of fixes to-do. In the meantime, the workaround that I can see would be to set your rrt value to 1 lower than what you want, to compensate for the immediate charge s2 does before the subscription start. Could you work with that approach until the implementation is improved?

:slight_smile:

1 Like
#12

I think I will continue to manually cancel the Stripe subscriptions that are in this configuration until your update (there are not many happily).
If I deduct a recurring payment in the shortcode, I’m afraid it creates a bigger problem after your update if I make sales before reacting and changing my shortcode again.

In any case thank you for your quick consideration and I hope that the update will not be too late either.
Sincerely, Brice.

1 Like
#13

Just a thought about changing the marketing tactic in stead of the code. Why not charge once for the entire term and issue a discount coupon for the amount of free trial?

#14

Hi Brian,

I think you didn’t understand how I use s2Member.
I don’t want any trial period and the fixed number of recurring payments configuration is a easiest payment method (payment in installments) for my customers.
So I can’t use any coupon code to do that.

Best regards. Brice.

#15

Hi Cristian,

I have just been informed of something much more serious and embarrassing about our problem:
Customers who paid in installments with Stripe as described in this post received EOT Renewal / Reminder Emails notifying them of their acces cessation at the end of the third month (this is the behavior I was originally hoping for)… but the recurring payment in excess (4th payment unforeseen therefore) prevented the normal EOT and therefore continued for a 4th month …
There is therefore a real problem of coherence between the theoretical management of s2Member accesses and the reality in Stripe.
This problem therefore prevents the number of recurring payments in the shortcode from being modified because it also shifts the theoretical date of the automatic EOT which causes the sending of EOT Renewal / Reminder Emails which don’t correspond with the real EOT.

Best regards. Brice.

#16

Ah, I see. Thank you for the additional info.

Do users that have the subscription still active, have an EOT time set in their profiles? Most likely not. I believe the reminders system is calculating this separately and taking into account that first month.

Well, if you do shorten the rrt by one to compensate while its fixed, it seems you’d also need to adjust the reminder email offset.

#17

Hi,

You’re right, all users that have a subscription still active in this configuration haven’t EOT time set in their profile!
I’m hope that their subscriptions automaticly stop at the end of 4th month when Stripe will send the information on the end of their subscription to s2Member… otherwise I should do it myself manually for each customer… bad thing…
I can’t adjust the reminder email offset for reminders that less than one month because the last month (4th month) don’t exist for s2Member.

Do you know when you will be able to release an update about that? This is very problematic for me and I don’t think that I’m alone in this situation.

Best regards, Brice.

#18

No, I don’t have an estimate yet.

I just found a knowledge base article I had not seen before, that mentions this rrt behavior (see the “important note” at the end): https://s2member.com/kb-article/how-do-i-offer-an-installment-plan/

#19

Hi Cristian,

I know this “important note” very well, and the same thing is also mentioned at the explanations of the shortcode but I applied this mention from the beginning!
That’s why my shortcode only mentions rrt = ‘2’ and not rrt = ‘3’ (I remind you that the expected behavior is 3 payments in all, 1 when ordering and 2 each following month).
However, even with my mention rrt = ‘2’, Stripe is collecting a 4th recurring payment due to an unwanted trial period not counted in the Stripe subscription.

So this problem is real and not solved.

Thans for your help. Best regards, Brice.

1 Like
#20

even with my mention rrt = ‘2’, Stripe is collecting a 4th recurring payment

Oh, I had not understood that! I thought you used rrt=“3” first. I now went back to your first post and see the rrt=“2” that I missed the it first time. I’m really sorry.

Okay, I made a note about that to take into account while investigating this.

Thank you for clarifying it!

1 Like
#21
1 Like