View Full Version : Discover, Diners Club and CVV2
tappel
09-13-2003, 08:21 PM
I'll soon be moving from 2Checkout.com to a merchant account provided by my bank. I'll be accepting all major credit cards (Visa, MC, Discover, Diners Club and Am Ex).
CVV2 refers to the 3 or 4 digit code found on most major credit cards.
I need to configure Discover and Diners Club manually in my shopping cart program and the option to require CVV2 is a check box. I know Visa, MC, and American Express use CVV2, but what about Discover and Diners Club?
Tom
Randall
09-13-2003, 09:12 PM
Greyhound now requires the CVV2 number for all credit cards except Diners Club and Carte Blanche, where a CVV2 number is not issued. So that would be a "yes" on Discover.
Randall
The "verification code" differs slightly from card to card. Visa (CVV2), MasterCard (CVC2), Diner's Club (CVV2), and Discover Card (CID) all use a 3-digit number on the front of the card. American Express (CID) uses a 4-digit number on the back of the card.
Note however that the actual availability of the verification code varies from card to card as well as country to country.
Be careful about *requiring* the code since many customers won't have a code or don't know how to find it. The best checkout interfaces allow you to either require the code or to make it optional.
I would advise starting by making the verification code optional and carefully reviewing all orders before requiring the code everywhere.
hobbes
09-15-2003, 09:30 AM
American Express (CID) uses a 4-digit number on the back of the card. Note that my AmEx has the code in front.
Note that my AmEx has the code in front.
Yes. Thanks for correcting this error, Hobbes!
Also note that if you're checking the validity of card numbers (along with expiration dates), Amex has fewer digits than Visa/MC/Discover. That tripped me up mightily... 15 as opposed to 16, I believe.
Dan
tappel
09-15-2003, 08:52 PM
Originally posted by Rich:
Be careful about *requiring* the code since many customers won't have a code or don't know how to find it. The best checkout interfaces allow you to either require the code or to make it optional.
I would advise starting by making the verification code optional and carefully reviewing all orders before requiring the code everywhere.
Interesting point, Rich. I'm currently using 2CheckOut and CVV2 is required. I've been surprised by how many people bail out of a transaction because of that.
I thought that the CVV2 field was (is?) an important security feature and that those who couldn't (or wouldn't) fill in the field weren't customers that I'd miss. Based on your comments, I might rethink that...
Tom
Up until pretty recently, I had a card or two without the "security" code and couldn't complete some transactions because of it. I never did understand what security that is really providing... I suppose it makes one more number to guess, but chances are if they know your expiration date, they have your stolen card in front of them and can look up the additional 3 or 4-digit code just as easily. :\
Dan
The "verification code" differs slightly from card to card. Visa (CVV2), MasterCard (CVC2), Diner's Club (CVV2), and Discover Card (CID) all use a 3-digit number on the front of the card.
My MasterCards both have the number on the back of the card, only.
Randall
09-16-2003, 02:26 AM
I never did understand what security that is really providing... I suppose it makes one more number to guess, but chances are if they know your expiration date, they have your stolen card in front of them and can look up the additional 3 or 4-digit code just as easily. Based on my reading last night, it's aimed at people who don't have the card, period. The old imprint machines don't pick up the code, and apparently swipe readers are designed not to save the number either. So the theory goes that unless they have the card -- or a photocopy -- they can't use it.
Supposedly they started printing the CVV2 number on the card because of internet and phone sales, since very few people have swipe machines at home. The original CVV code was already in the magnetic stripe. It's not clear from what I've read whether the two codes are the same.
Randall
Doesn't the expiration date do the same thing? I don't recall seeing that recorded on receipts or anything. :\
Dan
A few points:
(1) My original post was a little dyslexic. As many of you have noticed, Visa, MasterCard, Discover put the security code on the BACK of the card while American Express puts the code on the FRONT of the card.
(2) The security code is the only cardholder data that requires the physical presense of the credit card. Card Association rules forbid storing this number in any database (its use is only for the purpose of authorizing the current transaction). The security code is not a part of the magnetic stripe data. This would make the security code an excellent card authorization tool IF the code is on all cards (it isn't) and IF the code can be found by all users (which it can't).
(3) Credit card "theft" is rarely the theft of the actual credit card. It is almost always the theft of the credit card number, expiration date and other cardholder data.
Here's my take on both AVS and the CVxx security codes: Collect data for them but do not automatically reject based on them. They should be just 2 of the many factors you look for in transactions to determine if it is "good" or "bad". Remember that if your chargebacks climb above 1%, the card associations will start to fine you and you can risk losing your charge priviledges. Also, if you blindly implement AVS and the security code check and automaticaly reject all transactions that don't match, you *might* see your total revenue fall by 25% or more.
The bottom line is that these security measures do a great job of filtering fraudulent transactions--they also do a great job of filtering GOOD transactions, too.
hobbes
09-16-2003, 12:11 PM
Card Association rules forbid storing this number in any database (its use is only for the purpose of authorizing the current transaction). Rich - This came up recently for a client who does phone/Internet sales. How are they supposed to process transactions if the CVV cannot be stored in a database? The way transactions get processed is after they have gone into the database. Bit of a catch-22...
This came up recently for a client who does phone/Internet sales. How are they supposed to process transactions if the CVV cannot be stored in a database? The way transactions get processed is after they have gone into the database. Bit of a catch-22...
The security code is designed for "real-time" authentication. To authorize the transaction with the security code, the company must authorize the charge while the customer is on the phone. If they do not take this step, they cannot use the security code for authorization purposes.
Wouldn't that mean you can't use a card with the security code for recurring billing? I know there's some way around it, because I have security code cards set up for monthly billing for cable, phone, etc.
Dan
Wouldn't that mean you can't use a card with the security code for recurring billing?
No, because the security code is not required to process a transaction. It is an option for use during the authorization step.
Besides, after the initial transaction, the security code wouldn't be needed anymore because it had already served its purpose.
the security code is not required to process a transaction. It is an option for use during the authorization step.
This is getting more confusing by the minute. :\ Isn't the authorization part of the transaction? If the security code is optional, then what good does it do? If a thief doesn't have your card in front of them, it figures they would choose Option B: don't enter the security code.
What am I missing? %)
Dan
Isn't the authorization part of the transaction? If the security code is optional, then what good does it do? If a thief doesn't have your card in front of them, it figures they would choose Option B: don't enter the security code.
The use of the security code (like the use of AVS) is an option the MERCHANT can choose to use or not use (although your merchant bank might require that you use one or both of these depending on their assessment of your businesses risk of fraudulent transactions).
Also keep in mind that although the merchant might choose to use the security code (or AVS) when authorizing the transaction, this use does NOT automatically accept or reject the transaction. It simply informs the merchant whether the security code matches. The merchant then needs to decide whether to accept or reject the transaction.
One point that confuses many people s that some payment systems are configured to automatically Authorize and Capture the transaction in one step allowing a "hands-off" (albeit very dangerous) management approach to the merchant. However, Authorization (approving/rejecting the transaction) is a separate step from Capturing (submitting the transaction for payment).
Hope this helps clarify.
Ok, I think I get it now. The option is on the part of the merchant, not the person entering the CC info. If the merchant and/or bank requires it, then the user has no choice. Correct?
So in hobbes' case, it could have been handled by simply ignoring the security code, assuming the bank allowed that.
Dan
If the merchant and/or bank requires it, then the user has no choice. Correct?
Correct.
So in hobbes' case, it could have been handled by simply ignoring the security code, assuming the bank allowed that.
And assuming the application (order form or shopping cart) also allowed that...yes.
I think you've got it. :)
Coming back to this, in my Authorize.net CVV setup, I've got the following configuration options:
Reject Transaction If Card Code value...
- Does NOT Match (N)
- Is NOT Processed (P)
- Should be on card, but is not indicated (S)
- Issuer is not certified or has not provided encryption key (U)
It seems to me all 4 options should be checked, although I'm not sure about the second one. A non-match or a card with a verification code that wasn't submitted are bad signs, and I would assume a non-certified bank is a major red flag. I'm not clear on what "not processed" represents, though. Would that mean there was a failure in verifying the code other than a non-match situation, or might it also include the merchant not requiring the code and the customer not submitting it (presumably a non-match, but who knows)?
Dan
If you are beginning by using AUTH_ONLY (which is what I recommend at least for the first few weeks) then I would also recommend that you do not select ANY return codes for rejecting the transaction for either CVV codes or AVS. You will still be able to see the result codes and make a decision to reject the transaction based on the returned values. However, if you setup the system to reject on returned values there is no way to "save" a transaction.
P - this says to reject if the card does not have a code or if for some reason the code is not processed. Rejecting on this basically says you do not accept any cards without a code.
S - this is the "reject if left it blank" choice. This also says to reject if the customer doesn't know what the code is or where to find it.
U - very similar to P, so I would recommend treating this like the P option.
That seems like a wise suggestion, and thanks for the clarification on (P). I'm confused why (U) would be roughly the same as (P), though. Well, maybe it's not so strange given the description in the manual, which differs from that in the Authorize.net admin area:
U = Issuer unable to process request
I would think a non-processed CVV would also indicate a non-processed card for authorization, but maybe that's not a safe assumption.
AVS I'm much more hesitant to enable (act on) right off the bat, because there are so many more potential variations and returned codes.
Reject If...
- Address information is not provided for AVS Check (B)
- AVS Error (E)
- Non US Card Issuing Bank (G)
- Retry, system is unavailable (R)
- AVS is not supported by card issuing bank (S)
- Address information for cardholder is unavailable (U)
Reject If Street Address Matches AND
- First 5 digits of Zip Code Match (Y)
- First 5 digits of ZIP Code Do NOT Match (A)
Reject If Street Address Does Not Match AND
- 9 digits of Zip Code Match (W)
- First 5 digits of Zip Code Match (Z)
- First 5 digits of ZIP Code Do NOT Match (N)
Once I'm confident in the system, I could see rejecting on B, E, S, U, A, N, and maybe R. That's a lot to weigh, though.
Dan
vBulletin® v3.6.8, Copyright ©2000-2012, Jelsoft Enterprises Ltd.