techblog 

At Nominet we use DataCash as our payment service provider. The idea is that they give you the relevant libraries to allow you to process various types of payments without needing to get tied up in all of the implementation details. We use them to process credit/debit cards and bank direct debits. This has generally worked pretty well for us.

We provide online services to our customers, we don’t ship physical products. So if we get a chargeback, we can simply stop the service. It’s a different matter if you’ve sent hundreds of pounds of electronics to a crook. This means that we’ve never signed up for the bells and whistles that are available to verify transactions because that would just force our customers to jump through a bunch of extra hoops.

Recently though, the big two credit card companies have been pushing their online security system, 3-D Secure. They are rolling this out over their different card types, making it mandatory to use online. As an example, since 1 July 2007 it has been mandatory for Maestro cards. The only get out clause is if you are in the process of implementing it.

So this has meant that we’ve had to do some development work to change all of our online credit/debit card processing to add this extra step. It isn’t a simple one either, as it involves redirecting the cardholder to their bank’s website, where they enter a password or somesuch, which then POSTs a bunch more data back to your site. It makes what was once a one-step process into a multi-step one.

So, we did the development work necessary and put it on our test systems. We used DataCash’s test server and tested out all of the various error messages it could send back. The test server is only set up to send a subset of the long list of return codes, but we were confident we could handle the common ones and display an error message for the obscure ones. There are in effect three classes of return code:

1. ok so far, redirect to this URL: …
2. ok so far, but this card is not setup for 3-D Secure, so continue without.
3. oh dear, something went wrong.

We were pretty sure we knew which codes were which so that our payment logic would work. The day of deployment came. We put the system live. Suddenly we were hit by a bunch of new codes that we weren’t expecting. Lots of people couldn’t make payments. The result is that we look like a bunch of amateurs who haven’t tested our systems properly. After a couple of phonecalls to DataCash I got hold of someone who knew what they were talking about. It turns out that there are 5 codes in the second class (”ok so far, but this card is not setup for 3-D Secure, so continue without”), rather than the 2 we had been expecting. So we were telling the user that an error had occurred when everything was fine.

Unfortunately, the piece of information we were missing is not mentioned anywhere in DataCash’s current documentation and the error code we were seeing is not sent back by the test server. So unless you are psychic, you are only going to find out the truth once you’ve gone live and you look like an incompetent idiot. I was told that these error codes are not DataCash’s codes, but are part of the 3-D Secure specification, so we should have known about this by reading about 3-D Secure elsewhere. Frankly I don’t believe this for the following reasons:

1. I’ve searched the web for a list of standard 3-D secure return codes. I can’t find one anywhere. The only places where I find something that looks promising, I am asked to sign up to a credit card company’s licence agreement.
2. It seems a little coincidental that in their list of return codes, the 3-D secure ones lie neatly in the range 150-189 with only a handful of numbers separating them from codes for completely different services above and below.

So if you are in the process of implementing 3-D secure with DataCash, here’s the secret that will spare you a lot of grief. The following codes all mean that the card is not enrolled in 3-D Secure and you should proceed without a redirection:

158, 162, 163, 173 or 183

Good luck!