My suggestion is to 1) pick a reliable gateway and 2) pick a gateway that allows for pre-settlement auditing.
Double posting is a fact of life when two applications interface to each other. You want a reliable gateway to minimize the occurrence. Because double postings can occasionally occur, I always recommend pre-settlement auditing to make sure application A balances with application B.
A gotcha in the payments industry is when you double post, you get dinged a discount rate and transaction fees -- something like 2.00% + $0.35 as an example. If the double post makes it through interchange, and you need to refund one of the transactions back to the customer, you don't get the original fees back and you will most likely be dinged additional transaction fees (the $0.35 in sample rate). Using my rate example, if your average ticket is $10, your average processing fee is $0.55 ($10 x 2% + $0.35) so a refund will cost you the $0.90 (the original fee that does not get refunded plus another $0.35 for the refund). Now if your average tick is $100, now your approaching $3 for each double posting. If you pre-audit and stop the double posts before interchange, it'll only cost you the single $0.35 fixed fee for the double auth.
Now some API's are better than others and some can stop double postings all together. I still recommend the pre-settlement auditing if notithing else, for volume trending and fraud prevention. Again, a reliable gateway should have a solid API that can prevent double-postings.
While the gateways we work with do a decent job of protecting us from double payments recently (rarely though) our application has been posting the form data twice (sometimes more) virtually simultaneously to the gateway APIs. Due to the quick transaction requests, the APIs cannot always catch the double post. I would like a coldfusion server side solution/architecture/process to never let this happen. Any suggestions for this problem (even if just high level) ? I figure this has been an issue for other people too. Thank you.
Yup, we had just this issue a couple of weeks ago - turned out to be caused initially by a customer who thought you had to double-click hyperlinks and buttons in order to get them to work. We fixed the issue twofold:
We then had a variable in the client scope called client.processingPayment or similar - the very first thing done on the payment processing page was to check that was not set, then set that to true. That way, even on the quickest of double-clicks/duplicate requests the first will set the flag, and the second will not run. Setting it at the bottom of the processing page was not enough, the few seconds taken to process the payment was enough to make the difference - if the second request was called before that first finished it would still run again.
Hope that helps, it certainly helped us.
That is great. I was more or less adding the same solution when you posted your comment. So that is great. It looks like it is helping a bunch. Thanks! It made me feel like I was on the right path. -P