Help! Transactions submission!

sledgeweb

I'm having a problem with a transaction system. The problem is, people are being charged multiple times for the same transactions.

I've runs some tests and found the following.

On the page you enter your payment info on, if you hit the submit button multiple times you get an error.

The next page submits the info to authorize.net and if succesfful, sets a session variable "paymentComplete" to 1. If you try to go back to the submission page, it checks for this session variable to prevent duplicate charges. If it is set to 1, it forwards you to the receipt screen.

After the results are returned from authorize, you go to a third page, which prints the success confirmation or failure. If there is a failure, the 3rd screen ask for new payment information and starts over.

The problem is, on the first page, if you hit submit button multiple times, the payment is sent to authorize multiple times. A successful payment goes through, but after that, it returns a duplicate error. Apparrently, all this happens really quick, so the paymentComplete session variable is never set to 1. Therefore, you can even go back and resubmit more transactions.

So... the major problem is, how can I keep them from hitting the submit botton more than once? I thought of having a page inbetween the submit an the transaction, but... I couldn't output anything to the browser before doing a header("Location:")... so, it wouldn't load the page until the authorize transaction went though anyways.

Help!

AstroTeg

I've got to say its been a while since the last shop I was at had to deal with this problem. This is from memory...

We set a session variable the moment the form passed validation BUT had not gone off to the processor. It was at this point the script knew it was a "go" / "no go" to go to the payment gateway. If the form failed, we'd just reshow the form with errors. We'd also check the session to determine if the same form had been submitted to us more then once (we'd abort the script if it was). If this happened, the worst that would happen is the transaction goes through but the user is stuck on the check out page. They'd eventually get an email receipt with directions to their download.

I want to say we also had some JavaScrpt that triggered on the "onSubmit" event. We'd increment a JavaScript counter for each onSubmit. Obviously, if the counter is greater then 1, then the form has already submitted so don't resubmit it. I think thats what we did. But its been so long that you tend to forget about the little details like this.