CVV Not working

[datoad]

Hi,

I'm a new member and I'm working on setting up my shopping cart.  An Authorize.net customer support  representative suggested I read/post questions here.

I can not get my CVV to work properly.  At this time I've made three transaction which I do see in my unsettled report.  But when I use my credit card and I do not put in my CCV number (or use the wrong number) the transaction still processes.  I was asked if I receive an error message, which I do not. I want to make sure that the CVV is working  properly.  What steps would you recommend I take?

I looked at my add-on module (version Id: authorizenet.php,v 1.4 2004/03/05 00:36:42 ccwjr Exp) and I have enabled the last option which is:

"Enable CCV code
Do you want to enable ccv code checking?

 True
 False"

I have it set to "True".  But the card will still process without the number.

Thank you,

datoad

[soundcommerce]

Are you in test mode or live mode? Also, are you sending transactions to the test environment or live environment?

[stymiee]

CVV, like AVS, will not cause a transaction to be declined. It is merely one of several tools available to help determine if a transaction is possible fraudulent or not. So, if you don't provide it or provide the wrong CVV number, the transaction will still be approved (assuming all factors for approval are present). You simply will be provided with a CVV result which you can then use to determine if you want to investigate the transaction further (and of course possibly void or refund it).

[datoad]

---

@stymiee wrote:

CVV, like AVS, will not cause a transaction to be declined. It is merely one of several tools available to help determine if a transaction is possible fraudulent or not. So, if you don't provide it or provide the wrong CVV number, the transaction will still be approved (assuming all factors for approval are present). You simply will be provided with a CVV result which you can then use to determine if you want to investigate the transaction further (and of course possibly void or refund it).

---

Hi Stymiee,

How do I use it as a tool?  So if I understand you correctly, you are saying that "if" I have an issue, I can go back and show the merchant provider that the customer "did" enter in a CVV number?  But as you said if they don't or provide a false one, what's the point of it?  Which takes me back to my original question; what "factors" need to be met for the card to be approved?  

I'm new to all of this so please forgive my ignorance.  I want to make sure to best of my ability that I can safely process transactions on my site for the protection of my customers as well as my business.  I also want to be PCI compliant and I’m being proactive in making sure I have all of the proper processes implemented.

In my mind, if the name on the card doesn't match the card number, expiration date, and/or the CVV, the card should be declined.  But as my merchant services provider told me, the name isn't a way to validate the card.  So we are left with the latter three.  So now I'm learning that the CVV is just a means to "track" someone using the card only, that's "if" they actually put the CVV in the field.  This sounds very weird to me.

I have a website which hasn’t gone LIVE yet.  I'm currently live and using the production server.  I'm not in test mode.  On my shopping cart, when you check out, you can use any credit card from the drop down (V,M,D), any expiration date (as long as its after the current mm/yy) as well as any name you like and the card process.  I do not like this, this to me is very wrong.  Please tell me I’m wrong here.

So what steps can I put in place so this doesn’t happen?  Or is this really how the credit card industry really works?

