techblog 

We have had occasional problems handling credit card payments via our payment service provider, DataCash whereby customers have received an error message and sometimes ended up paying twice due to retrying. We eventually tracked this down to a network timeout. What happens is that DataCash receives the data about the transaction from us, processes the payment, but is then too slow to send a response. So our client code times out. This means that payment has been taken from the customer’s credit card, but we don’t know as we haven’t received confirmation from DataCash. In order to avoid problems in the future, I changed the code to explicitly trap these timeouts so that we can get the customers to contact us before trying to pay again.

The difficulty then was how to test this. Datacash have facilities for testing all the expected responses such as “Success”, “Declined by Bank” etc, but there is no way to test for a timeout waiting for a response. The solution is to change the URL you are communicating with to one that will be blocked by a firewall. It swallows anything you throw at it and never returns anything, causing the timeout. In this case I am pointing my test code at http://testserver.datacash.com:43817, but you don’t even have to point at datacash if you don’t want to.