Force submission with payment success
-
We are using forminator for some (really complex) forms.
Our main issue is that the payment (stripe integration) is the last thing on the form and is mandatory, but sometime, people pay, but do not submit form !
That’s understandable as, most of the time, payment flow is made so that your order is validated right after payment.
So, is there a way to force form submission right after payment succeed ?
-
Hi @sp4rky35 ,
I hope you’re doing well.
Could you confirm if you’re using a form with page breaks/pagination? https://wpmudev.com/docs/wpmu-dev-plugins/forminator/#page-break
If it’s not, you can try adding it as adding pagination, at least for the payment field, as adding Stripe to the final step without visibility rules should make it required to be able to submit the form.
I hope to hear back from you soon.
Best Regards,
Williams ValerioYes we use them, but the issue is the other way around. People must pay to submit form, that’s fine and working as expected. The issue is sometime people pay (this is the very last step) but do not submit form after payment. This is understandable as when you buy something on internet, successful payment usually means order is validated without extra step.
I would like to either :
- Auto submit form when payment is validated
- Be able to catch the successful payment event and add some popup to warn users (or auto submit ^^)
Hello @sp4rky35,
Hope you’re doing well today! Thank you for sharing additional information.
I tested a Stripe Payment on my lab site but could not replicate the issue yet. But it sounds similar to one of the reports we noticed recently.
Could you please confirm if you have noticed the issue specifically while using the 3D-Secure workflow? Where the browser opens another pop-up to validate the payment?
I am mentioning this because Forminator saves the entry before the payment handling on the Stripe end is fully completed. In such cases, if there is a payment failure at the Stripe end, the entry is removed as a part of cleanup. However, in case if you use 3DS cards, the objects on stripe may still pass, but the browser round trip to confirm the payment could fail causing the cleanup to trigger on the Forminator end, causing the payment to become successful on Stripe yet causing a missing entry on Forminator submissions.
Hence we wanted to take a closer look at the form itself to test and troubleshoot the scenario. Would it be possible for you to export and share the form with us?
To share the form export
– Navigate to the “Forminator -> Forms” page in your site’s back-end
– click on a little “gear” icon next to the form in question
– select “Export” option
– copy given export code and paste it at https://pastebin.com
– include link to that paste in your response below.Note: this export will not include any data that is already submitted – they’ll stay safely on your site and we don’t need them anyway.
Kind Regards,
Saurabhcausing the payment to become successful on Stripe yet causing a missing entry on Forminator submissions.
Sorry, that’s still not my issue 🙂 My issue is that, sometimes, people will pay (and this succeed) but will not click to the final form submission button. This cause some successful payment without corresponding registration.
After discussing with these people, every time this happens, they shared they were surprise they need to submit the form after payment, as usually (let’s define usually by “whenever you buy something on internet”) the payment is the very last step which confirms the order as soon as it succeed .
I can still share my (quite big and complex) form, but this is easy to reproduce with a single stripe widget form. You can pay and still have to submit the form.Hello @sp4rky35,
I hope things are going well for you.
My issue is that, sometimes, people will pay (and this succeed)
It was really odd because, before clicking on the final form submission button, Forminator would not collect the Payment.
I tried replicating the same issue by creating a form with these details:
– Page1: Contact Details & Add Items for purchase
– Page2: Shows total amount with Stripe Credit/Debit Card Widget
– Page3: Order Summary and submit.
If I add details to page two and go to page 3, we still don’t get payment.It would be really helpful if you could share a video on how we can replicate the issue on our end with the default form, or you can share the form export file.
We look forward to hearing from you soon on this.
–
Kind Regards,
Imran KhanI’m not sure how to replicate it BUT I analyzed our payments and ~ 2% of submission had the issue (2% of 250 submissions).
I reached some of them and 2 told me that they had a generic error message during submission (the others did not remember / didn’t answer), but the form asked for the payment again. In meantime, I got a payment but no final submission.
My guess was that there might be a race condition in code like : payment is processed, then form is checked and if it fails, payment is not canceled but an error is returned. So I tried to dig a bit into the code, and here is my analysis (Forminator 1.57.2 + Forminator Stripe 1.5.1) :
In
handle_form():- Line 1696, stripe payment is processed
- upload, fields processing, email are processed
If an exception is raised during one of these step, the
catchl1727 throw an error message but do not delete / cancel anything > the payment remains.After some more research, one fix might be to not immediately ask for payment but :
- create the intent in manual mode . as far as I can tell, the intent is created without
capture_method: manualset (library/fields/stripe.php:701), so it defaults toautomaticwhich immediately process the payment. Withmanualmethod, stripe only authorizes and holds the funds on the customer’s card without charging them right away. - capture payment after the form has been validated (right before … or right after
save_entry_fields)
I’m not sure what the exact error is. It might help to have some debug mode that logs exact error / context in php error log, so we do not only get a generic error message.
Hope it helps, but I may be absolutely wrong here as well.
Hello @sp4rky35 ,
I hope you are doing well, and thank you for the details.
Based on what you’ve shared, what you’re seeing matches the current Forminator Stripe flow. In this flow, Forminator saves the entry before the Stripe payment handling is fully completed. If the Stripe step is then treated as failed or incomplete, the payment failure cleanup can remove that saved entry before notifications are sent.
The risk is amplified by an SCA/3DS “requires_action” style flow happening inside the Google app’s in-app browser on iOS/Android, where the browser round-trip can fail even though Stripe-side objects (customer) have already been created. If the plugin then deletes the entry on a non active/trialing outcome, you can end up with exactly what you described: a payment with no WordPress record and no notification emails.
At the moment, there isn’t a supported way for us to “reattach” an existing Stripe payment back into a Forminator entry, and we wouldn’t recommend manually inserting rows into wp_frmt_form_entry / wp_frmt_form_entry_meta as it’s very easy to get the entry structure/meta mapping wrong and create more issues.
For reconciling the current orphan, the safest path is to use the Stripe dashboard as the source of truth for that customer’s payment (ID, invoice, payment intent, timestamps).
As an immediate mitigation, restricting the available Stripe payment methods to ones that provide immediate confirmation can reduce exposure to redirect/long-running flows (Stripe’s payment element supports multiple methods, but not all methods behave the same during confirmation). This section of our documentation also calls out the “immediate confirmation” requirement when troubleshooting payment methods: https://wpmudev.com/docs/wpmu-dev-plugins/forminator/#new-stripe-payment-method.
Please note that restricting payment methods can reduce exposure to redirect or long-running confirmation flows, but it does not fully eliminate the risk because card payments may still require SCA/3DS depending on the issuer and region.
Our developers are already aware of this scenario. They will try to improve the payment process in future versions. However, I can’t promise an ETA.
Kind Regards,
Fida Al HasanHi, thanks for all the details.
Reconciliation is already done, from stripe dashboard as you said.
I was investigating a bit more and noticed than :
- None of the payment which failed used google pay (apple is already deactivated). They all used bare credit card
- Most (almost all) of them did not trigger 3ds
- The most interesting thing, they *all* submit payment confirmation more than once on the same PI (call to
/v1/payment_pages/cs_live_xxxx/confirm) . The first call succeed, the others (sometime up to 3 more) failed with error 400.
Is this the same issue you are already investigating ?
Hello @sp4rky35,
I hope things are going well for you.
Yes, our team is investigating the same issue, and they will soon release an update to improve the payment process and submission workflow. As mentioned, we currently do not have an ETA to share with you, so you can rely on the Stripe Dashboard for now. However, an update will be provided soon.
I appreciate your patience and understanding regarding this issue.
–
Kind Regards,
Imran Khan
You must be logged in to reply to this topic.
