|
1a) Varies by issuing bank. Your processor sends the transaction viaVisa & MasterCard ("network") which passes along the transaction to the issuer (a large bank), which in turn decided to approve or decline the transaction and passes back a code. Your processor may map that specific code to a more general code, which behavior will often vary per client - some clients just want to get back "Declined" while some want "Invalid expiration date". Unfortunately since decline code behavior varies -by issuer-, it's possible to get back wrong codes, so you can't trust them really. For example, you might see a Mastercard with an invalid zipcode come back as invalid expiration date, while another mastercard with an invalid zipcode comes back with invalid AVS. Then if you present "invalid expiration date" to your end user, they will be confused because the expiration date is fine. In my experience, detailed decline codes are more trouble than they're worth, the customer will have to call their bank to fix anything regardless so just tell them declined - call bank. 1b) Numbers only. See for example http://en.wikipedia.org/wiki/Address_Verification_System and understand that "street address" just means whatever numbers are there at the beginning of the address. Also understand that this is frequently incredibly low quality data, all you can really rely on is the zipcode match part, trying to do any better will result in a lot of false negatives. 2) There are multiple names for this. In the beginning, on mag stripes, CVV/CVC (name varies by network) was developed and it was a way to validate that somebody didn't build a mag stripe based on just knowing the card numbers - it's data that exists only on the mag stripe and is not printed on the card. Then, CVV2/CVC2/CID/etc was developed and it is a way to validate that somebody has seen the actual card - it is data that is printed on the card but is not in the stripe. People usually don't know about the difference and are talking about CVV2/CVC2 when they say CVV or CVC.
The key thing that makes this work is that merchants are restricted from storing the CVV2/CVC2/CID data (and they already weren't supposed to store mag stripes, so CVV/CVC also), so if somebody gets a database dump of a bunch of credit cards it shouldn't have CVV2/CVC2 data in it. It also doesn't come for free from an automated skimmer because it isn't on the mag stripe. And, way back in the day, it wouldn't have been on the carbon copies because it was in flat type. So, this really does add some security to a transaction. So what it does for chargeback protection is make it more likely that you are dealing with someone who physically has the card in front of them, because that little bit of data is harder to steal than the other bits of data. It still doesn't let you win a chargeback - for that, you need a signature, which you won't have if you're doing ecommerce, so you'll lose. It just makes the chargeback less likely in the first place. Additionally, if you are classified as doing ecommerce, some issuers will simply decline any transaction that doesn't have CVV2/CVC2. Varies by merchant category and by issuer. 3) Don't know, I processed cards in America. Debit cards when used with PIN have a completely different technology behind their security, and a completely different set of laws covering them than credit cards do, but I don't know about chip-and-pin. 4) Don't know, because Internet. |