Closed User not upgraded after purchasing a subscription with stripe ( Race condition )

K

K a M a L

Well-known member
Licensed customer
Affected version
2.2.10
Today I got a report that a user has paid a recurring subscription via stripe but his account was not upgraded .. checking his payment log entry it shows
Error: Event data received from Stripe does not contain the expected values. and Purchase request key was N/A.
Checking the database I found that Purchase Request provider_metadata has the correct subscription_id and everything looks fine there.
Going through the code to find a probable reason for the issue I figured out it may be a race condition that could occur when the webhook notification is received/processed before purchase request is updated
$purchaseRequest->fastUpdate('provider_metadata', $subscriptionId);

P.S. This is not a duplicate of https://xenforo.com/community/threa...-does-not-contain-the-expected-values.204069/
which seems to be caused by deleted payment profile
 
Below after
$purchaseRequest->fastUpdate('provider_metadata', $subscriptionId);
Xenforo checks for payment success
$paymentStatus = $latestInvoice->payment_intent->status; if ($paymentStatus !== 'succeeded') { }

it could be a good Idea to upgrade user there using the payment status from API instead of relying on the webhook notification
 
Logs about not having the expected values are not necessarily unusual but was it the case that a paid for upgrade was not applied, or was it just logs?

A lot has changed in the Stripe code since this report.
 
Upgrade not applied.

Looking in the database, the "provider_metadata" field is never updated with the subscriber ID - if I do this manually and run the Stripe webhooks again then they go through.

Just to confirm, which events do I need to listen to? I currently have it as:

charge.dispute.funds_reinstated
charge.dispute.funds_withdrawn
charge.refunded
charge.succeeded
invoice.payment_succeeded
review.closed
 
Last edited:
As it happens we've been doing a bit of work on this over the last week and I'm confident that XF 2.3.5 will resolve these issues conclusively. Unfortunately I cannot fully confirm what is going wrong with 2.2. The Stripe implementation between 2.2 and 2.3 is quite different to begin with and some of the issues we've fixed were new in 2.3. But based on what you've said, I'm pretty sure it should no longer be an issue. But upgrading will be necessary.
 
Chris D said:
As it happens we've been doing a bit of work on this over the last week and I'm confident that XF 2.3.5 will resolve these issues conclusively. Unfortunately I cannot fully confirm what is going wrong with 2.2. The Stripe implementation between 2.2 and 2.3 is quite different to begin with and some of the issues we've fixed were new in 2.3. But based on what you've said, I'm pretty sure it should no longer be an issue. But upgrading will be necessary.
Click to expand...
Thanks for the update :)

So until I make the upgrade, is updating the "provider_metadata" field to the subscriber ID enough to make sure a recurrence will correctly apply? (going to be quite a few months until I can confirm!)
 
Automated triage: Not a bug

Thank you for reporting this issue. This report is about the Stripe integration in 2.2. In 2.3 it was replaced by Stripe Checkout, and webhooks now carry the purchase's own reference, so they no longer depend on the subscription ID being saved first. If upgrades still fail to apply on a current version, please post a new report with the payment log details.

This is an automated assessment. A member of staff may review and update it.
 
Back
Top Bottom