I've seen a couple topics that talk about this but the answers in them were fairly unclear and unsatisfying.
So here's the problem, if a customer mis-enters information for their credit card, they are still charged for the transaction but then the transaction is voided.
Hypothetical Situation:
1. Customer is purchasing a $50 item off of my website, and they mis-enter their expiration date and zip code.
2. My site tells them to fix the exp date, because that's the first error that shows up in the response from Authorize.net
3. Then they have to fix their zip code...
But every time they submit changes, a new transaction is created, resulting in three $50 charges, until the first two $50 charges are process as "declined" the customer has three transactions in their statement...effectively holding up $100 of their money.
There has to be a way to check valid credit card info without having customer credit tied up for more than an hour.
I tried the following:
1. AVS and CCV verifications which automatically decline transactions with faulty information.
2. Removed AVS and CCV verif, but used the response codes from the response array from Authorize.net to automatically VOID transactions where there is an AVS or CCV mismatch.
Both methods still charge the user, and it takes up to a couple days to remove the "pending transaction" from my customer's bank statements. So for several days, their credit is tied up...
Solved! Go to Solution.
04-16-2010 08:37 PM
Your processor probably doesn't support $0.00 auths yet. Try doing auth only for $0.01. Be sure to void it when you're done.
Accepting payments that accepts incorrect CVV and AVS in no way hurts your websites credibilty. Besides the fact that no one bases credibility on those factors, it's very common for users to enter incorrect information for a variety of legitimate reasons. Its happening is no big deal.
FYI, you cannot store CVV information. It is a violation of PCI rules. You'll get in big trouble if you get caught. You should also encrypt the expiration date if you can.
04-17-2010 03:55 PM
If you use the Auto-decline feature that Authorize.Net offers then you're not really getting declines, you simply are declining already approved transactions which makes things much more technical and problematic then a true decline. Since they aren't really declined but you are simply making them look declined by reversing already approved transaction you are stuck with some card issuers holding those funds until the reversal clears. It's the cost of using those features. It's yet another reason why I don't recommend declining transactions based solely on AVS and CVV. In your case it sounds like a lot of legit orders are failing and your users are suffering because of your strict, and probably unecessary, policies. Have you considered not declining these transactions based solely on AVS and CVV results? It sounds like you're hurting more legit customers then stopping fraudulant ones.
FYI, your first hypothetical scenario is unrealistic. Authorize.Net won't throw an error for an expiration date unless the card is expired or in the wrong format when it is submitted to them. That should never happen because the website's code should catch that before it ever gets sent to Authorize.Net. Not to mention if the card is expired the transaction may still be approved in which case there is no need to process it again.
04-16-2010 09:43 PM
It'll throw a AVS error for an expiration date if the expiration date does not match the card.
It's not necessarily that I'm hardcore against fraudulent charges, I'm more trying to gather data on the location of my purchases, since I'm offering a service that only operates within my city, zip codes will mostly be confined within my city.
For AVS the only things it checks for is a exp and zip code that match the card.
And then the CCV has to match the card.
If the card number is correct and any of those three things as incorrect (exp date, zip, or ccv) it will still process and show a pending transaction in my users' account. The transaction will automatically be declined, but it still ties up funds.
Does anyone know how often someone mis-enters information? Maybe I can just setup blocks on my website to only allow a person to mis-enter information for a card 3 times, and then they have to wait a couple days or something.
My service is fairly cheap, so I don't expect people to be extremely mad if there is two pending transactions (one that's auto-declined). However, I'd like to maintain as little hassle as possible, while still confirming those three aspects:
exp date, ccv, and zip code
04-17-2010 01:30 AM
AVS error if the expiration date is incorrect? That sounds very odd. Is it an actual error? Or do you just get an AVS mismatch? Those are two very different things. An error means nothing should be processed as it is an error. An AVS mismatch just means AVS was caused to fail although I am unsure how the expiration date would cause this since it is not used in address verification.
It sounds like what you need to be doing is AUTH_ONLY transactions for $0.00 until your customer's credit card passes AVS and CVV checks. Then process the transaction for the full amount. That way you aren't holding up their funds for a day or two.
As far as how often someone mis-enters information, I have yet to see stats on that. I would think they are in the minority based on the AVS and CVV stats I see in sites I monitor.
Some advice from someone who has done quite a bit of ecommerce work:
1) If your average transaction is small in size you shouldn't be making your customers jump through hoops to make payment.Your exposure to risk is so low that your chasing a red herring.
2) You have to remember, a card with failed AVS and CVV and incorrect expiration that gets approved is no different then the same card getting approved with correct values after multiple retries to get it right. The only difference is each time you tell your customer to try again you risk having them walk away. Your risk of fraud or chargebacks is definitely not any lower and possibly even higher.
3) Having AVS and CVV correct makes no difference to your merchant account provider or the card issuer. They're just tools to help you determine risk. If you keep rejecting the same card until they're right, even though they're getting approved by the card issuer, you're only doing so to make yourself happy. It literally is not helping you in any other way.
4) By now you should be realizing incorrect expiration dates and AVS and CVV failing does not mean a card is fraudulant. This is plainly evident by the fact that the same people whose expiration dates, AVS, and CVV checks are failing keep making payment until it works and those transactions are fine. Make your life easier, your customer's lives easier, reduce your chargeback exposure, and increase your success rate and stop declining failed AVS and CVV transactions.
04-17-2010 07:26 AM - edited 04-17-2010 07:28 AM
Oh wait you're right it's the CVV, I get the following reponse:
1) 2
3) 2
6) Z (AVS)
39) N (CCV)
Also, you can't run an AUTH_ONLY transaction for $0.00, doesn't allow it. Something like that would be the solution I'm looking for...
Also having no checks as to false information, doesn't that hurt the credibility of your website? If it accepts mis-entered information and continues to process seems to me like a hoax of a site...
And really I want the information i store about my customer's card to be correct: exp date, zip, cvv
04-17-2010 12:40 PM
Your processor probably doesn't support $0.00 auths yet. Try doing auth only for $0.01. Be sure to void it when you're done.
Accepting payments that accepts incorrect CVV and AVS in no way hurts your websites credibilty. Besides the fact that no one bases credibility on those factors, it's very common for users to enter incorrect information for a variety of legitimate reasons. Its happening is no big deal.
FYI, you cannot store CVV information. It is a violation of PCI rules. You'll get in big trouble if you get caught. You should also encrypt the expiration date if you can.
04-17-2010 03:55 PM
oh no yeah, whoops...i don't store the cvv, just the exp date, zip, and cc #
04-17-2010 04:27 PM
If you're going to store the credit card numbers make sure you are PCI compliant. This incliudes encrypting the numbers themselves. Or consider using CIM and avoiding the hassle.
04-18-2010 12:30 AM
Yea the numbers are encrypted, and I'll take your advice and encrypt the exp date as well, thanks for your advice I think I'm going to go with the 1 cent verification checks.
04-18-2010 02:34 PM
Why in the world do thise features exist if you are just going to ignore them??? That's just plain stupid. You're given a tool to evaluate your fraud risk, yet you chose to ignore it's warning signs.
stymiee wrote:
.... stop declining failed AVS and CVV transactions.
02-01-2012 09:49 AM