Fixed Stripe subscription trial started even if payment isn't completed

[Tom]

Affected version

2.1.10 Patch 2

I'm not entirely sure if this is caused by what XF is configured to pass to the Stripe API, or if it's a configuration issue on our end, but we currently have an issue where if a user launches the Stripe modal to subscribe to a user upgrade, but doesn't proceed and doesn't make a payment, a trial subscription is still started on Stripe's end (causing issues related to renewal emails being sent to users who aren't actively subscribed).

 

[BT10]

I reported this issue in a support ticket and was told to publish it here.

When using the Stripe integration in XenForo, I notice that when someone attempts to upgrade their account by subscribing to our service, Stripe will report it as a subscription, even when the member didn't follow through with their billing details.



So a click on the Upgrade button will be logged as a subscription and when they try to exit the billing modal, that gets recorded as a cancellation. Each click on the Upgrade button and each click outside of the screen (to remove the Stripe popup) is being counted as a Subscribe and a Cancel.

I created a test account, attempted to click on the Upgrade buttons 3 times and during those 3 attempts, I will not enter anything in the "Confirm payment details" modal and only click elsewhere on the screen to remove the billing modal.

Here is what gets reported to Stripe:



No doubt that some of our customers do that a couple of times before deciding to enter their billing details and make the purchase.

Why is this critical?

First of all, Stripe is now reporting false data to us. When we checked for a list of current and canceled subscriptions, the same customer who didn't fill out their billing details during the first attempt was listed under both sections (Current customer and Canceled customer). When we want to export our Stripe reports, we wouldn't be able to tell if this customer is actually a current subscriber or has already canceled his/her subscription.

Secondly, anyone who only clicks on the Upgrade button will also be reported as a subscriber, even if they don't fill out their billing details. This gets added to the Stripe's Subscription page. Again, when we want to get a list of current customers (subscribers), this person who didn't actually pay will be included in the report. And we wouldn't be able to tell if he has paid or not unless we look him up in our forum or Stripe's dashboard.

How would we be able to fix it? How do we tell Stripe not to record any of those events before the customer actually made the payment?

While I'm still here, I would like to ask, why are subscriptions in XenForo being labeled "Trial" instead of "Active"?




Update #1: I notice someone recently reported a similar problem where "a user launches the Stripe modal to subscribe to a user upgrade, but doesn't proceed and doesn't make a payment, a trial subscription is still started on Stripe's end." As a result, it causes "issues related to renewal emails being sent to users who aren't actively subscribed."

 

[ichpen]

I'm not entirely sure if this is caused by what XF is configured to pass to the Stripe API, or if it's a configuration issue on our end, but we currently have an issue where if a user launches the Stripe modal to subscribe to a user upgrade, but doesn't proceed and doesn't make a payment, a trial subscription is still started on Stripe's end (causing issues related to renewal emails being sent to users who aren't actively subscribed).

I can confirm this also.

 

[BT10]

@ichpen Same, posted about it here as well.

 

[BT10]

Update #2: I reported this issue to Stripe and this is what they told me:

Jumping right in here, based on the logs associated with the cancellations you've outlined, the subscription.cancel API call was done through the API. For cases such as these, I'd recommend having a look at your integration. Specifically, the code that is executed when clicking the upgrade button.

I assume they're talking about XenForo integration with Stripe.

 

[BT10]

Update #3: Further reply from Stripe support

As mentioned previously, what may be causing the issue here would be the code that is executed when you or your customer clicks the purchase button. I'd suggest to have a look at your code for what happens when that button has been clicked.

As far as we can see here, based on the logs, the action that is taken during the timeline you've specified is to cancel the subscription and to subsequently create a new subscription. In order to resolve the issue, we'll need to have a look at the code to identify any underlying issues with this.

If your integration was built by a third party, then I'd also suggest to reach out to them as they would be able to examine the code and identify any underlying issues.

 

[BT10]

Update #4: Last reply from Stripe support:

Based on what I can see through the video you've forwarded (also provided this video to the XenForo support team already) is that there doesn't seem to be any error handling when the there is no input within the text boxes for entering payment details (i.e. the customer is not prompted to enter in any information or there is no prevention of the progression).

What this might suggest would be a mixup in the code where when conditions are checked to choose the most appropriate action (in this case, it is cancelling the subscription and recreating it instead of other responses.) Though with that said, XenForo would be best knowledgeable about how they have set up the integration with Stripe.

 

[BT10]

Update #5: I reached out to @AddonFlare, who created the Paid Registration add-on, for help, and this is what the told me:

XF would have to change the way they go about setting up the subscription (if there's even a different way they can take). I just looked at the existing code and it creates a "payment intent" via Stripe when the "purchase button" is clicked.

More info about it here: https://stripe.com/docs/payments/payment-intents

 

[Mouth]

Update #5:

It certainly seems incorrect to create a subscription with Stripe when there is no card details present. I hope xF triage/respond this bug report shortly.

 

[Paul B]

There's no need to go back and forth with Stripe or keep bumping the thread.

The developers will respond in due course.

 

[BT10]

Sorry @Brogan, it was not my intention to bump the thread. I just want to give as much info as possible to assist the XenForo developers with their work. I thought the info provided by Stripe was important because the integration was directly between XenForo and Stripe. My apology if it causes any issues for you guys.

 

[Paul B]

No problem @BT10 - the developers are aware of every bug report, even if they don't immediately respond.

 

[Mike]

We have changed this for the next 2.2 release. It's a pretty significant internal flow change for Stipe when doing recurring subscriptions. We'll now only create the subscription once we have a payment method. (If that payment then fails or requires something like 3D secure which isn't completed, the subscription never leaves "incomplete" in Stripe and it will be removed in approximately 24 hours. You can filter these out in the Stripe dashboard.)

 

[BT10]

@Mike You're the man. Thank you so much.

Were you able to look into why Stripe labeled the subscriptions made through XenForo upgrade as "Trial" instead "Active"?

Thanks again.

 

[Mike]

That was a side effect of the flow used.

 

[BT10]

@Mike Got it, thank you.

 

[BT10]

@Mike Will the existing subscriptions that were created based on this issue be updated/fixed automatically in Stripe once we update to XenForo 2.2? From what @Tom posted in message #1, "a trial subscription is still started on Stripe's end (causing issues related to renewal emails being sent to users who aren't actively subscribed)."

We have over 1,000 total subscribers (some of whom are not actual subscribers because of this current bug). I don't want them to be emailed about their upcoming subscription renewal even though they're not an active subscriber yet. Does that make sense?

 

[Mike]

No, this doesn't change things retroactively.

 

[robdog]

@Mike, I am running into this issue as well, but is there any way to get this fixed in 2.1.x as well? Or is the only way to get this fixed to upgrade to 2.2?

 

[Mike]

It's a very significant change. It requires 2.2. (2.2 is also now our primary release so any further bug fixes will generally be in future 2.2 releases.)