Fixed Stripe payment provider intermittently fails due to order of events received

[Liam W]

Affected version

2.0.4

For some reason, the Stripe webhook charge.succeeded doesn't contain any metadata, so purchases aren't applied.

Liam

 

[Chris D]

My immediate thought was that this was related to a change we made in 2.0.3, but I actually don't think it is.

That change only blacklisted certain events (one, actually) from going any further, and just logging them for info, rather than letting them get as far as processing as an error:

$skippableEvents = ['payout.created'];

So, this hasn't actually changed for some time. Are you sure the charge was created in XF?

I'll be able to do some proper testing later but any more info you can provide in the meantime will be helpful.

 

[Liam W]

It were definitely created in XF, as the customer.created event that got sent for the purchase has the metadata.

 

[Chris D]

Recurring or one off purchase?

 

[Liam W]

One off.

Liam

 

[Liam W]

Having looked into it, I'm currently thinking that somehow the database transaction with the customer creation log hadn't yet been committed by the time the Stripe charge succeeded web hook had been received (about 7 seconds later, based on the log_date fields). This feels somewhat unlikely, though...?

Liam

 

[Chris D]

It's possible. We have actually seen a scenario where one webhook was received before another despite the first one received being sent last.

 

[Liam W]

Just an update, another payment went through without issues without anything being changed, so it looks like I was right in thinking that the Stripe callback was received before the database transaction had commited.

Maybe it's worth allowing 1 retry for webhooks if the relevant transaction can't be found initially?

Liam

 

[Chris D]

Yeah I've been noticing this myself.

It's kind of ironic. With PayPal we have a problem with IPNs not being received quickly enough. With Stripe, they're coming too quickly!

I've had a vague idea on how to handle this so hopefully something to report in the next round of bug fixes.

 

[Chris D]

Fairly sure this has resurfaced and that makes sense because the original fix was reverted because it was made in conjunction with the changes to make use of Stripe's Billing API.

We'll need to look into re-applying at least some of those changes.