ASP .NET switch bounce

[VectraMan]

Okay so "switch bounce" I'm sure is the wrong term, but I mean when the idiot user enters his credit card details, presses the pay button, presses it again, and again, and again, and then you end up with four orders.

Is there a good way of stopping this? I was thinking I'd disable the pay button on click with some client side code. I found this off the net:

PayButton.Attributes.Add("onclick", "this.disabled=true;" + Page.ClientScript.GetPostBackEventReference(PayButton, "").ToString());

Which works. The problem is I have some validators on the form, and if they fail the button still gets disabled.

So my second thought was to disable the button as part on the on Submit:

            System.Web.UI.HtmlControls.HtmlForm frm =(System.Web.UI.HtmlControls.HtmlForm)this.FindControl("DoDirPay");
            frm.Attributes.Add("onSubmit","PayButton.disabled = true;");

Which adds the PayButton.disabled line to the client side onSubmit function after the validation. Which would appear to be the right thing, except the button disable doesn't work. I thought it might not know about PayButton at that point, but I tried changing PayButton.disabled to Wibble.disabled, and that came up with a script error, which proves it at least knows what the PayButton object is.

Presumably all you professionals must solve this problem twenty times a day. So what's the best approach?

Ta.

 

[TheBigYinJames]

Presumably all you professionals must solve this problem twenty times a day. So what's the best approach?
Ta.

Disable the form submit rather than the button itself, by adding an onsubmit attribute to the form itself in javascript.

 

[Durbs]

presses the pay button, presses it again, and again, and again, and then you end up with four orders.

Most important thing is the above should be handled within the function that actually creates the transaction record. I do that by having a transaction ID already associated with that particular cart instance using a GUID. This is added to the transaction record so on any purchase record i first run a check to see if that particular ID exists in the sales DB, if it does, its not added. This check should never return true unless, as you say, a user somehow bypasses validation and submits multiple times.

As you've seen, disabling controls can easily lead to unwanted results such as the user being left sat looking at a page with a disabled button unable to do anything or the postback simply not occurring as the control is disabled.

Can try to check the validation status like: http://msmvps.com/blogs/anguslogan/archive/2004/12/22/27223.aspx

But as said above, use belt-and-braces approach and check at a lower level too to prevent duplicates at the time of DB write.

 

[VectraMan]

Can try to check the validation status like: http://msmvps.com/blogs/anguslogan/archive/2004/12/22/27223.aspx

Thanks. The code in that article does do what I wanted: does the validation and then disables the button.

But I take the point about making the system more resilient, so I've made sure the same thing won't be submitted more than once.

This system is using PayPal, and the issue was one poor customer who submitted four times, and each time it seemed PayPal took the money but didn't reply.

 

[Durbs]

This system is using PayPal, and the issue was one poor customer who submitted four times, and each time it seemed PayPal took the money but didn't reply.

Been there myself with Paypal IPN. Made a change to my stores IPN handler and seemed minor so didn't test it properly.

Paypal's IPN server no longer got an 'OK' response from my IPN script so kept resending the post on a sliding scale of frequency.

Unfortunately, my script was happily processing these incoming posts and whilst not creating any new transactions (due to the check listed above) it WAS sending out a "Thanks for your sale, you've purchased..." email to the customer each time the script was hit.

Only realised when i got a frantic note from a customer assuming he'd purchased the thing like 20 times and was being charged accordingly. Doh.

One of those mistakes you make only once.