Why do credit card forms ask for Visa, Mastercard, etc.?(ux.stackexchange.com)
ux.stackexchange.com
Why do credit card forms ask for Visa, Mastercard, etc.?
http://ux.stackexchange.com/questions/51346/why-do-credit-card-forms-ask-for-visa-mastercard-etc
98 comments
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.
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.
Collecting a CVV2 code doesn't increase your chargeback protection (for merchants, there is essentially no chargeback protection. if a customer wants to issue a chargeback, you'll get a chargeback). What it does is reduce your risk profile, which is part of how your processing fees are collected. If you don't collect the CVV2 you're going to have a much higher risk profile, and will either pay a higher processing fee or else be denied the ability to process cards at all.
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.
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.
How do you mean address verification 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.
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.
our payment gateway would charge us more for address verification than our merchant bank would discount us for using address verification.
Checks are typically very simple, no regex-ing involved.
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.
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.
> 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.
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.
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.
It's not clear that chip cards would have avoided the Target thing since the fraudsters infiltrated the terminal software
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)
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)
>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 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...
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...
Can I piggyback on this and ask an unrelated question I'm curious about?
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?
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?
No, there are no such provisions. The card companies have their own fraud prevention/detection departments which mine transactions and look for abnormal behavior. If they spot something out of the ordinary (big purchase, foreign purchase, etc) then they will call you to validate.
Anecdote: I used to work with donation processing, and we had a situation where we had transactions that I knew we're identity theft (email addresses were the same, IP the same, but zip, CVV, name correct, and all submitted in a short timeframe). I refunded the transactions and called the banks to report that the cards had been stolen, and the banks basically threw their hands up in the air.
I work with donation processing. We found the same response from the banks, so we've started trying to look up the identify theft victims in the white pages and calling them. Sadly, we only get a 20% hit rate for working phone numbers and typically only get in touch with half of them.
Which is why, every time I travel, I end up with all the cards blocked. I hate you visa.
My bank has done the same in the past, but now the offer an interface in online banking to inform them when I'm travelling.
It still annoys me though: Their fraud system keeps flagging regular transactions that I've done for similar amounts to the same companies, at the same times of month or year for years, yet when someone did two transfers of 3000 GBP each to a credit card account in a different bank that I've never dealt with before, in someone elses name, their fraud system did not trigger...
From my perspective, their blocks are nothing but a nuisance.
It still annoys me though: Their fraud system keeps flagging regular transactions that I've done for similar amounts to the same companies, at the same times of month or year for years, yet when someone did two transfers of 3000 GBP each to a credit card account in a different bank that I've never dealt with before, in someone elses name, their fraud system did not trigger...
From my perspective, their blocks are nothing but a nuisance.
Call before you go and tell them you are traveling.
Somewhere I read that such a call triggers a fraud red alert.
That would be counterintuitive. I always inform my bank before traveling out of the country. They want to know the destination nation and a date range, which is necessary to avoid triggering red flags when "card present" transactions start showing up from an unexpected location.
Nope. Once the credit card company authorizes the transaction, it's entirely up to the merchant whether to fulfill the transaction and close it out, or refund the customer. The credit card companies will do nothing to assist in making this decision.
But be sure you choose correctly, because they will take the entire payment away from you if there's a chargeback.
But be sure you choose correctly, because they will take the entire payment away from you if there's a chargeback.
Some processors return a numeric risk score, or a ternary result (OK,Review,Denied). Then the merchant might choose to review the transaction if the risk score is above a certain threshold (or the result is Review), then cancel or capture it accordingly.
For example, merchant's staff calls the shopper. This adds some cost, but for some merchants it might save money overall since chargebacks can be very costly (even if the merchant manages to challenge and win).
For example, merchant's staff calls the shopper. This adds some cost, but for some merchants it might save money overall since chargebacks can be very costly (even if the merchant manages to challenge and win).
Can't resist a shout out for a friend's new company that makes a lot of sense: http://chargeback.com (outsourced chargeback handling).
>It's harder to "steal" a chip card since the information is not sitting on an easy-to-read mag-stripe.
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.
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.
Since the chip verifies the PIN, is it protected against brute force cracking? I know some cards become "blocked" if a wrong PIN is presented three consecutive times. Is this a chip feature, and if so can the chips be "reset" by the bank?
> charge more for missing or incorrect CVVs.
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?
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?
Yes. Quite a lot of merchants do not ask for CVV/CVCs (Amazon being an example).
Yes, the CVV is not required. If you think about it, it is obvious CCV isn't since many self-serve card swipe machines (gas stations, grocery stores, fast food restaurants) don't ask you for it.
Yup -- you can authorize a card with a missing, or even incorrect, CVV.
I work at Balanced payments, and this frequently trips up a lot of people. If incorrect CVV information is entered, we note that in our response, but it's up to the user of our API to decide if they want to accept that card or not. (We also use this information as one component of many in our internal fraud systems, of course).
I work at Balanced payments, and this frequently trips up a lot of people. If incorrect CVV information is entered, we note that in our response, but it's up to the user of our API to decide if they want to accept that card or not. (We also use this information as one component of many in our internal fraud systems, of course).
Yes. Physical transactions, card present, with chip and pin have lowest txfee.
You can run a card with only a number and exp even. No AVS at all. Just higher cost higher risk.
You can run a card with only a number and exp even. No AVS at all. Just higher cost higher risk.
[deleted]
The story behind the CVV is something like this:
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.
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.
I'm confused, how does this work? There is no raised type on any of my cards whatsoever, how do you take an impression of a flat card?
In the old days, before most places had machines to swipe the mag stripe, they used to take card imprints. I'm 38, and have had cards for 20 years, and I've never had anyone imprint my cards.
So these days it's not very necessary to have raised type on the cards for most people.
So these days it's not very necessary to have raised type on the cards for most people.
It's certainly not necessary, but my guess is that it follows from the "Don't Make Me Think" school of UX design. If a majority of consumers have been conditioned to expect a credit-card-selection menu (or series of clickable icons), then the absence of such might confuse them and cause measurable drop-offs in the purchase completion funnel. It seems a little farfetched, but I'm sure at least someone has done the tests and proven this to be the case. (And if not, then there is truly no reason for the continued presence of these menus.)
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.
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.
I worked for a company which sold goods online and ran their own shopping cart. We took out the 'card type' drop down and just auto detected it. We had a bunch of greyed-out logos and once you entered a valid credit card number it would light up whichever card type it was (Visa, Mastercard, Discover, Amex).
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.
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.
We do a similar thing here in Australia with states and postcodes. Except for a couple of unusual postcodes the state can be predicted with a 100% accuracy from the postcode. We found that if we didn't include the ability for the customer to select a state then they would do silly things like put the state in the street address or even their own names. We added a functionless state dropdown and these errors stopped.
Fascinating. And it makes sense. Sometimes long-time purchasing habits are hard to break, and forcing a change hurts results.
If you only accept the 4 biggest card issuers, you can get away with some dead-simple code to indicate to the user what card type their number indicates they are.
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).
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]];
}Except that Maestro cards start with 6 as well.
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.
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.
Just so I understand, your complaint is: if you enter a number that isn't a credit card number, but that can't actually be differentiated from a valid credit card number, the credit card widget isn't able to determine that it's not valid? You seem to be expecting a great deal from this widget.
> 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).
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).
If you only accept the 4 biggest card issuers
Heads up: If you're in (say) Europe or UK, then American Express and Discover aren't a "big card issuer"
Heads up: If you're in (say) Europe or UK, then American Express and Discover aren't a "big card issuer"
>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?
Do you only have Visa and Mastercard then?
Yes. And local bank debit cards usually combined on the VISA card, in Norway there is BankAxept, Dankort in Denmark and something else Germany can't remember. The fees for these transactions are next to nothing compared to Visa/MC here in Norway. But very rarely accepted online (unfortunately).
This is similar in Australia and New Zealand as well. Visa and MasterCard are extremely common, AMEX is sometimes offered with fancy accounts (usually as a second card), and Discover is all but unheard of.
We have a checking account payment system called EFTPOS which has near universal acceptance, and can be combined on the same card as a Visa/MC/AMEX.
Contactless payment (PayWave and PayPass) is rapidly becoming commonplace among retailers, and can be used for transactions up to AU$100.
http://en.wikipedia.org/wiki/Debit_card#Australia
Australia plans to deprecate the use of signature verification for domestic credit cards later this year, requiring Chip+PIN for all cards issued by Australian banks. Signatures will still be accepted for foreign cards, because tourists.
http://www.lifehacker.com.au/2014/01/credit-card-pin-number-...
Visa Debit is available and works, but doesn't really have any domestic advantages over EFTPOS. Maestro and PLUS aren't brands Australians generally interact with, except when traveling.
Frustratingly, Australian Chip+PIN cards don't seem to travel overseas well -- in ATMs they work fine (with fees galore) but in retail, the terminal often insists on a signature instead of a PIN.
We have a checking account payment system called EFTPOS which has near universal acceptance, and can be combined on the same card as a Visa/MC/AMEX.
Contactless payment (PayWave and PayPass) is rapidly becoming commonplace among retailers, and can be used for transactions up to AU$100.
http://en.wikipedia.org/wiki/Debit_card#Australia
Australia plans to deprecate the use of signature verification for domestic credit cards later this year, requiring Chip+PIN for all cards issued by Australian banks. Signatures will still be accepted for foreign cards, because tourists.
http://www.lifehacker.com.au/2014/01/credit-card-pin-number-...
Visa Debit is available and works, but doesn't really have any domestic advantages over EFTPOS. Maestro and PLUS aren't brands Australians generally interact with, except when traveling.
Frustratingly, Australian Chip+PIN cards don't seem to travel overseas well -- in ATMs they work fine (with fees galore) but in retail, the terminal often insists on a signature instead of a PIN.
And a boatload of country-specific systems (both credit cards, debit cards and various systems for direct bank transfers)
Yes, there are often country-specific debit cards, but I'm not aware of many country-specific credit cards in Europe? Within the EU (and especially Eurozone), bank transfers are all easy to do and interoperable.
I'm in the UK and had an AmEx card for many years. Visa and Mastercard dominate the market, though.
Yes.
In Canada, it's Visa and Mastercard, and the occasional AmEx. I don't think anyone here takes Discover.
Amex is big enough that it is accepted almost everywhere in Europe. When it isn't, it is usually over cost, not lack of demand.
As for Discover, I don't think I've ever seen a Discover card in Europe...
As for Discover, I don't think I've ever seen a Discover card in Europe...
I think it was just a convention and made people feel better about having entered the form correctly. It makes sense to tell a merchant what type of card you are using even though someone "in the know" might know that it can be sussed from the digits.
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.
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.
Many years ago, I worked on an online donations form that did not ask this (wasn't a requirement). But soon after launch, users asked if the form was broken or missing some important part, so we added it to make them feel more at ease.
The name on the billing address is handy if you need to contact the person making the purchase.
Well, then you'd need to ask for their email or phone which I've never seen.
most online purchases ask for the person's email address.
Also, you've never shopped at Amazon? They ask for the phone number for the billing address. https://www.monosnap.com/image/4QZmCDNdlsqei8BLIsjw6Z3q00tml...
Also, you've never shopped at Amazon? They ask for the phone number for the billing address. https://www.monosnap.com/image/4QZmCDNdlsqei8BLIsjw6Z3q00tml...
I was referring to when merchants ask for the name on your credit card. I can't recall that ever being accompanied by email or phone. Here's Amazon's form: http://imgur.com/Azd1VKZ
I'd like to see an A/B test between the 2 options. It sounds plausible that a less-sophisticated buyer might see the Visa logo light up after they've typed the first digit of their card and get confused ("WHAT WITCHCRAFT IS THIS").
I don't have published version of data, but I can confirm from running a checkout flow that's processed $100M that fewer fields = more conversions. If you light up the logo people understand it when done properly.
It helps that more savvy ecommerce sites are moving to this model so more and more users are familiar with the experience.
It helps that more savvy ecommerce sites are moving to this model so more and more users are familiar with the experience.
Conversion rate isn't the only thing you optimize for. I helped a company reduce its fraud/chargeback rate by asking for the type of card without error correction. A type mismatch was one of a dozen or so scoring items that, if over a specific threshold, tripped a second level of verification.
Unfortunately I don't have a linkable source for this, but the Democratic fundraising platform ActBlue gave a talk on A/B testing donation forms and it turns out that when they removed the "select card type" field, donations went -way- down. You'd think that the Law of Forms would apply (fewer fields = higher conversions), but it doesn't. Apparently people assumed that there was something wrong with the form and therefore didn't trust it (when they removed that field, they also had a huge uptick in people submitting reports of things wrong with the form).
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'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.
My limited experience is that less-sophisticated users are either unaware or impressed by the light up logos option.
Why do credit card forms ask you to enter the credit card number without spaces between the clusters of digits, when it's simple for the machine to parse with or without them?
I'm going to guess that the most likely reason is that a terrible progranmer or manager was behind the decision of making the customer do the extra work instead of the development team spending a little more time to parse it.
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.
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.
If you follow the letter of the law with gateways it's frequently the case that you cannot modify the payment data. At least that was the case years ago when I integrated with a couple (in the scary days before Braintree and Stripe).
This came up in a training course along with why do some sites prevent characters like * / ( & from passwords. The reason is the same:
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.
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.
If you are handling the card number on your own servers (e.g. not using an iframe which you can't modify), then it's just lazy programming. There's no spec that says you cannot modify poor user input to strip characters.
Source: I run an e-commerece site and have written checkout flow.
Source: I run an e-commerece site and have written checkout flow.
This is extremely rare in my experience. But I suspect it's just lazy or poor programming. It's usually kind of humorous because the coding to identify the situation and display an error message could have simply been spent removing the spaces/dashes/etc.
Someone specced the field length and type for the database, and just said "enforce the same rules on the front-end."
Working for nonprofits and church's, I know we do it because AMEX and others charge higher rates per transaction than say VISA, thus some clients only take VISA and giving a select list of options, lets the user know to use that type of card.
Not taking Amex for cost reasons is almost always a bad move. First, it annoys the person giving you money (always a bad move). Second, Amex cardholder spend way more than average (frequently a bad move). They may still spend as much when asked to use Visa instead, but maybe not.
I'm an AMEX cardholder. I don't really mind too much when people don't take AMEX. I understand they are a "premium" brand and I adjust my expectations accordingly. That being said 99.9% of the time they take AMEX.
>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.
>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.
Seconded. I know to look for an AMEX or Discover logo at a cash register or on the bill cover at a restaurant/bar. Those cards are accepted at many more businesses than they were ten years ago, but acceptance will never hit 100% due to the fee differences for merchants.
We do stress that point, that the barrier to donate should be as low as possible. Still, some churches go as far to say donations can't/shouldn't be made on credit do to their individual beliefs, and would only take ACH transfers as they pull directly from a bank account.
Merchants are now seeing a lot of payments by debit card which are not loans (direclty out of bank account). And there are still a lot of Amex cards out there that require full payment each month which is not really a loan.
For a good example of how to do this right, see skeuocard:
http://kenkeiter.com/skeuocard/
http://kenkeiter.com/skeuocard/
Good example? It is an interesting concept but while it resembles the physical object it does not fit in with the normal way of filling out a form on a webpage. And has anyone used this in production? I really like to see some stats on how this performs.
This requires me to use mouse to navigate between fields. I really prefer to not get my hands off the keyboard when I start typing something. Tab key is there for a reason.
And I can't review in a single glance whenever I typed everything right.
And I can't review in a single glance whenever I typed everything right.
Highly recommended.
Worked in restaurants for years while I was in college. All but 1 restaurant I worked at had systems that asked for the type of card.
I dont think this is limited to web forms.
I dont think this is limited to web forms.
This has always been a pet peeve of mine, it's totally unnecessary to ask for the card type.
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!
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!
If anyone is curious about the luhn algorithm, here is one I made in C# from the example in the question:
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?
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?
I also did one in javascript (i've requested it be ammended to the accepted response but we'll see how it reviews) anyway here it is:
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)');
}
While your code may be fine, I find it weird to see functional operations in the same expression as the ASCII code '0' (48). It is a very weird juxtaposition of abstractions.
I think it's one of those things where convenience for those looking at the underlying data has bled over into the UI. While you can deduce the type from the number, it's not easy for humans to do that at glance while looking over SQL query results. I could be wrong, but often, we ask users for more input than we need to because elegant UIs take lots of work.
Is it really hard for anyone in 2014 to get the type of a card from the first 2 digits of a card number and add a field to an INSERT query?
It's not difficult, but quite a few developers I've worked with were unaware of that algorithm, which is one reason I think they pushed it into the UI.
All developers I know of, including myself, do have this unawareness of simple things, but I prefer to call it for what it is: simple human laziness.
Might also be that some people will try to enter an amex or discover card number if you don't do this. Even if you state that only visa or mc can be used, people don't always read it. Having to select an option is how you can be sure that they are aware of it. Kind of like having to check off the "I agree to the terms" checkbox.
I wonder if this was used to discourage AmEX cards(Higher processing fee), as to my knowledge these forms have originated in pre-checkout JS era and have just been copied thereafter. Would be helpful if we could get a look at the processing rates 6-7 years back.
The same reason forms make your enter your phone number in a particular format.
It'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.
It'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.
Mostly it's because of PCI DSS and dinosaurs in the market leaving very little customizability of the iframes they provide.
if (strcmp($POST['cardtype'], "mastercard")) {
$Processor = $PaymentProcessorFactory.InstantiateByType("mastercard");
$Processor = $PaymentProcessorFactory.InstantiateByType("visa");
}
$Processor.process($POST);
* 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...