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.
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.
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.
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.
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.
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.
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.