Multiple notifications sent when refreshing confirmation page

A client just reported getting multiple copies of a notification over a few days. Could this be if the person had bookmarked the confirmation page or some other way kept going back to it?

Hi,

I have a similar issue initially reported by my client and so I hooked myself up to receive notifications from the same form.

The first notification that I got arrived as it should but the second arrived twice. My client reported the issue when he received 6 notifications for the same entry. He received 7 and then 8 to my 1 and 2.

I don't think that this is a browser issue.

Thanks for your help

Hi chris,

The link is http://www.offshoreinvestmentguide.eu

Thanks

Philip

I had a customer fill in a form including a payment in the evening. All went through ok. The next day the customer apparently went back to their device and refreshed the browser (Safari left open from the previous day with the confirmation text still showing)- bang another payment gets processed and another entry created.

The noduplicates checkbox sounds good but I can see how to apply it in my situation. Customers return and fill in forms and make payments all the time so I don't want to stop that.

Is there any way to obliterate all the post data once the form is submitted successfully the first time so that even if they refresh - use the back button or whatever there is no hope of the submission / payment going through again ?

I am thinking of switching to a re-direct to thankyou page to see if that helps. Feeback from customers who have been charged twice is "fix your website" and even if they may technically be the cause they don't see it that way!

It sure would be great if once a form was submitted successfully it couldn't be submitted again!

Ideally I would like to stop people resubmitting their forms no matter what.

I thought about generating my own unique tran id and populating a hidden field dynamically and then turning on no duplicates for the hidden field. That should work shouldn't it ? - but I see that a hidden field does not support the no duplicates option.

Not allowing the same form to be submitted twice by accident through browser refresh / back button or whatever seems fundamental but given it isn't built in to gravity forms would the above idea do the job and if it will could you point me in the right direction on how to implement noduplicates on the hidden field.

If there is some kind of jquery magic that achieves the same result (stops resubmission on browser refresh) that would also be great if anyone can point me to it.

I think refreshing any browser when you have the confirmation option set to text on a confirmation page is resubmitting the form data. Definitely on ie9 as well.

I am happy to test 303 redirect (for my text based confirmation) to see if it stops form data being resubmitted when users click the browser refresh but how can this be implemented ? Is there some filter or hook - could someone at gf post the code ? If I switch from the text confirmation to a page confirmation does that use a 303 redirect?

Thanks for posting the reading. It seems there are a number of ways to stop accidental resubmission and that it can be done if you want to. Is it on the road map at gravity forms?

Scratch that, although GF generates a unique ID for a form entry, it doesn't actually store the bugger! If it did, it would be a simple matter to grab the saved lead with that unique ID; finding it saved would indicate that the form has been processed, so don't do it again (in fact, GF ought to be doing that itself).

@Chris Hajer: once an entry has been saved, is there a way to test for that if the page is refreshed? A cursory look here hasn't found such a way. Storing the unique ID of the entry would help.

I could work around this by storing the unique ID in my plugin's field data (thus complicating storage / retrieval of that data) or storing it in a separate, meta field (probably better as easier to search on), but...

I can't actually reproduce the problem here on my browsers. I've tried a few times, but can't seem to make it submit another payment attempt; refreshing either brings up the confirmation again, or brings up a blank form. Steve, maybe you could email me the XML export of your form so that I could have a play with it. Maybe I need to try it specifically on Safari, which I have an old (5.11) copy on Windows or the mobile version on iPad.

cheers,
Ross

@tcs: I just noticed I had AJAX form submission turned on, which avoids this problem.

So, quick fix for most users: use AJAX form submission and they can't accidentally resubmit the form. Of course, this doesn't resolve the problem for users with JavaScript disabled / broken / limited by policies.

I have a working fix, I would like to get your help testing it please. You can download an alpha of v1.2.3 from this URL and test.

http://www.webaware.com.au/files/gravityforms-eway-1.2.3-alpha1.zip

What it does is save the entry's unique ID in a meta value for the form, gfeway_unique_id, and checks to see if that value is present when validating the credit card information. If it finds it there, it invalidates the form with the following error message on the credit card field:

Attempt to submit form multiple times; already processed.

Please let me know how you go.

cheers,
Ross

@tcs: thanks for testing, and good idea about custom error messages. I'll see what I can do this week, before I release this fix. Regarding multipage forms, it should already work OK because I set the form page to return to the page with the credit card field when invalidating it. This fix will work with both one-off and recurring payments, because the check is done before determining which payment type is required.

@Gravity Forms: Steve is correct, the AJAX form method should really fall back to regular form submissions when JavaScript is disabled. For stopping form submissions, the unique ID should be a sufficient test if the website is single-hosted. I don't know how/whether you would add this to Gravity Forms core, but I'll be maintaining this fix in my plugin in the meantime (to be releases this week).

cheers,
Ross