Problem/Motivation

I can only make one payment with a webform with a stripe element (Stripe Credit Card). If I remove the element and re-create it I get another go.

I get an error in Chrome's console:
donate?ajax_form=1&_wrapper_format=drupal_ajax:1 Failed to load resource: the server responded with a status of 500 ()
ajax.js?v=9.2.0:513 Uncaught Drupal.AjaxErrormessage: "\nAn AJAX HTTP error occurred.\nHTTP Result Code: 500\nDebugging information follows.\nPath: /donate?ajax_form=1\nStatusText: error\nResponseText: The website encountered an unexpected error. Please try again later.Stripe\\Exception\\InvalidRequestException: This PaymentIntent's amount could not be updated because it has a status of succeeded. You may only update the amount of a PaymentIntent with one of the following statuses: requires_payment_method, requires_confirmation, requires_action. in Stripe\\Exception\

So for some reason it is trying to update the same payment intent each time.

Apologies if this should be in the Stripe module queue as I am not sure which module is causing this.

Steps to reproduce

Create a webform with an amount, name, email address and address part elements minimum. Add a Stripe credit card element that refers to these elements in the webform submission.

Validation on the card fields work. One payment can be successfully made.

After that one successful payment, each click of the submit button will generate the above Ajax error. This happens whether the card fields are valid or not.

If you then remove the Stripe element, save the webform definition, re-add the stripe element and save again, you can then make another payment.

Proposed resolution

Make sure code is always doing a new intent.

Remaining tasks

Unknown

User interface changes

No

API changes

No

Data model changes

Unknown

CommentFileSizeAuthor
#12 stripe_webform-page-cache-fix-3228485-12.patch2.28 KBsundhar

Issue fork stripe_webform-3228485

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

Rory Downes created an issue. See original summary.

rory downes’s picture

rory downes commented

I have just spoken to Stripe who tell me that the Stripe account needs to be verified and that it is not a module issue. I need to get back to our client to do this so we can verify this, so it may be a little while before I can confirm.

As soon as I find out if this what is causing the issue, I will update this issue.

rory downes’s picture

rory downes commented

We have verified the account which worked for a while. I managed to process several transactions successfully before it stopped working and I got the same message.

Stripe looked at their end and confirm that the account is not correctly set up and state that the issue is because the site is trying to edit and existing and completed intent rather than start a new one.

Can you look at why that would happen?

If I find anything more I will let you know.

piscos’s picture

piscos commented

I'm getting the exact same error.

Logged users can make payments without a hitch, but for anynomous users it only works for the 1st one. The following ones get the error and they're not able to pay (no matter what device or ip they use).

If I save the webform (I don't need to make any changes), it works but, again, only for the 1st anonymous user.

According to the Stripe log, all these anonymous users are sharing the same payment_intent id (that's why it only works for the 1st one), but logged users get a unique id so it works for them everytime.

Anyone has an idea on how to solve it?

piscos’s picture

piscos commented

I think I found the culprit.

I disabled the cache for the webform and now all anonymous users are able to play, so I guess the cache was making all of them getting the same payment_intent id.

rory downes’s picture

rory downes commented

Thanks @piscos. I am not sure that is the ideal solution but will allow us to use version 2. For now we have settled on version 1 of the module as it does not have the same problem.

Anonymous’s picture

Anonymous (not verified) commented

mickael@kaneva.io made their first commit to this issue’s fork.

goldin’s picture

goldin commented

@piscos I am getting the same error. Do you recall exactly the steps you took to disable the cache for the webform? I have not found an obvious config for that. Thanks.

edward.fuller’s picture

edward.fuller commented

We managed to get past this issue by adding this to our custom theme's THEME.theme file:

function THEME_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
  if (str_starts_with($form_id, '<start of webform id>') { // client occasionally made changes that altered form id
    $form['#cache']['contexts'][] = 'session';
    Drupal::service('page_cache_kill_switch')->trigger();
  }
}

sundhar made their first commit to this issue’s fork.

sundhar opened merge request !11

sundhar’s picture

sundhar
Location Coimbatore TN - India
commented
Version: 2.0.0-beta3 » 2.0.0
Status: Active » Needs review
StatusFileSize
new stripe_webform-page-cache-fix-3228485-12.patch2.28 KB
dr. gubó’s picture

dr. gubó commented
Status: Needs review » Needs work

The function stripe_webform_webform_has_stripe(array $elements) introduced by the patch in 12 contains a reference to an undefined function named "etbu_webform_has_stripe" and causes "undefined function" errors. Hiding patch file.

brian@graith’s picture

brian@graith commented
Status: Needs work » Postponed

Same root cause as #3318577. With stripe 2.0.1 the PaymentIntent is created while the form is rendered, so a page-cached form hands the same intent to every anonymous visitor and only the first of them can pay. #3572924 in the Stripe module creates the intent during validation instead, once per submission, which removes the shared intent without touching caching at all. It was committed to stripe 2.x-dev in February 2026 but has not been released.

Verified on stripe 2.x-dev with this module on Drupal 11.4.7: form loads create no intent, and payments complete.

The approach in MR !11, invalidating cache tags on every submission, would not fix the cause, and as noted in #13 it calls an undefined function. Postponing on a Stripe release, after which composer.json here should require it.