Several errors and warnings in the console

Thanks for reporting this issues. let me check and get back to you shortly.

Thanks for reporting this, I will check and provide a fix if needed.

irina.povjakel → made their first commit to this issue’s fork.

irina.povjakel → changed the visibility of the branch cherry-pick-bd6ee1e6 to hidden.

irina.povjakel → changed the visibility of the branch 1.0.x to hidden.

Hi,
I have opened a merge request for the fix.

james.williams → made their first commit to this issue’s fork.

I've spotted that the approach of overriding the ajax.beforeSend method cannot be relied upon, because Stripe returns the payment status asynchronously. So the beforeSend method itself got marked as async, which means that when Drupal is preparing to make the AJAX request, it calls the beforeSend method but also continues on to send it, regardless of what happens inside the beforeSend() method. So if the response from Stripe is that the payment has failed, the call to xmlhttprequest.abort(); may happen after the original AJAX call which submitted the form back to Drupal has already been made!

This also means that even when the payment succeeds, the usual AJAX submission back to Drupal that the submit button triggers has already been sent. If Stripe processes the request to it quickly enough, the payment will go through (as noted in 🐛 Payment Received, no form submission Active )
and Drupal considers the submission as completed, but the module javascript clicks the submit button in submitWebform(), causing another identical AJAX submission back to Drupal - and the Integrity Constraint Violation error like the one reported in 🐛 Integrity Constraint Violation Active . (And in fact, in the webform module's own issue 🐛 Ajax integrity constraint on uuid with autosave and ajax-compatible confirmation type Needs review !) That duplicate AJAX submission will therefore report an error, making it look like the payment didn't work, when actually it had!

In addition to all this, the override of beforeSend() means the payment request is triggered for any AJAX functionality added to the page - including the webform's button to go back to the previous page (as reported in 🐛 Previous button behavior like submit button Active ).

So basically, there are too many problems with this approach of trying to abort an AJAX request according to the result of an asynchronous call made whilst preparing the AJAX request. Instead, in my new commit to the MR, I've cloned the original submit button with an identical one that won't trigger any of the AJAX requests or submit the form, and hidden the original button. It has a custom click handler that will call the asynchronous handlePayButtonClick() method to make the payment request, and only once that returns successfully, will the form submission AJAX request be triggered for the original submit button.

This could still do with some more testing (e.g. what happens when a payment fails now? do we need to re-enable the new payment button to allow users to try again?), but Irina tells me it's looking good so far :) (We're colleagues so have worked through this challenge together!)

I've linked the various issues together here, but I'll make some updates across each of them explaining this again so the various followers can be pointed towards this potential fix.