Fixed Tons of errors on backend in Payment Provider log after upgrading to 2.3.5

cdub

cdub

Well-known member
Affected version
2.3.5
Getting a TON of errors in the payment provider log after upgrading to 2.3.5. Thankfully new subscription are going through and renewals are going through. Just a TON of webhook errors from Stripe. The funny thing is they're all Unknown Payment profile and PayPal when I don't have PayPal set up as all as a payment profile. But when I click through to the error the log is all Stripe.

Error: Could not validate purchasable: Unable to find user upgrade '9'
PayPal User upgrades Today at 2:53 AM

Error: Event data received from Stripe does not contain the expected values.
Unknown payment profile Unknown purchasable Today at 12:40 AM Unknown user

etc

Screenshot 2025-02-03 at 6.31.35 AM.webp

On Stripe's end we're getting this:

Screenshot 2025-02-03 at 6.32.57 AM.webp


New suscriptions are going through fine.

Screenshot 2025-02-03 at 6.37.03 AM.webp


Anyone else seeing this? I do have the Paid Registrations addon from @Painbaker installed but is anyone who doesn't have that installed seeing problems like this?
 
Yes tons...
I have to say that I am a little disappointed that this bug error request was written on Feb 3rd, and no responses yet.
The HUGE issue that I am getting is that sometimes it works, sometimes it does not work. Yes, I also get all of the errors in the error log as well.
(Does Xenforo know that Stripe updates and changes their api every month or so?)
I believe we are on basil now..
Screenshot 2025-04-30 at 06-35-43 Developers – Prestigeworldwidepr – Stripe.webp

Of the many issues that exist:
1) If users cancel their account or it gets turned off for non-payment/non-renewal, then when they try to renew or turn it on again, Stripe creates 2 subscriptions for the customer (1 cancelled and 1 active), which is ok and as it should be but Xenforo cannot then apply or update the actual new subscription. and therefore the result is that the payment processes successfully, but the callback to Xenforo forum does not have the proper id, so therefore, the 'upgraded checkbox' does not get checked.
2) Members find it EXTREMELY difficult to administrate their active subscription.

What I think needs to happen is Xenforo update to Stripes current API (yes, older ones cause problems. I know because I use those same APIs in a .NET environment). Also, Xenforo should revamp the payment profile process to be more user friendly as well as more comprehensive when dealing with failures.

The number one issue I get everyday (there are literally dozens everyday) is "hey, can you check Stripe to see if this user has upgraded? He says that he did, but he is not on our website."

XF, PLEASE fix this. We are losing customers because of this. At some point, it will no longer be sustainable.
 
So, there are no Webhook error on Stripe (they get back a 200 response), so, there is probably a bug in XF when receiving the webhook.
The biggest issue I am experiencing is that Stripe processes a recurring subscription (successfully), and XF does not check the 'premium' checkbox for the user. (We set up 'Premium' as the paid upgrade option).
Sometimes it works, sometimes it does not. Intermittent, but more often, it does not work.
Out of approx 1000 paying members, I have to manually update approx 5-10 a day.


Untitled-2.webp
 
finally got it figured out... XF need to update it's webhook code... the newest Stripe API's (like Basil) are not compatible with XF's webhook code.
It does work with a year 2022 Stripe API, but there have been so many changes to Stripe's API over the past few years and we cannot 'roll-back' our Stripe account API for security and patch reasons.
In the past month, we have had to manually upgrade every user... obviously the user gets a little steamed about this..
XF, PLEASE fix/patch and update the system.
 
We already force the API version to 2023-10-16, which should apply regardless of account settings. Other things integrating with Stripe should pin to their supported API versions as well. This is exactly the problem API versioning is designed to solve, security/bugs are orthogonal. Any security issues at Stripe are resolved in a way that is API-compatible, and insecure endpoints aren't left around for people to exploit.

Can you confirm it doesn't work with 2023-10-16?
 
I understand it does, that's why we pin to the earlier (and still supported) version that we tested with. For what it's worth, we use Stripe ourselves internally and to the best of my knowledge we haven't been able to reproduce this issue so far. We force version 2023-10-16 in our own code.
 
Jeremy P said:
I understand it does, that's why we pin to the earlier (and still supported) version that we tested with. For what it's worth, we use Stripe ourselves internally and to the best of my knowledge we haven't been able to reproduce this issue so far. We force version 2023-10-16 in our own code.
Click to expand...
So, can XF update to the latest, or do I need to find another option? Rolling back by Stripe API version is not an option for many reasons
 
