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

[K a M a L]

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

 

[K a M a L]

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

 

[cdub]

I got this for the first time randomly today

 

[nates]

I got In contact with stripe about the recent webhook error they say it’s an error on XF SIDE!

 

[benFF]

Was this ever resolved?

I just had two pop up today.

 

[Chris D]

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.

 

[benFF]

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

 

[Chris D]

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.

 

[benFF]

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.

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!)

 

[Chris D]

That should work yes. Not sure why it isn’t the case already though.