I just updated my Authorize.net to version 3.1, per the website it says for the CVV to work I needed to be on version 3.1.  Then it also says to changed the code to "x_version=3.1", but no where in the add-on module I currently have does it have this verbiage.  I download this module from the CRE Loaded website (http://creloaded.org/extensions/Payment-Modules/Authorize-2Enet-Payment-Module/details.html).  Is there another module I should be using or will this one work?  Again, the only version ID information I can see is (version Id: authorizenet.php,v 1.4 2004/03/05 00:36:42 ccwjr Exp).

I appreciate all your help in getting this to work.

Thank you.

datoad

[stymiee]

Credit cards are approved by the card issuing bank, not the merchant account provider. The criteria for determining if a transaction is approved or not varies from issuer to issuer and you don't really have any control over this. The factors that they use go deeper then simple factors like, "is the expiration date correct" and, "is the street address correct".

When a transaction is submitted for processing the card issing bank is provided the card number, expiration date, street number (if provided), zip code (if provided), and CVV (if provided). However, to successfully process a transaction the card issuing bank only needs the credit card number. From that they can determine everything else they need to issue an approval or decline. The expiration date is commonly ignored, although not always, and the other pieces of information are validated against what the card issuer hason file and the results of that are returned to the merchant.

The merchant then is to use the results of AVS and CVV to help determine if the transaction is possibley fraudulant. Individually they are not very useful as false positives are very common. But when combined with each other, and other tools/factors, they can be very helpful in determining whether or not a transaction is fraudulant or not. For example, if a transaction has a failed AVS but CVV is correct and the shipping address match the billing address the transaction has a low probability of being frauduant. If both the AVS and CVV don't pass and the shipping address doesn't match the billing address then the sale has a much hgher probablity of being fraudulant and further investigation is required.

Authorize.Net, and possibley some shopping carts, allow you to configure them to automatically reject transactions that fail CVV and/or AVS. This seems like a good idea on the surface but is in practice a bad idea. There are lots of vaid reasons for these pieces information to be incorrect. They should be used in conjunction with other tools to determine if a transaction is invalid.

[datoad]

So where do I start?

I seem to have three issues:

1. The credit card will process if I use any expiration date.
2. The credit card will process if any of the “types” (Visa, Master, or Discover Card) are selected.  (I was using a Visa and I choose Master and it still processed.)
3. The credit card will process if I use a wrong CVV/CCV code.  (In Card Code Verification (CCV) Settings on Authorize.net's website.  I have it set to "Does NOT Match" (N) so shouldn't the customer receive a "declined" card?)

Thanks,

datoad

[datoad]

A post from a member in another forum:

those are questions for authorize to answer.. 
there should be a ton of settings for fraud and such

"CVV, like AVS, will not cause a transaction to be declined. It is merely one of several tools available to help determine if a transaction is possible fraudulent or not. So, if you don't provide it or provide the wrong CVV number, the transaction will still be approved (assuming all factors for approval are present). You simply will be provided with a CVV result which you can then use to determine if you want to investigate the transaction further (and of course possibly void or refund it)."

[stymiee]

1) Like I said, the expiration date being invalid or incorrect does not mean the credit card will be declined. However I would be skeptical of transactions that go through with expired dates as I believe Authnet does flag those before processing the order.

2) Choosing the card type is for your record keeping only. It has no bearing in any way on the actual processing of the transaction. It is not used by anybody for anything.

3) In a live environment you should be receiving a decline if you have set up your account to decline transactions that fail CVV. In a test environment this will not work as all transactions are approved if there are no errors regardless of account settings.

Authorize.Net does offer basic fraud control through rejection of failed AVS or CVV verification (however unwise this may be). But for really robust fraud protection you would need to use their Advanced Fraud Detection Suite which is designed specifically to reduce fraud.

[datoad]

Hi John,

After I changed over $1,400.00 on my credit card the process now works.  Here's what actually happening:

When I tested a incorrect/invalid credit card number on my Payment Information/Method page and I hit the continue button, the page would remain the same and a pink box would pop up on the top saying Credit Card Error.  So to me, the card was invalid and wouldn't be processed.  I then tested the same card with the correct number and wrong expiration as well as CVV number.  When I hit continue, I would then go to the confirmation page.  To me this was incorrect as why would I receive this page because in the example before I didn't, hence why I thought it wasn't working properly.

Well, tonight I decided to just hit continue to confirm the order with the invalid expiration and CVV number.  Once I hit continue to confirm my order, a bright red banner came up right below the address bar on the top of my screen and it  said "Card declined...".  I did this twice, and in a matter of 5 minutes I received a call from my Bank's fraud department saying the someone used my card and the transactions were declined.

So, I learn the hard way.  But it seems that the Expiration and CVV are working properly.

Thank you for your assistance.

[Deo]

Hello John and DJ,

I'm a developer testing the UpdateCustomerPaymentProfile in test environment (the webservice starting with "testapi").

I was testing the CVV and I was getting acceptance everytime, even with an invalid code. The date works though.

So, John, I shouldn't waste my time testing it in test environment because all transactions are going to be accepted anyway, regardless of wrong card code? I keep geting the same 'P' and '2' codes in the fields 39 and 40 of the validationDirectResponse.

Thanks for the help!

-Deo