Looking further into it, it appears we set the version for outgoing requests but don't have any control over the version for incoming requests. My understanding is that Stripe expects you to maintain separate accounts for each application expecting webhooks from a different API version.

In all honesty, we're unlikely to keep pace with every breaking update, so the best chance at mitigating this is likely having a XenForo-specific sub-account set to our supported API version (2023-10-16). Stripe makes creating application-specific sub-accounts pretty easy as far as I can tell.
 
I understand what you are saying, but I cannot set up a sub-account in Stripe for various reasons.
However, having multiple websites served by my one Stripe account is not the issue.

It would seem to me that it would be a simple fix on Xenforo's end.:
Look at the code on your webhook, re-map the events, and variables which are obviously not matching up any longer.
Because XF responds to the webhook from Stripe with a 200ok, but appends the error:
"Event data received from Stripe does not contain the expected values."

In all honesty, I hear what you are saying about "we're unlikely to keep pace with every breaking update", but maybe updating to THIS year would be a good thing. As a .NET programmer, I understand the frustration and I understand that because Stripe has a massive amount of services, their APIs update sometimes monthly. But c'mon...really...2023

I don't mean to sound obtuse or cause problems. I just want for this to work, and 'downgrading' another service to match your service is really not the responsible or appropriate answer, in my opinion as another developer.

I really hope that XF addresses this, because forcing forum owners to downgrade to a payment API almost 2 years old that has been patched and upgraded over that same time frame just does not make sense to me.
But, without it, it renders my forum useless and I lose out on what amounts to a substantial subscription income.
 
Updates to the API are often for introducing new features that we don't use, and contain breaking changes, so we just don't have a compelling reason to chase them too closely. Note that API versions are different than software versions, and that bugs and security fixes can be (and are) applied to multiple API versions on an ongoing basis (including older versions).

I'm still investigating, but I'm not sure the fix is as simple as you may think since we have to pin to certain versions of their SDK to match our own support policy. Even if we updated the API version now, this seems liable to happen again in the future if the account doesn't match what we expect for whatever reason.
 
well, we are screwed then and will lose all of our subscribers because even if we were to try to create a Stripe subaccount, those subscribers (and their stripe data (payment intents, invoices, ect)) would not be able to move over to another account.
 
I'm still investigating how viable it is to use the newer version on our older SDK, or what our options look like for updating the SDK.

For future reference, I wouldn't recommend upgrading the API version in Stripe without checking that all connected applications support the new version. There is a grace period to rollback the upgrade if any connected applications start failing, but it looks like it's limited to 72 hours unfortunately.
 
Jeremy P said:
I'm still investigating how viable it is to use the newer version on our older SDK, or what our options look like for updating the SDK.

For future reference, I wouldn't recommend upgrading the API version in Stripe without checking that all connected applications support the new version. There is a grace period to rollback the upgrade if any connected applications start failing, but it looks like it's limited to 72 hours unfortunately.
Click to expand...
thank you... sure would like to see a fix, and rather quickly...
 
Attaching a hotfix in case anyone else is running into this. It may still log errors for charge.succeeded on new subscriptions, but we actually only need those for one-off payments so it should still function ok. Will try to see if we can disambiguate those somehow, but Stripe makes this painful.

Still, we absolutely cannot guarantee we will always track the latest API changes. The basil update with breaking changes was released after the most recent XF version at the time of writing. I strongly caution against ever upgrading the Stripe API without exercising due diligence. That means ensuring all connected applications (including XenForo) are compatible, making the best of the three day grace period to actually test that new and existing payments continue to function properly for all of them, and rolling back the upgrade if they do not.

@cdub The PayPal errors may be related to your IPN settings in your PayPal account. PayPal will keep sending them to XF even if XF isn't using them for payments.
 

Attachments

Jeremy P said:
@cdub The PayPal errors may be related to your IPN settings in your PayPal account. PayPal will keep sending them to XF even if XF isn't using them for payments.
Click to expand...
PayPal wasn't sending them. It was Stripe. Everything was Stripe but XF said it was PayPal. Irregardless I think that particular problem has been solved on my site.
 
Ah ok, I'd seen someone else with a similar issue where it turned out to be related to legacy IPN settings. Just in case someone else with a similar issue comes across this thread in the future, the only other thing I can think of that would cause that going forward would be missing ?_xfProvider=stripe in the webhook URL.
 
Back
Top Bottom