* Fault/Decline Codes returned from processors like CyberSource. How are these factored? How do processors do Regex on names/addresses? [1][2]
* CVV numbers and what they mean/how they are treated in the system? If CVV number is included does this increase chargeback protection?
* How CHIP cards work differently in the processing system, if at all?
* Do "knuckle-busters" (carbon copy physical imprints) follow any sort of compliance anymore?
[1] http://apps.cybersource.com/library/documentation/dev_guides... [2] http://apps.cybersource.com/library/documentation/dev_guides...
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.
First, names are not really checked.
For addresses, usually only the number (and sometimes just first three digits) are checked as well as the zip.
Generally the processor tries to decline as few txns as possible and instead deliver the information to the merchant to make a decision. The merchant can usually pre-configure error codes that it would like the processor to decline. This might be preferable to the merchant from a cost-saving standpoint as well as not needing to "void an auth" in order to free up the cardholders spendability.
The idea behind CVVs is that merchants are disallowed from storing them so they are far less likely to be included in stolen credit card databases. Thus, requiring them significantly decreases fraud risk. And, yes, many gateways/processors charge more for missing or incorrect CVVs.
It's harder to "steal" a chip card since the information is not sitting on an easy-to-read mag-stripe. It's not clear that chip cards would have avoided the Target thing since the fraudsters infiltrated the terminal software. I'm guessing more current terminals/software is simply harder to compromise. "Chip & pin", as is widely used in places such as Canada and Europe, might help a bit since you would need the PIN to shop off-line. But it would have minimal effect for online shopping since PIN is typically not requested.
The reason we still sign receipts and yes, you still see a carbon copy here and there, is mainly because it protects the merchant if the cardholder does a "chargeback". Merchants typically store the receipts and only turn them over if a chargeback is received. Showing the signed receipt to your processor will usually absolve you from any loss.
I think the above is accurate or close to.
Limiting the fraud to online only would have greatly reduced the potential damage. There was a reason why carders were making physical cards to use, it's muuuch easier to get a transaction through. Address verification and CVV (not part of Target's dump because it's not on the mag stripe and is not collected by Target) would catch anyone using a stolen number online.
From my understanding, chip cards implement challenge-response. So unless the terminal is capable of placing the card in debug mode and dumping any keys, I would expect chip-and-pin would have prevented the Target breach.
(If the terminal is capable of this... well, that is a gigantic hole)
I wonder what would happen in this case if you turned in one of these?
(taken from the internet archive site apparently went down)
https://web.archive.org/web/20050317031541/http://www.zug.co...
Let's say an online merchant gets a transaction they very strongly suspect is a stolen credit card (perhaps it's from a customer with a long history of using stolen cards) but it validates just fine. Is there any provision in the interface for merchants to ask the credit card company to perform extra fraud checks, like calling the cardholder?
Well, yes. But really it's mostly the POS device sending data to the chip which then performs operations and returns a result code or a data block to the POS device.
When you enter a PIN in the POS device it is sent to the chip and it verifies that the PIN is correct. A yes/no result code is returned to the POS device.
In a POS transaction your PIN is not sent to your card issuing bank for it to verify like it is for ATM.
Instead the POS device sends about a dozen data elements about the transaction to the card which runs them through an algorithm and encrypts (maybe not encrypts but that's the best term I can think of right now) it with a key it and the issuing bank knows. The resulting hash is returned to the POS device and is sent to the bank for authorisation. The bank then performs the same algorithm and verfies the hash is valid.
I am not sure if you could literally copy a chip, but it is doing more than just storing data like you have with a mag stripe only card.
"Chip&PIN" would have zero effect for an online transaction as neither the chip or the PIN are in play.
Wait, what? Can transactions still go through without the CVV, except the merchant's transaction fee is a bit higher? They're just not declined outright?
Chips are the same thing - it reduces the fraud risk, thus reducing your processing fees. the carbon imprint is just like a chip - physical proof that the card was present during the transaction. card-present environment is a much lower risk profile than card not present environment, the difference between the two is often a full percentage point in processing fee.
The address verification is not a regex, it's just a simple lookup. Most merchants don't actually do address verification though because it is fairly expensive.
Expensive in terms of lost sales (i.e. users giving up in frustration due to mismatches) or something else?
We've had AVS in place for years and get reduced fees as a result. How many people give up on payment due to AVS mismatches, however, is another matter.
CVV is also known as card not present number. Historically it was printed on the back of the card, or on the front using unraised type. This way, if an impression of a credit card was taken (using one of those old fashion swipe back and forth machines), the CVV number would not be included in the impression. This provided some protection for card owners, as it prevented a merchant from using the credit card number obtained from an impression to say place an order using the CC over the phone. This is why you're required (or it's recommended) that you ask for the CVV number for any transaction where the card is not present.
Anecdotally, I've noticed that more and more sites are using autodetect features based on the first 4 digits entered. It certainly didn't put me off as a shopper; in fact, I found it a lot more elegant. But I'm an unusual guy, as are most people who work in tech. We can't assume that what's appealing or efficient to us is necessarily the same for the broader masses.
What we found was a huge increase in people typing 'Visa' or 'Mastercard' into the 'Name on the card' field (whatever the field was called, I don't remember). People were so used to having to provide that information that they began to provide it in lieu of providing the cardholder name at all.
Think about that for a second; they stopped putting their own name anywhere on the credit card form, and instead started putting the card type in that field. Conversion went down, customer service issues went up.
We added the field back to the form, even though it was never checked and did nothing, and it resolved the issue.
Personally, I bind an onkeyup event handler to fade in the appropriate icon based on the first digit of the number. This is not safe if you accept more than these 4 card types, (we don't).
function detect_cc_type(number){
return {
'3': 'american_express',
'4': 'visa',
'5': 'mastercard',
'6': 'discover'
}[number[0]];
}Also, many ATM cards (a foreign concept to this European until very recently) overlap with Visa ranges. In fact, my ATM card parses exactly as a Visa number. It even has the Visa trademark mentioned on the back. No, you can't use it for online transactions. Apparently, Visa Debit is not a thing in Canada ...
My point is, showing wrong UI is often worse than clunkier UI.
Point taken. As I thought I pointed out however, it's not wrong UI for my app. Since our company only accepts those 4 options, any other code that does more work than my example is a pointless waste of time (for both the programmer and computer).
Heads up: If you're in (say) Europe or UK, then American Express and Discover aren't a "big card issuer"
Do you only have Visa and Mastercard then?
As for Discover, I don't think I've ever seen a Discover card in Europe...
Most payment gateways still require it even though it's probably superfluous.
I've also wondered why forms ask for name on card even though I'm pretty sure it's not checked by most/all processors and would never lead to a decline. Worse is that hardly any merchants pre-fill it if they've already collected your name.
It helps that more savvy ecommerce sites are moving to this model so more and more users are familiar with the experience.
I'm hoping someone from ActBlue's dev team sees this and can jump in. They run a lot of fascinating tests on credit card forms.
I doubt there's a reasonable explanation as to why a CC field can't contain dashes or spaces. I'd love to hear one but I doubt there is one.
Poor Input Validation
Basically whoever was behind making the site couldn't be bothered dealing with those cases and just made them illegal options. Makes you wonder what other corners were cut.
Source: I run an e-commerece site and have written checkout flow.
>giving a select list of options, lets the user know to use that type of card
No. AMEX cardholders know they aren't welcome 100% of the time, and they know to look for an AMEX logo before typing in their info. You need to have the proper logos or lists of payment methods right next to your way to pay.
And I can't review in a single glance whenever I typed everything right.
I dont think this is limited to web forms.
Also, it bothers me that I can't type in my card number exactly as it appears on the card, with embedded spaces for readability. Stupid form! Don't tell me the number is invalid since it has spaces in it! If you don't like my spaces, take them out!
static bool IsValidLuhn(string numbers) { if (numbers == null) throw new ArgumentNullException("number", "number must have a value.");
var allNumbers = numbers .Where((c) => c >= '0' && c <= '9') .Reverse() .Select((c, i) => (i % 2 == 1) ? ((Convert.ToInt32(c) - 48) * 2).ToString() : c.ToString());
return allNumbers.Count() > 0 ? allNumbers.Aggregate((x, y) => x + y).Sum((c) => Convert.ToInt32(c) - 48) % 10 == 0 : false; }
Edit: Can sum one link me to HackerNews markdown?
function validateCC(ccNumber) {
var ccNumber = ccNumber.replace(/ /g, '');
console.log(
/^3[4|7]\d{13}/.test(ccNumber) ? 'AMEX' :
/^6011\d{12}/.test(ccNumber) ? 'Discover' :
/^5[1-5]\d{14}/.test(ccNumber) ? 'MasterCard' :
/^4[\d{12}|\d{15}]/.test(ccNumber) ? 'Visa' : 'Unknown',
ccNumber,
ccNumber.split('').reverse()
.map(function (v, i) { return v * (1 + i % 2) })
.reduce(function (agg, v) { return agg + v; }, '').split('')
.reduce(function (agg, v) { return agg + +v; }, 0) % 10 === 0 ? '(valid)' : '(invalid)');
}
btw to markup simply append 2 spaces to the front of the newlineIt's easier to make the user do all the work, and lazy developers can't be bothered to do simple things like strip all non-digits from a phone number.
if (strcmp($POST['cardtype'], "mastercard")) {
$Processor = $PaymentProcessorFactory.InstantiateByType("mastercard");
$Processor = $PaymentProcessorFactory.InstantiateByType("visa");
}
$Processor.process($POST);
Sorry, cannot simulate "real-world" (lame enough) PHP OO code, but you got the idea.)