Head of Ecommerce at Lovehoney
29 November 2009 21:43pm
Hi there, one thing I'm looking at at the moment ( I might even write something for econsultancy about it) is Card Declines. It would seem that (presumably for economic reasons) this is on the up.
Currently, we use HSBC's epayments API to process cards, but when a card is declined, the response we get back from the API is always the same - Decline General. Response Code 50. It doesn't give me a lot to go on, to point the visitor in the right direction.
However, digging into the epayments service, I can see there's Card Security Responses, AVS responses, all sorts, let alone declines where the card in on a security block.
How do other people handle card declines? I'm specifically looking at improving conversion rates for visitors who've experienced a decline. This currently lies at around 75% for us, but I'm sure I can improve it.
Is it best practise to interrogate the API somehow and return to the visitor with a reason for the decline? I can imagine there's security issue here if I say "hey, everything else is OK, but you're CV2 number is wrong", as they've then got 999 more guesses, I expect.
Also, how do other people handle partial matches on the AVS side of things? From doing a little bit of investigation, it seems that a simple match on the name ( something you'd get form the front of the card ) is enough to fire a partial match. But I worry that requiring an exact match would potentially turn away good business. Again, I doubt this is something I can message the visitor with.
Anyone have some good advice here?
Strategy Director at Blueleaf
29 November 2009 23:13pm
I don't know the API so just wanted to ask - are you interrogating the API after the event (for instance on a tidy up process) or is that the information you get in real time when the card declines? Only reason I ask is that normally at the point of failure a lot more information is given from our payment providers (for instance Datacash) and so you can do a lot more in terms of tracking why failures are occuring.
In terms of best practice we have found that the clearer the error message the better as people can sort out the issue themselves more easily. For instance common miskeying errors could result in Credit card number too short or Credit card number too long messages - not sure if you have these covered.
On the security side though, you're right about the detail, it's a tough line between helping and making sure they will pay! I think a friendly error message such as
"We're sorry but there was a problem with your payment. Could you please double check all your details and make sure your billing address is the one registered to that card"
Or something similar is the best way to help without giving too much away.
Some thoughts on AVS:
- You could perform a full AVS match if the card is in a high risk area (Africa for example) as there more likely fraud from CC's in that location, otherwise, perform a partial match
- If CVV2 and 3D Secure are turned on, I would suggest that AVS is less important to have a full match on
Finally, good news you're tracking in this level of detail, a lot of merchants don't track this well on their purchases, let alone their declines.
Cheers, hope that helps even a little bit!
Director and Co-Founder at 4Ps Marketing
30 November 2009 08:51am
If you guys run PPC make sure you are analysing the time of day when the declines appear. On some of our retail clients they experience a lot of declines from 1:00 am – 3:00 am. Some quick analysis can quickly show you if you should suspend transactions at that time.
There is also a lot of other deeper analysis you can do from a wider SEM point of view.
Matthew PhelanAccount Director4Ps Marketing
CEO at Econsultancy
30 November 2009 09:54am
We noticed the number of card declines going up recently too (for transactions on this site) so looked into it.
We use Datacash as our payment gateway but, of course, they refer us on to the bank(s) to try and find out *why* transactions are being refused. And they, in turn, don't tell you much because (along the Google search algo argument line) they can't say too much because it would help fraudsters to release exactly how their fraud detection works. But our suspicion was/is that the banks have simply tightened up their fraud detection because they are very risk averse at the moment (you try asking for a loan...) so only want 'safe' cash.
We too have a problem with the 'not very helpful' error messages and don't seem to be able to do that much about it. In most cases there generally is a problem with the users card where the payment is rejected but we can't give them any helpful messaging e.g. you've maxed out your daily spend limit (which is very common).
However, something we have "discovered" (by just trying it rather than anyone telling us it was the right thing to do) is that our previous payment process appears to have been tripping a fraud filter that it didn't do in the good old days of bountiful credit. So what was working fine started to cause card declines on perfectly good cards because the transaction was rejected as "fraudulent".
We used to do a 'pre-auth' on the card (initially of £1 and then 1p but the amount doesn't actually make any difference) on the payment confirmation page in the basket i.e. before taking actual payment. This is like a "fake transaction" to 'ping' the card to check it will actually work. Essentially you request authorisation from the acquiring bank for a transaction of an amount to make sure the card will work. You then void this amount when you make the actual transaction. The advantage of this is that we can then alert users to problems with payment/their card before we try to make the actual transaction.
However, the disadvantage, as it appears to turn out, is that you end up appearing to make 2 transactions on the same card within a short space of time which can look fraudulent to the bank. So they approve the first 'pre-auth' and then reject the actual transaction.
We then discovered Datacash have a Pre-registered Card Service which means we can 'ping' Datacash rather than the bank and only make the final payment request to the bank.
Since changing our payment process the number of card declines has reduced a lot. From a low point of 15% of transactions declined in a week to more like 0% now... We don't really need to worry too much about fraud as we don't sell physical goods so there is really no cost of sale, however we certainly were 'leaving (good) money on the table'.
I'm not sure *how* exactly your payment process works but the above *might* be relevant / worth checking.
30 November 2009 09:58am
p.s. yes would be great if you could write something up as I think it is an important area which 'marketers' or 'commercial' folk don't typically want to have to grapple with but is very important. A bit like site speed / tech infrastructure - another vital area that affects user experience and therefore sales and commercial KPIs but which commercial/marketing bods seem uninterested in as a 'technical' thing...
I'm seeing this thread top of Google already for "card declines"?
30 November 2009 10:13am
@Ashley, that pre registered service from Datacash I didn't know about - very useful thanks for your input.
30 November 2009 10:29am
Bit strange that Datacash themselves didn't point it out to us even when we were enquiring about the challenges we were having. But it seems to be working well.
30 November 2009 15:23pm
hey, this has been a bit busy today!
We also have a 2 step process. We Pre-auth first for the total amount, then when the goods have been delivered, run a Settle for the transaction which takes the funds. It works pretty well for the most part, but it's not an ideal process as sometimes the Settle wil be declined (normally a card block) but it's only a transaction or 2 a month at worst. However it's a good messsage to tell the visitor that we don't charge their card until we're certain that everything has been delivered ok.
It also means we are able to implement a really great buffer system that holds these commands in a queue should the payment api go down.
Since we're selling food, hand delivered, and not y'know, playstations, fraud isn't really an issue, given my customers ( which you should know about by now!) it's normally something entered incorrectly, a billing address issue (for example, if a son or daughter is order for their parents) etc. We check as much (LUHN, Bin match etc), as we can before sending off to the bank. Where there is a problem,I would love to be able to point them in the direction of what's wrong.
Fortunately, we also offer Cash/Cheque on delivery, which is a good final option if the card isn't working.
We're not talking lots here, yesterday I tracked 30 unique decline events, 22 of which eventually converted. But the other 8 bug the hell out of me. My game is repeat business, so turning anyone away isn't ideal.
I can't think of anyone who gives messages other than the standard decline? There must be a best practise guide to this somewhere!
r.e. the Pre-registered card stuff, we're using a similar tokenised card payment system in our B2B business, where speed of sale in an issue. It's not a bad idea to get this in the B2C side as well.
01 December 2009 18:27pm
A bit of an update - now that I've got the API documentation and read through all 193 pages of it......we can get the AVS and CVM responses "live" during a transaction.
So, all I need to figure out is, is there precedence, has someone else done this?
Anyway, on a side note, did discover a cause for a decline that we hadn't figured out. Turns out there's a second message it the XML that gets returned ( undocumented, I might add ) that gave us some feedback about card start dates.
Off to write something about the importance of handling declines properly.
01 December 2009 18:31pm
Sounds really interesting. Yes 'card declines' deserves real attention! Fancy writing a 'best practice' guide for us on it? ;)
Free market research on digital marketing
Daily Pulse: award winning newsletter
It takes 30 seconds to register