How are you penalized if you don't collect the extra information (besides potentially higher rates as stated in the post)? Are there more frauds leading to chargebacks that may have been detected if the card merchant had more information?
If you were to use a really minimal payment form (number and expiration), it's likely that you'd get somewhat more chargebacks. However, you'd also get more revenue. Let's say your chargeback rate goes from 0.1% to 0.2%, but your conversion rate goes from 50% to 60%, then you come out way ahead.
In our experience, you can stop most fraud without putting up roadblocks for your users. Every site is different, but to give an example, we were able detect 90% of fraud for a site with a huge fraud problem without requiring any extra verification from the users.
The really key penalty to avoid is what is called an "excessive chargeback program," which usually triggers for chargeback rates that exceed 1%. You initially get a warning, and if you can't get your chargeback rate down, your payment processor has the right to shut you off. If you're in an excessive chargeback program, then I'd definitely recommend "playing it safe."
But otherwise, I think slimming down your payment form and carefully measuring the effect on fraud is almost always a smart business move.
> Let's say your chargeback rate goes from 0.1% to 0.2%, but your conversion rate goes from 50% to 60%, then you come out way ahead.
No, you don't. You need more information about the transaction then that. What if your profit margin is 1%? Then you've come out even, because chargebacks cost you the full cost of an item, but an extra conversion only nets you the profit on that sale.
Note: I assumed that the 0.1% and 50% to 60% were both percentages of potential sales, because it made the math easier. Otherwise, you have 20% x 1%=2% more profit and .2% x 120%-.1%=.14% more loss from chargebacks, so you have come out slightly ahead.
Doesn't Verified by Visa and SecurePay by Mastercard solve this problem? Whenever I enter a credit card I get asked to enter an online password as well.
Of course, ideally every citizen would be able to sign anything with a public-private key pair, counter-signed by the state.
I hated when Newegg started using Verified by Visa. The password requirements were so silly that I would always forget my password. I haven't been prompted to enter my VbV password at Newegg for some years.
I haven't had to use it in a long time so my memory is fuzzy...but last I remember, when the actual Verified by Visa form pops up, there is an option to disable it.
Verified by Visa is an extremely high friction mechanism. It requires registration the first time around for each CC, and also an extra password or some other authentication mechanism like a bank dongle. If significant people bounce off transactions due to needing to type in their address, or due to needing to flip over the credit card and read 3 numbers, I don't even dare to think of what the bounce rate is for these mechanisms.
It's especially bad since just about no websites I ever buy anything from use VbV / SecurePay. That means that I don't remember the authentication secrets off the top of my head, so unless I'm at home will likely abort the extremely rare transactions that really require it. I've maybe needed VbV once in the last year, and had to try 3 cards before I found one that I could use on the spot.
It's gotten better, but the implementations the first years were abysmally bad. You're in this somewhat skinned payment flow, and then suddenly you're redirected to an un-skinned page, that maybe has your bank's logo on it, that asks for your secret password, or asks you to log in to your internet bank. And you would be on some sort of unrecognizable third-party url, because the merchant redirected you to their payment processor's webpage, which through 3DSecure redirected you to your bank, which in turn redirected you to some partner they used for that, because the bank couldn't figure out how to do it in less than three years because making software is hard or something.
I think I abandoned every such purchase on reflex because it just screamed phishing attempt each time.
Extremely high friction indeed. Most merchants these days give me the option to skip it. Thank you.
Verified by Visa is incredibly obnoxious. Thankfully its very uncommon in North America. Seems to be much more popular in Europe (or maybe European sites just force VbV for my US-issued Visa).
Important to note that companies can turn off verified by visa but then they pay a higher transaction/processing fee. So many merchants dislike it significantly but then pay higher rates. Fun place to be. I wonder how Stripe will handle 3DS with their UK launch given I've heard it has as much as 80% penetration into online sales?
There's also an enhanced version of 'Verified by Visa' and 'SecurePay': at your bank you order OTP calculator/card reader and for every online purchase with your credit card, you are prompted for OTP passcode. This card reader costs about 30 euros. Mine looks like this: http://www.vasco.com/products/client_products/card_reader_di...
The "40% higher conversion rates" for not requiring CVV is extremely suspect to me. Looking at the paper, it wasn't an A/B test, but comparing entire sites. There could be any number of variables causing a difference in conversion rates.
On top of that, there is no published date, but it does mention May 2007 being in the future. Six years is an eternity in the ecommerce space, and I have a feeling people are more familiar with what the CVV code is and where it is located today.
You're right that it's not proper A/B test, so it may be a case that correlation doesn't imply causation. Unfortunately, there's not a lot of research published with rigorous A/B testing for this kind of thing. If any of you out there would like to run an A/B test (and have us help detect fraud if you're worried about increases there), I'd love to help!
I have purchased stuff on sites that have greatly simplified their payment process to the point I did not need to type anything at all! I click "Checkout"; the site displays a QR code; I scan it with my smartphone, which decodes it and prompts "Send 0.123 BTC to xxx?"; and I click "OK". Done.
This is how the purchasing experience looks like with Bitcoin which, for merchants, solves the fraud problem. Hence buyers do not need to give any billing information.
Hehe, I have a recent relevant experience with this topic:
I just finished a simple gift certificate purchase page[1] for a client where I attempted to cut out all unnecessary details; the client's immediate response? "Looks good, but can we add some more fields like name, address, and security code to make it look more 'official'".
Edit: I don't necessarily disagree with their intuition; I think some consumers might actually be suspicious of a sparse payment form but I don't have any hard data.
We at Thumbtack use a similarly simple form, and our chargeback rates are very small [although admittedly we aren't a particularly attractive candidate for fraud]. We also did see both conversion increases and frustration decreases when we switched to a simpler payment form.
We do have one difference though (which I would call a simplication): For the expiration date, we just have input boxes for the person to enter it instead of a dropdown. Select boxes are great if a) You can pick a sane default and b) you don't have many options. For a CC form, both of these fail. You cannot set the default with anything better than random accuracy, and each box probably has at least 10 options. Additionally, the expiration date box says "2 - February". I have a lot of credit cards, and none of them say the name of the month on it, only the number. Why waste the space?
The user just typed in their 16-digit credit card number, just pop them right into the expiration date input boxes for them to type in their month and year free-form. Don't make them put the credit card down, pick up the mouse, then have to navigate select boxes with tiny print.
>I have a lot of credit cards, and none of them say the name of the month on it, only the number. Why waste the space?
Use a lot (more then your sample size) of different credit cards and you'll see some only have 'FEB' or others 'February' and no numerical month at all. Others have the year as '14' or '2014'. It would have been better if the card issuers decided on a standard quite some time ago.
That strengthens the case for having the user type in the value rather than using a drop-down menu. That way you can do the heavy lifting of normalizing the format rather than forcing the user to do it in their head.
This might seem really petty, but I'm always a little annoyed when I have to mentally convert the number on my credit card into a month. It always takes a moment to remember that 04 is March, or whatever. It's much easier just to type the value.
Not just you, I've yet to have a card with a non numeric month. Instead of being friendly, putting month name is a usability loss. Are cards with names instead of numbers the majority in the US?
and for the year 13, 14, ... 22 and 2013, 2014, ... 2022
Basically, I addressed my own pet peeve of never knowing what format the drop-down contents would be in and therefore never being able to select it via the keyboard correctly.
What I would really like would be some way of having all those permutations, but when the user actually clicks the drop-down (instead of keying in the stub) only one of those sets is displayed.
Presumably you could use a mouseover/click/touch handler to swap out the dropdown options before the person sees the options. The handler could even consolidate the options if someone had already selected it.
I don't understand why, instead of adding extra fields to collect more information, the banks and credit card companies instead just added more digits to the original fields. So instead of a separate field for the security code, why not just append the security code (and the postcode, and the XXX, etc.) to the credit card number field? I always have to enter a bunch of information anyway, so why not let me enter it all in one go? (Better for copy and paste.)
The way they're doing things at the moment is driving people to pay via PayPal, because PayPal requires--hey look!--a single string which they call a "password".
It may be an extra layer of protection related to getting the credit card number via seeing or taking a picture of the front of the card, having it on the back helps improve security from that aspect.
What makes the security code (CVV) different from just having more digits is that you (the site/merchant) not allowed to store it permanently in your database. You can keep it in-memory for up to 15 minutes while authorizing the transaction.
That means in theory, if the merchant's credit card database gets hacked, the fraudsters will get access to the credit card numbers but not the CVV.
In practice, the rules aren't obeyed as strictly as they might, so you can easily find credit cards with CVV on the black market.
Even if the different fields have different security requirements, that doesn't seem to be a good reason to require them to be entered separately.
I don't really care if someone mandates that digits 1-4 can be sent via email, digits 5-10 can be stored unencrypted, digits 11-16 must be encrypted, and digits 17-20 can never be stored at all. They're still just digits/bits of information, and I have to provide all of them almost all the time anyway.
The one exception is when a retailer has saved my credit card number, in which case they might ask me for the CVV only. But I'd rather that they didn't save the card number at all! I have to look up the CVV and copy and paste it into their form every time anyway--so they may as well require the whole thing every time.
Compatibility is a valid reason. You really can't change any parts of a system with so many participants in every country worldwide - you can only add new layers to it.
For those who are interested, this is what I am told is one of the original reasons for inventing the CVV value. Back in the olden days credit card transactions were processed and verified by taking an impression of the card and the raised numbers on the front of the card. To prevent merchants, and/or employees of those merchants from taking credit card numbers off of the impressions and using them to make over the phone transactions (or any transaction where the card is not physically present), the CVV value was created. This is why the CVV value is printed on the back of the card, or if it's on the front of the card then it's not printed on raised type, so that the CVV number will never show up on credit card impressions. This is why the CVV number is often referred to as the "credit card not present" number, and is usually required when making transactions where the card is not physically present to the merchant.
Because way back in the old days they used it have these machines that would run over the card and clone the card information onto carbon paper.
That's why the number is raised on the card.
But those machines are for point of sale purchases only and should NOT get enough information for the card to be used over the phone/internet. Otherwise you'd have tons of carbon sheets that could be used to defraud people.
Also as the other poster said, harder to photograph using a card capture device attached to an ATM/cashpoint.
But you basically can't do anything with a credit card number anyway--there doesn't seem to be much point breaking a long number into 10+ shorter numbers with different security requirements if you need all of the numbers all the time to do anything anyway. It's not like I can make purchases under $5 with just a CC number, but for larger purchases I have to provide more information.
Where companies like Sift interest me is moving from a place where a system determines whether or not it believes a charge is fraudulent to a place where you evaluate the likelihood that an individual transaction is fraudulent. And they're absolutely right that individual components are going to lead to tons of false positives and then eventual end-gaming of their countermeasures.
As an example, in the implosion following the dot-com boom, it was almost impossible for denizens of many Eastern European and African countries to buy things online because the incidence of fraud attributed to their country was high enough that the fraud officers at many online retailers wouldn't chance it. I have a friend who lived in Romania who had a credit card that used my address in the US and frequently required me to ship stuff for him because no companies would ship directly to him. He loves the modern era of fraud evaluation, because while his country is weighted negatively, his use of a respected international bank, an IP address in the same area as his billing address and purchase history with many online companies has greatly reduced his level of hassle due to false positives alleging that he's a fraudster.
Definitely true. A lot of sites just block all transactions from, say, Africa when they start getting hit with fraud. But that's a very broad brush to paint with. It's better to use a machine learning system that looks at many signals so that people like your friend can shop online without being hassled.
About the issue of matching addresses, it seems that the payment processors can't do a fuzzy matching (not sure why), so if your address is "P Sherman 42 Wallaby Way Sydney" and you typed "42 P Sherman Wallaby Way Sydney" you're denied the transaction
Even if you do need to collect some of that information (such as the address if you need to ship a product), several of those fields still remain redundant.
Notably, you should never ask for "credit card type"; the credit card number already tells you that. I like the forms that just ask for a credit card number and then show the computed card type's logo once you've filled it in.
You can also automatically compute the city and state from the zip code, but that requires you to ask for the zip code first, which does break user expectations somewhat.
And please, don't ask for "First Name" and "Last Name" unless you specifically need them separated for some reason; just ask for "Name".
Combining first/last name into a name field and auto-detecting card type were easy wins for the shopper, but in user testing, we found that detecting city/state from a zip code had some potential issues.
First, the format of the form without city/state surprised some users. One user said something like "where do I put my city and state?" They ended up appending it to the street name. Then they filled in the zip code and saw that it fetched the city/state and then realized how it worked then went back to delete it from the street name field.
Also, in the U.S., some zip codes can return multiple cities and states. Our solution was to populate a pull down of the possible values for both fields.
It turns out there are small towns/cities that we didn't return from a zip lookup, so city had to be editable for these users. We added a "Let me type it in" option on the bottom of the city pulldown for those users, who are hopefully the minority.
Perhaps having the user enter their location information in the order country, zip, city, state, street would provide a better experience. It's not what they would be used to, but it's at least consistant (information is entered from less precise to more precise).
Having to build an additional "let me type it in" option seems like it increases the complexity and confusion. One of the banks I use asks for the zip first and then populates the city and state text fields on the lines below. This also has the benefit of working if Javascript is disabled.
What do you do if there are multiple options for the city/state? What if your city happens to not be one of the options you provide? That's why we needed to add an option for the user to fill it in.
In that case the user can type it in themselves. The textfields are fully editable after all. I would expect that it is faster for user to type in the correct city if you get it wrong than for them to have to move their mouse to the keyboard and select it from a drop down list, and if it isn't in the drop down then this method is faster.
I really like your checkout process. It's very pretty and unobtrusive. One note: your dropdown fields don't update when I have focus and type in a value until after I've left the field (unlike the native control which updates as I type) which makes keyboard-only navigation a bit tricky.
For Australia we have the user enter a postcode which then allows them to pick a suburb from a drop down. We have some text next to the postcode field to explain this.
I live in the UK and want to have stuff shipped to family in the US. I've had vendors of all sizes turn away my business because either they didn't like my IP or wouldn't let international addresses order at all.
Amazon(.com) has literally earned themselves thousands in additional sales because they happily accepted my UK payment to a US address without fuss or hassle.
You might say this is a niche situation but money is money, and I've had lot's of small vendors lose out because they were "US only!"
I now also have a "flower guy" because they're the only one in the city who will do international flower orders...
PS - Specific example, NewEgg, wanted to buy a several hundred dollar laptop - couldn't. Used Amazon instead.
Why do you think it is "IP based"? It sounds more like traditional fraud checks requiring the billing and shipping address to be located in the same country.
I hope that's not what the article is suggesting. The way I read it, it's more like what Google and Facebook do: very sophisticated tracking of multiple factors (your IP, geolocation, browser identity, second-factor, etc) to find out if it's really "you" logging in, or someone who's just got your password.
The problems are:
(1) This will never work for a single vendor (unless it's a massive vendor like Amazon, and they're already doing it). It's something the bank has to do so it can tie together all the information about you.
(2) Banks have proven to be totally useless at online security in the past, and I don't see that changing any time soon.
(3) Google-style security can be a bit annoying when you really are logging in from an internet cafe in a foreign country.
Threatmetrix assigns a fraud risk/score based on multiple factors, including the geolocation, IP, & browser. Additionally (to your point #1), they anonymize data across their customers and alert if a device has been flagged in a fraudulent transaction elsewhere. On top of their own customers, they partner with Cybersource so there is quite a network of data behind their fraud analysis.
(I don't work for Threatmetrix- but I do use their product as provided via Cybersource.)
That's exactly it. It's important to look at a whole bunch of factors. For example, fraudsters tend to go directly to the payments page, whereas good users will browse around the site before making a purchase. There are tons of little signals like that which allow you to distinguish legitimate users from the fraudsters.
We don't do things like two-factor auth -- in general, we believe in minimizing friction. It's a better user experience, and if you can prevent fraud without burdening the user, why not?
It is. If you spill the beans that you are checkin staying on site and browsing before buying, and it'll take a week till there's a tool for simulating that.
Will people please stop saying that in this context?
Merchant-side fraud prevention schemes are not security. They are heuristics for reducing the number of bad transactions that the vendor has to handle.
Algorithms should be air-tight. Yes, the best way to ensure that they are is to make them public. Heuristics by definition are not airtight. The best way to get utility from them is to keep their nature hidden from parties trying to abuse the system.
I'm not saying something like that will hold forever. It might take 2 months to figure out that sites check for that, and 2 weeks (/days) to code it up. If you make the information on your heuristic public, those 2 months just drop out straight.
A long time ago we decreased fraud by a significant amount simply by putting a little message on our payment form that we detected fraud. Stolen numbers and identities are really valuable to fraudsters, they tend to prey on merchants they think they can get it by.
Re: the first point. . .no one can go directly to the payment page, don't you have to have something to purchase first? And if, as a user, I've been to the site before, I might select one item and then go directly to payment.
The idea behind machine learning is that no single data point does the changing. It's about modelling you with a computer and determining if the model matches current models of fraudsters. If you do go directly to the payment page, you use tor for your browsing, you auto-delete cookies, and whatever else they check for, you become more clearly likely to be committing fraud. This does not mean, still, that you are committing fraud, only that you probably ought to be inquired about.
It's the same thing with, say, shoplifting. If you own a thrift store, and you see someone come in with a heavy coat, you might think nothing of it. But if that person acts suspiciously and holds his hands in his pockets, you may inquire as to whether that person is shoplifting. Of course, people do walk around suspiciously with hands in the pockets of big coats who are not shoplifting, but false positives like that are removed when the human element steps in at the last stage.
That's only one of several signals they are tracking. There's also what you're ordering, where you're coming from, if you have a history on the site or not. Each one of those getting a pair of scores (likely_fraud, likely_legit) and the decision being made on the balance of probabilities at the time of purchase.
And remember that the goal isn't to absolutely eliminate fraud, it's to reduce it to the point where it has negligible impact on profitability.
Maybe you could add the predictable human irrationalities as an input signal. For example decision paralysis - I'd expect legit customers to take a bit longer for pages that require a decision. Or the way people react to discounts - a fraudster wouldn't care, but a legit customer would be happier and thus less a little bit less focused.
Amazon has a UK presence so it's only natural they accept payments from there. But it's very myopic to insist all other vendors do the same since many don't have the resources to pursue fraud cases overseas. They barely manage to get through locally.
I used to work at a fashion house that didn't ship outside the U.S. simply due to our AVS not being able to valiate addresses outside the 50 states. Losing thousands of dollars to fraud during a bleak economy isn't how people stay in business.
I wasn't either. I'm talking about the billing address, which for most vendors must be in the U.S. for their AVS to work.
Edit: Let me clarify further...
U.S. Businesses rent services here that let their AVS take advantage of anti-fraud measures. Many of these services don't even bother looking at the shipping address, but do look at the billing to make sure the card number matches the account holder information. These services often times have no information on overseas card holders so they have no means to verify whether the actual card holder made the purchase.
Now you also have some vendors who make sure the billing address == shipping address as that's a cheap way to prevent fraud (or at least reduce it). That's not what I was talking about.
If someone uses a stolen credit card with a working address then the AVS has done nothing to mitigate the fraud, if they use a non-working address then it bounces up-stream and the AVS has done nothing, and if there is no fraud then the AVS has done nothing...
So explain to me exactly what the AVS's point is? And how it saves companies money? Isn't it up to the bank to decide what is and is not a valid address for usage with the card?
All you're doing is hitting real customers (including international ones).
AVS doesn't work all that well outside the U.S. (Amex declines it outright) And services that do work outside are often value added (read: expensive) and for businesses that primarily cater to U.S. customers, isn't worth the price. AVS isn't just a "bank service". It's only available to merchants that use a gateway that supports it (same for CVV/2) :
https://support.mivamerchant.com/supportsuite/index.php?/Kno...
And of those gateways, some don't support AVS outside mainland U.S. or only partially.
Those businesses aren't "losing money" by not catering to you. On the contrary, they're saving quite a bit by focusing on local customers.
If your shipping a physical good then it works well, different billing and shipping address can be a red flag. Depending on where the billing address is then it can be easy to stop fraud.
If the causes us to miss out on a few sales it is small price to pay compared to getting hit with chargebacks.
> Now you also have some vendors who make sure the billing address == shipping address as that's a cheap way to prevent fraud (or at least reduce it).
I use a PO box as my billing address. I never have anything shipped to my billing address. Also, my PO box shows up nowhere in my wallet, so, if it gets stolen, at least the thief won't have a valid billing address to use with my cards. And merchants who check billing address will decline his order when it comes through with my driver's license address.
I've never had a problem with an online merchant using the tactic you advocate. However, if I did, I would be royally pissed and bad-mouth the vendor online. Far from reducing fraud, your tactic would serve to increase it!
Refusing to ship a physical product to a first-time customer at anything other than the address where their card is registered seems a sensible practice, and it is certainly in fairly common use here in the UK.
If you tried to order from one of those companies and failed their check, sure, they might lose your order, but it's a game of probabilities and you're making yourself a statistical outlier.
As for going on-line and bad-mouthing a vendor who uses this technique to reduce fraud, that's between you and your conscience, but if you in any way claimed that they were insecure and cost them business, don't be surprised if it becomes between you and their lawyers.
Perhaps you should think about the number of times you've entered a new shop to find some present for someone. Refusing the first sale because the shipping address is different equals to saying FU to most gift orders in my opinion.
As a side note, the most heavy handed and dumb fraud detection processes I ever saw where fom very small shops who would for instance try to hand mail or phone you to have you fax them some doc.
It's a real PITA, but since someone taje time to communicate with you in a people to people level, usually I wouldn't just cancel, and try to make it work out.
>Refusing to ship a physical product to a first-time customer at anything other than the address where their card is registered seems a sensible practice
Knowledge of the billing address is a means of authentication, as is knowledge of the expiration date and the CVV2. A different billing address enhances security, since a typical thief would be expecting the billing address to match whatever fleeting knowledge of the customer he gleaned during the theft. I've done many transactions using a PO box billing address and a street shipping address, all without a problem.
> As for going on-line and bad-mouthing a vendor who uses this technique to reduce fraud, that's between you and your conscience, but if you in any way claimed that they were insecure and cost them business, don't be surprised if it becomes between you and their lawyers.
My conscience says, you inconvenience me, I tell others!
As they say in Texas, Bring It On. In the United States of America, truth is an absolute defense! That means, even if you go out of business because your story was told, you've got no case unless you can prove the story teller lied deliberately while knowing the truth.
Knowledge of the billing address is a means of authentication, as is knowledge of the expiration date and the CVV2.
Right, but requiring that physical products are only ever sent to an address that is known to be associated directly with the card holder, at least the first time when you don't "know" the card holder yet, reduces the likely gain from fraud to near zero for third parties. That is a far more effective deterrent than any minor hurdle in the authentication process.
As they say in Texas, Bring It On. In the United States of America, truth is an absolute defense!
And which truth would that be? If you caused serious damage to a business by claiming this practice made them less secure, I expect they would have no difficulty at all lining up expert witnesses who say they have a very different idea of what makes things more secure. They would have the added advantage that this is a field where lots of people look very carefully at real numbers, so they could probably bring a mountain of statistical data in support of their position.
I use dirt-cheap VPS servers to tunnel web traffic over SSH socks proxies. Why? For fun. Because I can. To thwart ISP packet inspection and Google profiling my IP. To screw up IP-based ad targeting. Whatever.
I often sign up for a new VPS service while relaying from another one. I will often make it through the entire sign-up process, going through the PayPal info and everything, only to be told something like, "Your new account has been suspended due to suspicion of fraud." This only happens when I'm using a proxy. So they must be doing geo-IP lookups and flagging IP space that is a certain variance from your billing address.
I don't know how many VPS providers have lost my business due to this practice.
Well they are probably doing it to avoid headaches later. Maybe your business would be innocuous, but others doing the same thing might have some dirtier business in mind later.
I had to move services running on my VPS because their "fraud detector" would portscan it and find an "open proxy". It's the stupidest thing ever implemented in a payment system.
Neweggs policies on card related issues are insane imho. I've actually had my account banned because my wife used my CC to buy something on her newegg account once. The next time I went to make a purchase my account was banned because the CC i wanted to use was listed in another account. It's worth noting that they didn't have any problems processing `her` order which is where you would want that kind of action to actually happen!
I run an ecommerce site and we sell about 50% in the US and 50% overseas and have a lot of fraud attempts pretty much daily (more outside of the US, but plenty in the US). A couple months ago I built some simple checks that dramatically reduced our handling time of fraud cases. The checks include:
1. Has the credit card been used by any other account holder?
2. Has the shipping address been used by any other account holder?
3. Has the phone number been used by any other account holder?
4. Has the billing address been used by any other account holder?
If any of those are true a warning or info notice is shown depending on the situation. For example, if the shipping address is used by multiple accounts an info notice is shown as there are plenty of times the same address would be used by multiple accounts (freight forwarder, sending parts to a repair shop, etc...). It reminds the order processor to check it out and verify the order is legit.
If the billing, credit card or phone number match it throws a warning as that is far less likely to happen legitimately - which is what you experienced. We don't automatically decline like Newegg did to you, but we do investigate the order thoroughly and if we aren't comfortable with it we will decline or require funds be sent via a verified papal account or wire transfer.
We use a lot of other methods for checking fraud; IP, AVS, etc... but these really simple checks have been really helpful because we get hit by the same people over and over again. They try the same card with multiple accounts or use the same shipping address on multiple accounts, etc...
If an order has been marked as fraud and any of those checks above hit then the new order is automatically marked as fraud too.
Would you use an api service that aggregated addresses and could tell you if a given address was known to be associated with fraud? And that let you add addresses to the 'blacklist'.
I would certainly look at it with much interest. Being able to add an address to the list would be fantastic as well since small retailers like us can't combat fraud alone very efficiently.
I actually would have no problem with them just telling me "hey you can't use this card because it's in another account." It was the severity of the action that was the most frustrating part. I'm still not sure why when the card was in my account to start with it let my wifes purchase go through, that just doesn't make any sense at all to me.
Smart fraud detection will use IP as one of a hundred or so checks. I know of at least one service in the UK that would OK your transaction if it could match your billing info to those US addresses through previous purchases with any of a number of different retailers.
The goals the larger retailers have here are to reduce the number of manual approvals (things like phone follow ups) needed without compromising the fraud rate, not to turn down transactions, so there's a lot of competition for more intelligent detection.
What works for one company may not be acceptable or optimal to other companies. I think the biggest insight is that you should measure these things and see what approach earns you the most money, taking chargebacks into account.
Most of these forms are more complicated because of tax codes and such. If I don't know your name or your address, I can't adequately assess whether I should be collecting sales tax. Failing to collect and report sales tax can come with very hefty fines.
There's a whole bunch of other valid reasons too. If there's a problem, it's nice being able to actually contact your customer. Most businesses need to be able to produce receipts, with some data needed to even count as a receipt ("you were charged X on Y" via email -- which you may not have anyway -- usually doesn't cut it).
And I'd love to see the data on this, but if someone has gotten to the point where they've decided to purchase and are presented with fields that are pretty standard just about everywhere else, I suspect abandonment rate is rather low. The pros just seem to outweigh the cons on this minimalism debate.
If you're shopping for something specific, say for a new hard drive or monitor or something, chances are you've been looking around for awhile and once you're in the checkout process, you've made up your mind to commit to that product. A few extra fields for payment data probably won't deter you.
But on the opposite side of the spectrum, if someone is going to impulse buy, each field you force them to fill out gives them a few more seconds to decide "Eh, I don't really need this..." and abandon. In those cases, you want payments as frictionless as possible. I know I've done some impulse buys a few times after being drawn in via an email campaign or something--and subsequently decided to just forget about making the purchase.
Thanks for bringing the topic up, I always wondered why some sites ask me for only my ZIP next to the CC number, but never really got into finding out why.
A few years ago, gas stations around here starting asking customers to enter their ZIP at the pump. Not long after they started doing that, many added a clarification: billing address ZIP, not residence ZIP. Apparently, some customers thought they were asking for market-research reasons, as opposed to credit card security.
sigh, and where are you going to send your invoices to? or is your plan to issue invoices for the costumers ip's. I am sure the tax authorities will love that.
The interchange fees Visa/MC charge vary with what information is collected. The minimum required info is assumed to be at a higher risk of fraud, so the fee passed to the merchant is more. Sure, some optimization can be done to make online forms easier to use, but collecting more information is necessary to offset the fact that you aren't physically in a store handing someone your card, letting them see the name on your driver's license, etc.
This leads to the question: Does the difference in processing fees outweigh the percentage of sales lost due to increased friction? This will have a different answer for every product and business which makes this a perfect example of something every company should be A/B testing.
If you don't want chargebacks, accept digital cash in addition to credit cards. Give your customers a discount for digital cash, and charge your price + (estimated cost of chargebacks/sales) for a given period. BitPay / Coinbase are probably your best options for accepting non-reversible digital cash.
That works for the current ecosystem. As it is non-anonymous, bitcoin will eventually become infected with chargebacks. For this process to begin, it just takes one sizable stolen-from party getting the ear of an exchange.
Great article. I do think cutting out "account creation" is something to look at. My friend, Joe just launched a very easy to use check out procedure for his new start up - https://www.getphotogasm.com/. Great example.
You can save a bunch of fields in the form (and has nothing to do with fraud):
1. Given postal code, asking for city and state is pretty much useless. There is a unique mapping from postal code -> city, state. Maxmind used to have free db, but you can download it from geonames here: http://download.geonames.org/export/zip/
3. Only American Express supports name verification. Most other banks don't. So, asking name is pretty much useless. If you already have the customer name in you database, use that to fill them in.
4. Things like 'Company' are just not needed.
5. Phone verification is again something supported by very few banks.
That just cut down 7 fields with no compromise on fraud.
Also, any good payment processor will let you store card information (in a secure manner adhering to standards set by Visa, a.k.a being PCI complaint). So, you could just display the last four of the card along with card type and charge them at a later point of time (think Amazon checkout).
So, payment forms need not be nearly as bad as the one pointed out in OP. But, sometime bad design choices and legacy thinking comes in way.
I work for Balanced Payments. When we were PoundPay (previous avatar of our product), we used to serve the payment frame via iframe. Our form looked like this:
http://imgur.com/wF2Z2qZ
It encapsulates lot of points I discussed earlier.
It's not true that zip codes are unique to a particular city and state in the United States. Where I live, for instance, several couple of cities share the same post office - and thus zip code. It does cause confusion in some instances, especially with address verification.
There have been times when I have had to put the wrong city in my address because of zip code enforcement. Fortunately, the post office does a pretty good job delivering anyway.
Good to know and thanks for the input. I would assume this is a corner case and does not represent a typical situation. In this case, one could just send in the zip code for avs match. AVS will return specific codes related to postal code match. Here gain there's a tradeoff, I don't see the point of compromising the UX for 99% to cover the 1% case.
Good point, but as far as I've seen, zipcode seems to identifies locality good enough. If you have the right zipcode it doesn't make a material difference for either sending/receiving mail or for credit card checks.
For cases where one zip code covers parts of two or three cities, it would also be possible to present some kind of drop-down to select the city. This should still be much faster and less error prone than typing, and it only applies to a tiny fraction of zip codes.
Actually, I think asking for the customer name in your payment form is good. It's what's expected and it gives you more information to match against (i.e. the name in your customer database to the name they link to the card).
Seems to me that the form itself is just one small corner of a larger battlefield and the real trick to using it effectively is threefold.
For users, it's about creating a user experience that is comforting and normal enough to gain user confidence and easy/frictionless enough to make the transactions painless.
For merchants it's about information gathering and screening. It's about being able to collect information about the user's payment card and comparing it to what you already know about the prospective buyer and depending on the your size and fraud levels, the form may also be a point where you make it more difficult to programmatically try cards (i.e. randomized form fields, rate limiting, err... captcha).
For #1, the zip code 42223 spans Christian KY and Montgomery TN. The zip code 97635 spans Lake OR and Modoc CA. 95961 can be the city of Arboga, Olivehurst, or Plumas Lake.
The mapping isn't unique. I think the best you can do is restrict your pulldown to the possible choices. Even then, sometimes there are small cities and towns that you don't expect.
We're thinking of actually open sourcing this iframe - it took a lot of work and analytics to get it to where it should be and we think the community could benefit.
I would definitely like to see this open sourced, ideally not in an iframe, and maybe with a few different variants for collecting different amounts of information, for those with different priorities among security/convenience.
Given postal code, asking for city and state is pretty much useless.
This view is US-centric. Others have pointed out that there are cases even in the US where this may cause confusion.
But for me, the bigger problem is that asking for state is counter-productive. The state and country are the same thing for me. Some sites force users to put something in the state field, whatever country. Other sites explicitly check the country and reject input if there is a state specified for a country that doesn't have them. You never know. Most of the time it fortunately makes no difference. But it's a slight annoyance.
There is another reason as well - at least in the UK if you are VAT registered. You need to know if your customer is in the UK, EU or outside of the EU, and if they are a business or not (their own VAT registration number), so you know if you need to charge them VAT or not. When the tax man comes calling, you need accountability to ensure that you have been charging the correct amount to the correct people.
Extremely frustrating for purchasers and sellers to need to provide and collect all of that information simply to accept a payment. Far too much friction.
Although you do need to know whether your customer is in the UK or not, you can collect that through the address. You don't need to know whether the customer is a business - if you're providing VAT receipts then the business in question can claim the VAT back anyway.
Often people will deduct VAT at the point of sale for businesses as a convenience, but it's not mandatory or required.
Fraud is a huge motivation but one thing the article doesn't mention is sales tax.
When I sell a product online, I need to charge sales tax if the customer lives in Canada, a different tax if the customer lives in my province, or no tax if the customer lives in another country. Therefore, I'm forced to ask for the customer's address just for this.
That said, I can probably still avoid asking for a lot of the info but this requirement still increases the minimum set.
In the US, at least, there are many thousands of different geographically-based taxing jurisdictions, so you really do need to know the address, not just the ZIP code, in order to get it right.
I had a relatively simple payment form for a while, but I found I was being hit with a huge amount of fraud transactions and had to manually review each transaction at the end of each day to see if any looked suspicious and issue a refund.
I switched to using MinFraud automatic fraud detection. Unfortunately, their system requires that the customer provide their country, city, and postal code. They run over a dozen different checks from IP address, proxy detection, distance from IP to provided ZIP code, etc. I haven't had a single chargeback since I started using it.
For me, my product sells for $8 and a charge back is $15. For me it ended up worth while to implement the larger payment form in exchange for eliminating chargebacks.
I really wish that payments could be made simpler, but that would require that processors do much more vigorous fraud checks and they don't have a financial incentive to do so (they make their normal fees from fraudulent transactions that aren't caught).
172 comments
[ 5.0 ms ] story [ 222 ms ] threadIn our experience, you can stop most fraud without putting up roadblocks for your users. Every site is different, but to give an example, we were able detect 90% of fraud for a site with a huge fraud problem without requiring any extra verification from the users.
The really key penalty to avoid is what is called an "excessive chargeback program," which usually triggers for chargeback rates that exceed 1%. You initially get a warning, and if you can't get your chargeback rate down, your payment processor has the right to shut you off. If you're in an excessive chargeback program, then I'd definitely recommend "playing it safe."
But otherwise, I think slimming down your payment form and carefully measuring the effect on fraud is almost always a smart business move.
No, you don't. You need more information about the transaction then that. What if your profit margin is 1%? Then you've come out even, because chargebacks cost you the full cost of an item, but an extra conversion only nets you the profit on that sale.
Note: I assumed that the 0.1% and 50% to 60% were both percentages of potential sales, because it made the math easier. Otherwise, you have 20% x 1%=2% more profit and .2% x 120%-.1%=.14% more loss from chargebacks, so you have come out slightly ahead.
Of course, ideally every citizen would be able to sign anything with a public-private key pair, counter-signed by the state.
It's especially bad since just about no websites I ever buy anything from use VbV / SecurePay. That means that I don't remember the authentication secrets off the top of my head, so unless I'm at home will likely abort the extremely rare transactions that really require it. I've maybe needed VbV once in the last year, and had to try 3 cards before I found one that I could use on the spot.
I think I abandoned every such purchase on reflex because it just screamed phishing attempt each time.
Extremely high friction indeed. Most merchants these days give me the option to skip it. Thank you.
It's thoroughly stupid and broken.
State-verified identity for payments is your ideal case?
Have you heard of Wikileaks?
On top of that, there is no published date, but it does mention May 2007 being in the future. Six years is an eternity in the ecommerce space, and I have a feeling people are more familiar with what the CVV code is and where it is located today.
Fine, here's the thing, if the person can't find the CVV in the card, I don't want his business. Period
This is how the purchasing experience looks like with Bitcoin which, for merchants, solves the fraud problem. Hence buyers do not need to give any billing information.
How is 'xxx' determined?
Looks like a great place to install malware that overtops the sites QR with its own and sends the payment off to the wrong place.
I just finished a simple gift certificate purchase page[1] for a client where I attempted to cut out all unnecessary details; the client's immediate response? "Looks good, but can we add some more fields like name, address, and security code to make it look more 'official'".
Edit: I don't necessarily disagree with their intuition; I think some consumers might actually be suspicious of a sparse payment form but I don't have any hard data.
[1] https://motorcycle.ctec.ca/gifts.html
We do have one difference though (which I would call a simplication): For the expiration date, we just have input boxes for the person to enter it instead of a dropdown. Select boxes are great if a) You can pick a sane default and b) you don't have many options. For a CC form, both of these fail. You cannot set the default with anything better than random accuracy, and each box probably has at least 10 options. Additionally, the expiration date box says "2 - February". I have a lot of credit cards, and none of them say the name of the month on it, only the number. Why waste the space?
The user just typed in their 16-digit credit card number, just pop them right into the expiration date input boxes for them to type in their month and year free-form. Don't make them put the credit card down, pick up the mouse, then have to navigate select boxes with tiny print.
Use a lot (more then your sample size) of different credit cards and you'll see some only have 'FEB' or others 'February' and no numerical month at all. Others have the year as '14' or '2014'. It would have been better if the card issuers decided on a standard quite some time ago.
This might seem really petty, but I'm always a little annoyed when I have to mentally convert the number on my credit card into a month. It always takes a moment to remember that 04 is March, or whatever. It's much easier just to type the value.
When the user types 'Juny' did he mean June or July.
The longer drop down option of '07 - JULY' shows all the combinations that I've seen printed on cards with the least potential of failure.
I do believe your reply has validated my point with the error it contains.
In the expiry drop-down, we have all possible permutations:
1, 2, 3, ... 12; 01, 02, 03, ... 12; jan, feb, dec
and for the year 13, 14, ... 22 and 2013, 2014, ... 2022
Basically, I addressed my own pet peeve of never knowing what format the drop-down contents would be in and therefore never being able to select it via the keyboard correctly.
What I would really like would be some way of having all those permutations, but when the user actually clicks the drop-down (instead of keying in the stub) only one of those sets is displayed.
(Bad first-hand experience looking for work-arounds.)
Also, if I type Tex and then click on the next field, it just drops my selection.
Not trying to kvetch, just feedback =p
The way they're doing things at the moment is driving people to pay via PayPal, because PayPal requires--hey look!--a single string which they call a "password".
It may be an extra layer of protection related to getting the credit card number via seeing or taking a picture of the front of the card, having it on the back helps improve security from that aspect.
That means in theory, if the merchant's credit card database gets hacked, the fraudsters will get access to the credit card numbers but not the CVV.
In practice, the rules aren't obeyed as strictly as they might, so you can easily find credit cards with CVV on the black market.
I don't really care if someone mandates that digits 1-4 can be sent via email, digits 5-10 can be stored unencrypted, digits 11-16 must be encrypted, and digits 17-20 can never be stored at all. They're still just digits/bits of information, and I have to provide all of them almost all the time anyway.
The one exception is when a retailer has saved my credit card number, in which case they might ask me for the CVV only. But I'd rather that they didn't save the card number at all! I have to look up the CVV and copy and paste it into their form every time anyway--so they may as well require the whole thing every time.
That's why the number is raised on the card.
But those machines are for point of sale purchases only and should NOT get enough information for the card to be used over the phone/internet. Otherwise you'd have tons of carbon sheets that could be used to defraud people.
Also as the other poster said, harder to photograph using a card capture device attached to an ATM/cashpoint.
As an example, in the implosion following the dot-com boom, it was almost impossible for denizens of many Eastern European and African countries to buy things online because the incidence of fraud attributed to their country was high enough that the fraud officers at many online retailers wouldn't chance it. I have a friend who lived in Romania who had a credit card that used my address in the US and frequently required me to ship stuff for him because no companies would ship directly to him. He loves the modern era of fraud evaluation, because while his country is weighted negatively, his use of a respected international bank, an IP address in the same area as his billing address and purchase history with many online companies has greatly reduced his level of hassle due to false positives alleging that he's a fraudster.
DON'T RELY ON ZIP CODE ALONE
For one, you don't know the different formats of zip codes around the world
Second: not all countries have Zip Codes. Like Ireland, for example.
See here: http://www.google.ie/about/jobs/locations/dublin/ "Dublin 4" is the "Zip code"
About the issue of matching addresses, it seems that the payment processors can't do a fuzzy matching (not sure why), so if your address is "P Sherman 42 Wallaby Way Sydney" and you typed "42 P Sherman Wallaby Way Sydney" you're denied the transaction
Notably, you should never ask for "credit card type"; the credit card number already tells you that. I like the forms that just ask for a credit card number and then show the computed card type's logo once you've filled it in.
You can also automatically compute the city and state from the zip code, but that requires you to ask for the zip code first, which does break user expectations somewhat.
And please, don't ask for "First Name" and "Last Name" unless you specifically need them separated for some reason; just ask for "Name".
http://crop.to/fW
Combining first/last name into a name field and auto-detecting card type were easy wins for the shopper, but in user testing, we found that detecting city/state from a zip code had some potential issues.
First, the format of the form without city/state surprised some users. One user said something like "where do I put my city and state?" They ended up appending it to the street name. Then they filled in the zip code and saw that it fetched the city/state and then realized how it worked then went back to delete it from the street name field.
Also, in the U.S., some zip codes can return multiple cities and states. Our solution was to populate a pull down of the possible values for both fields.
It turns out there are small towns/cities that we didn't return from a zip lookup, so city had to be editable for these users. We added a "Let me type it in" option on the bottom of the city pulldown for those users, who are hopefully the minority.
Having to build an additional "let me type it in" option seems like it increases the complexity and confusion. One of the banks I use asks for the zip first and then populates the city and state text fields on the lines below. This also has the benefit of working if Javascript is disabled.
I live in the UK and want to have stuff shipped to family in the US. I've had vendors of all sizes turn away my business because either they didn't like my IP or wouldn't let international addresses order at all.
Amazon(.com) has literally earned themselves thousands in additional sales because they happily accepted my UK payment to a US address without fuss or hassle.
You might say this is a niche situation but money is money, and I've had lot's of small vendors lose out because they were "US only!"
I now also have a "flower guy" because they're the only one in the city who will do international flower orders...
PS - Specific example, NewEgg, wanted to buy a several hundred dollar laptop - couldn't. Used Amazon instead.
On the internet, everything is measurable, and fraudsters leave behind tracks they’re not even aware of. What IP address is the user coming from?
edit: oh, you probably mean 'why do you think (random business) refusal is IP based'.
The problems are:
(1) This will never work for a single vendor (unless it's a massive vendor like Amazon, and they're already doing it). It's something the bank has to do so it can tie together all the information about you.
(2) Banks have proven to be totally useless at online security in the past, and I don't see that changing any time soon.
(3) Google-style security can be a bit annoying when you really are logging in from an internet cafe in a foreign country.
(I don't work for Threatmetrix- but I do use their product as provided via Cybersource.)
We don't do things like two-factor auth -- in general, we believe in minimizing friction. It's a better user experience, and if you can prevent fraud without burdening the user, why not?
We have more information with some examples of signals our system uses here: https://siftscience.com/large-scale-machine-learning
Merchant-side fraud prevention schemes are not security. They are heuristics for reducing the number of bad transactions that the vendor has to handle.
Algorithms should be air-tight. Yes, the best way to ensure that they are is to make them public. Heuristics by definition are not airtight. The best way to get utility from them is to keep their nature hidden from parties trying to abuse the system.
It's the same thing with, say, shoplifting. If you own a thrift store, and you see someone come in with a heavy coat, you might think nothing of it. But if that person acts suspiciously and holds his hands in his pockets, you may inquire as to whether that person is shoplifting. Of course, people do walk around suspiciously with hands in the pockets of big coats who are not shoplifting, but false positives like that are removed when the human element steps in at the last stage.
That doesn't seem very defensible.
And remember that the goal isn't to absolutely eliminate fraud, it's to reduce it to the point where it has negligible impact on profitability.
Except that enables people to gain information about your fraud detection system.
Seriously, they blocked the entirety of Linode's IPv6 range and there's absolutely nothing you can do about it.
Well, you can submit a false flag report, but Google customer support for suspected bots isn't great.
Amazon has a UK presence so it's only natural they accept payments from there. But it's very myopic to insist all other vendors do the same since many don't have the resources to pursue fraud cases overseas. They barely manage to get through locally.
I used to work at a fashion house that didn't ship outside the U.S. simply due to our AVS not being able to valiate addresses outside the 50 states. Losing thousands of dollars to fraud during a bleak economy isn't how people stay in business.
Amazon UK has nothing to do with the transaction. It is all through Amazon (US/.Com).
Edit: Let me clarify further...
U.S. Businesses rent services here that let their AVS take advantage of anti-fraud measures. Many of these services don't even bother looking at the shipping address, but do look at the billing to make sure the card number matches the account holder information. These services often times have no information on overseas card holders so they have no means to verify whether the actual card holder made the purchase.
Now you also have some vendors who make sure the billing address == shipping address as that's a cheap way to prevent fraud (or at least reduce it). That's not what I was talking about.
If someone uses a stolen credit card with a working address then the AVS has done nothing to mitigate the fraud, if they use a non-working address then it bounces up-stream and the AVS has done nothing, and if there is no fraud then the AVS has done nothing...
So explain to me exactly what the AVS's point is? And how it saves companies money? Isn't it up to the bank to decide what is and is not a valid address for usage with the card?
All you're doing is hitting real customers (including international ones).
http://en.wikipedia.org/wiki/Address_Verification_System
AVS doesn't work all that well outside the U.S. (Amex declines it outright) And services that do work outside are often value added (read: expensive) and for businesses that primarily cater to U.S. customers, isn't worth the price. AVS isn't just a "bank service". It's only available to merchants that use a gateway that supports it (same for CVV/2) : https://support.mivamerchant.com/supportsuite/index.php?/Kno...
And of those gateways, some don't support AVS outside mainland U.S. or only partially.
Those businesses aren't "losing money" by not catering to you. On the contrary, they're saving quite a bit by focusing on local customers.
If the causes us to miss out on a few sales it is small price to pay compared to getting hit with chargebacks.
Also AVS works fine in the UK as well as the US.
I use a PO box as my billing address. I never have anything shipped to my billing address. Also, my PO box shows up nowhere in my wallet, so, if it gets stolen, at least the thief won't have a valid billing address to use with my cards. And merchants who check billing address will decline his order when it comes through with my driver's license address.
I've never had a problem with an online merchant using the tactic you advocate. However, if I did, I would be royally pissed and bad-mouth the vendor online. Far from reducing fraud, your tactic would serve to increase it!
If you tried to order from one of those companies and failed their check, sure, they might lose your order, but it's a game of probabilities and you're making yourself a statistical outlier.
As for going on-line and bad-mouthing a vendor who uses this technique to reduce fraud, that's between you and your conscience, but if you in any way claimed that they were insecure and cost them business, don't be surprised if it becomes between you and their lawyers.
As a side note, the most heavy handed and dumb fraud detection processes I ever saw where fom very small shops who would for instance try to hand mail or phone you to have you fax them some doc.
It's a real PITA, but since someone taje time to communicate with you in a people to people level, usually I wouldn't just cancel, and try to make it work out.
Knowledge of the billing address is a means of authentication, as is knowledge of the expiration date and the CVV2. A different billing address enhances security, since a typical thief would be expecting the billing address to match whatever fleeting knowledge of the customer he gleaned during the theft. I've done many transactions using a PO box billing address and a street shipping address, all without a problem.
> As for going on-line and bad-mouthing a vendor who uses this technique to reduce fraud, that's between you and your conscience, but if you in any way claimed that they were insecure and cost them business, don't be surprised if it becomes between you and their lawyers.
My conscience says, you inconvenience me, I tell others!
As they say in Texas, Bring It On. In the United States of America, truth is an absolute defense! That means, even if you go out of business because your story was told, you've got no case unless you can prove the story teller lied deliberately while knowing the truth.
Right, but requiring that physical products are only ever sent to an address that is known to be associated directly with the card holder, at least the first time when you don't "know" the card holder yet, reduces the likely gain from fraud to near zero for third parties. That is a far more effective deterrent than any minor hurdle in the authentication process.
As they say in Texas, Bring It On. In the United States of America, truth is an absolute defense!
And which truth would that be? If you caused serious damage to a business by claiming this practice made them less secure, I expect they would have no difficulty at all lining up expert witnesses who say they have a very different idea of what makes things more secure. They would have the added advantage that this is a field where lots of people look very carefully at real numbers, so they could probably bring a mountain of statistical data in support of their position.
I use dirt-cheap VPS servers to tunnel web traffic over SSH socks proxies. Why? For fun. Because I can. To thwart ISP packet inspection and Google profiling my IP. To screw up IP-based ad targeting. Whatever.
I often sign up for a new VPS service while relaying from another one. I will often make it through the entire sign-up process, going through the PayPal info and everything, only to be told something like, "Your new account has been suspended due to suspicion of fraud." This only happens when I'm using a proxy. So they must be doing geo-IP lookups and flagging IP space that is a certain variance from your billing address.
I don't know how many VPS providers have lost my business due to this practice.
1. Has the credit card been used by any other account holder? 2. Has the shipping address been used by any other account holder? 3. Has the phone number been used by any other account holder? 4. Has the billing address been used by any other account holder?
If any of those are true a warning or info notice is shown depending on the situation. For example, if the shipping address is used by multiple accounts an info notice is shown as there are plenty of times the same address would be used by multiple accounts (freight forwarder, sending parts to a repair shop, etc...). It reminds the order processor to check it out and verify the order is legit.
If the billing, credit card or phone number match it throws a warning as that is far less likely to happen legitimately - which is what you experienced. We don't automatically decline like Newegg did to you, but we do investigate the order thoroughly and if we aren't comfortable with it we will decline or require funds be sent via a verified papal account or wire transfer.
We use a lot of other methods for checking fraud; IP, AVS, etc... but these really simple checks have been really helpful because we get hit by the same people over and over again. They try the same card with multiple accounts or use the same shipping address on multiple accounts, etc...
If an order has been marked as fraud and any of those checks above hit then the new order is automatically marked as fraud too.
The goals the larger retailers have here are to reduce the number of manual approvals (things like phone follow ups) needed without compromising the fraud rate, not to turn down transactions, so there's a lot of competition for more intelligent detection.
There's a whole bunch of other valid reasons too. If there's a problem, it's nice being able to actually contact your customer. Most businesses need to be able to produce receipts, with some data needed to even count as a receipt ("you were charged X on Y" via email -- which you may not have anyway -- usually doesn't cut it).
And I'd love to see the data on this, but if someone has gotten to the point where they've decided to purchase and are presented with fields that are pretty standard just about everywhere else, I suspect abandonment rate is rather low. The pros just seem to outweigh the cons on this minimalism debate.
I'd say it depends on the situation.
If you're shopping for something specific, say for a new hard drive or monitor or something, chances are you've been looking around for awhile and once you're in the checkout process, you've made up your mind to commit to that product. A few extra fields for payment data probably won't deter you.
But on the opposite side of the spectrum, if someone is going to impulse buy, each field you force them to fill out gives them a few more seconds to decide "Eh, I don't really need this..." and abandon. In those cases, you want payments as frictionless as possible. I know I've done some impulse buys a few times after being drawn in via an email campaign or something--and subsequently decided to just forget about making the purchase.
If you don't want chargebacks, accept digital cash in addition to credit cards. Give your customers a discount for digital cash, and charge your price + (estimated cost of chargebacks/sales) for a given period. BitPay / Coinbase are probably your best options for accepting non-reversible digital cash.
1. Given postal code, asking for city and state is pretty much useless. There is a unique mapping from postal code -> city, state. Maxmind used to have free db, but you can download it from geonames here: http://download.geonames.org/export/zip/
2. You don't need to ask for card type given card number. Again, simple regex. Reference: http://stackoverflow.com/questions/72768/how-do-you-detect-c...
3. Only American Express supports name verification. Most other banks don't. So, asking name is pretty much useless. If you already have the customer name in you database, use that to fill them in.
4. Things like 'Company' are just not needed.
5. Phone verification is again something supported by very few banks.
That just cut down 7 fields with no compromise on fraud.
Also, any good payment processor will let you store card information (in a secure manner adhering to standards set by Visa, a.k.a being PCI complaint). So, you could just display the last four of the card along with card type and charge them at a later point of time (think Amazon checkout).
So, payment forms need not be nearly as bad as the one pointed out in OP. But, sometime bad design choices and legacy thinking comes in way.
I work for Balanced Payments. When we were PoundPay (previous avatar of our product), we used to serve the payment frame via iframe. Our form looked like this: http://imgur.com/wF2Z2qZ
It encapsulates lot of points I discussed earlier.
There have been times when I have had to put the wrong city in my address because of zip code enforcement. Fortunately, the post office does a pretty good job delivering anyway.
Seems to me that the form itself is just one small corner of a larger battlefield and the real trick to using it effectively is threefold.
For users, it's about creating a user experience that is comforting and normal enough to gain user confidence and easy/frictionless enough to make the transactions painless.
For merchants it's about information gathering and screening. It's about being able to collect information about the user's payment card and comparing it to what you already know about the prospective buyer and depending on the your size and fraud levels, the form may also be a point where you make it more difficult to programmatically try cards (i.e. randomized form fields, rate limiting, err... captcha).
The mapping isn't unique. I think the best you can do is restrict your pulldown to the possible choices. Even then, sometimes there are small cities and towns that you don't expect.
We're thinking of actually open sourcing this iframe - it took a lot of work and analytics to get it to where it should be and we think the community could benefit.
Let us know if there's interest. Create an issue on https://github.com/balanced/balanced-api/issues/ and we'll see how to prioritize it.
This view is US-centric. Others have pointed out that there are cases even in the US where this may cause confusion.
But for me, the bigger problem is that asking for state is counter-productive. The state and country are the same thing for me. Some sites force users to put something in the state field, whatever country. Other sites explicitly check the country and reject input if there is a state specified for a country that doesn't have them. You never know. Most of the time it fortunately makes no difference. But it's a slight annoyance.
Extremely frustrating for purchasers and sellers to need to provide and collect all of that information simply to accept a payment. Far too much friction.
Often people will deduct VAT at the point of sale for businesses as a convenience, but it's not mandatory or required.
When I sell a product online, I need to charge sales tax if the customer lives in Canada, a different tax if the customer lives in my province, or no tax if the customer lives in another country. Therefore, I'm forced to ask for the customer's address just for this.
That said, I can probably still avoid asking for a lot of the info but this requirement still increases the minimum set.
[1] https://dl.dropbox.com/u/8554242/dmitri/pay.html
I switched to using MinFraud automatic fraud detection. Unfortunately, their system requires that the customer provide their country, city, and postal code. They run over a dozen different checks from IP address, proxy detection, distance from IP to provided ZIP code, etc. I haven't had a single chargeback since I started using it.
For me, my product sells for $8 and a charge back is $15. For me it ended up worth while to implement the larger payment form in exchange for eliminating chargebacks.
I really wish that payments could be made simpler, but that would require that processors do much more vigorous fraud checks and they don't have a financial incentive to do so (they make their normal fees from fraudulent transactions that aren't caught).