The reason why payment forms are so complicated is because the credit card model is completely broken. Instead of transferring money from your account to their account, you give the other person unlimited and irrevocable access to your account, and then that person takes the money. This is a hilariously stupid way to transfer money. Once they have your credit card number, they can continue to take as much money as they want. Even worse, if they lose the number to some attack, the attacker can take money.
A much better system would be if you could get a temporary number where the merchant can withdraw exactly the amount you need to pay and no more. No charge-backs possible. That's not a problem since the reason we need charge-backs is to patch up the fact that people can randomly take money from you just by knowing the credit card number, which you need to send around to make payments.
Even better is this. At checkout the merchant's site would redirect you to yourbank.com/makepayment?amount=X&target=themerchantsaccount. There you would log in (if you were not already logged in) and click confirm, and the bank would send the money to the merchant. Very user friendly and secure, and no chargebacks. In the Netherlands we have such a system, it's called iDEAL and pretty much all dutch e-commerce uses this. The nice thing is that if your bank is secure, it's secure. You are not relying on thousands of individual merchants implementing security correctly, and you are not relying on the merchant not being evil.
You nailed it. Some time ago, my Amex business card had a feature called Private Payments. Basically, whenever you wanted to make a purchase, you would generate a one-time use number that could be used in place of your actual number. Not sure why they did away with it, but I figured it either became a hassle for them to support it or someone figured out how to defraud it. The latter would be insanely ironic, of course.
But, your point in general regarding the fact that divulging your info for one simple payment can expose you so horrendously is very true. Same with other info, like your SSN.
Too much of our current approach to "security" is based on protecting access to informarion, which is the core problem. In my business, we work with a number of retailers, large and small. It is breath-taking how exposed and naive some of these guys are. And, they are handling personal info for millions of people.
In general, we should have learned long ago that it is impossible to secure the data in all cases, so we need systems and processes that assume the data will fall into the wrong hands.
When I moved to NL I was really amazed by this system (no more writing checks!). Since the bank itself is in charge of the payment form, the incentives to fix security are in the right place.
Of course, this is easy to do in a small country with less than 10 banks, which all trust one another.
I had that idea a while back (haven't done anything with it). I was thinking more along the lines of separate PIN numbers for ATMs/at checkout. You would set up different PIN numbers on your account (on the bank website), with specific conditions, like transfer limit, time limits, $X allowed per day.
> Card, PIN 1234 -> bank -> access John Smith's account -> access "1234" setting (max transaction of $50 otherwise declined).
> Cart, PIN 2345 -> bank -> John Smith -> 2345 is only valid on weekdays
I originally thought of it as a way for parents to loan kids their cards, give them a temporary PIN to use.
Might make more sense to adapt it into the CVV system (or a new system), where each specific CVV would correspond to a setting you determine. They can be created by you quickly and securely with a bunch of constraints.
But then I realised I had no idea how CCs worked, and assumed I'd either have to get a bank on board, or a CC company to implement it, and gave up.
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.
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.
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.
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.
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 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.
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.
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.
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.
At Stripe, we've had to take a lot of these considerations into account when designing the Checkout. One particular bug-bear of mine is people disabling autocomplete on their credit-card forms.
Turns out that modern browsers (e.g. Safari/Chrome) encrypt CC data on disk, and that it's entirely PCI compliant to turn on autocomplete. The only field we don't do so (and that the browser doesn't store) is the CVC field.
Another tip is adding 'pattern="\d*"' to number/cvc/expiry inputs. That'll bring up a numeric keyboard in mobile browsers.
Lastly we've open sourced a library that'll do a lot of the client side validation and credit card number formatting for you: https://github.com/stripe/jquery.payment
Full disclosure: I work on the team that implemented this feature.
On Wave Invoices [1] we try to make it ridiculously easy for people to get paid. As such, we have a very select number of fields that are mandatory and don't require things like address, country, province, phone number, etc.
The payment amount is already filled in - set to the full amount of the invoice in question. The rest is relatively easy to fill out.
We use the awesome jquery.payment [2] and Stripe.js [3] on this form so you get formatted input - like on the credit card number and expiry date - and inline validation.
I just implemented Stripe payments on my first side project [1], but the jquery payment plugin wasn't on the radar when I was building it. Are there any advantages to using it over the jquery validator as seen in one of Stripe's payment examples? [2].
By the way, getting everything up and running with Stripe was a dream, it's an amazing product. Great work.
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.
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.
Don't forget, the amount of fraud that you need to worry about depends highly on the service or product you're selling. My company has only dealt with one fraudulent charge for $65 over the past 5 years of selling our product across a huge number of transactions.
No thief in their right mind would want to steel a Software as a Service product like ours since you can't really resell it. If they were reselling it we'd quickly find out about it and disable the account.
If we were selling hardware or an item that a thief could turn around and resell without any trace, we'd have to worry quite a bit more about fraud.
I'd hate for somebody who is running a SaaS company to read this and implement some insane IP/Tor/blah fraud detection scheme when the nature of their product/transactions doesn't necessitate it.
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.
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).
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
So I recently went from one of these simple forms to a more complex one due to a client's request. I did this because his customers were complaining that they didn't understand why they didn't have to fill out all this information. Everyone else makes them fill it out and they thought it was an problem or scam of some sort.
I implemented a full form asking for all their information and toss out everything during processing. It's a very silly thing but it makes customers feel better about the checkout process for some unknown reason to me...
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.
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.
This is all silly and retarded in my opinion. Consumer credit authentication is in the stone age. What happened to two factor authentication?
If someone steals your social security number they can open accounts in your name. To stop it you have to call one of the credit bureaus and they will put an "alert" on your account together with a phone number. What most creditors do when they see this alert is call that phone number and make sure it's really you opening the account.
Really? Why isn't that just the default? Are you opening credit accounts so often you are majorly inconvenienced to make sure someone verifies it's you by calling the number you selected?
Similarly with credit cards. They could just text your phone to confirm that you really are about to purchase something. You could turn this off EXPLICITLY, and turn it back on when you lose your credit card.
If everyone used "Verified By Visa" or PayPal oauth-type portals for payment, this wouldn't happen. When your bank password is compromised, you can just change it. To do this, you simply ask them to send you an authentication code at a previously supplied email address -- two factor authentication. But now it's too late, because anyone who accepts your credit card can steal it, and use it a year later.
For that matter, why do we use Social Security Numbers and Credit Card Numbers for such important things? It's a relic of terrible one-factor authentication. That signature stripe was probably supposed to be used to match your signature that you sign the receipt with. Well, no one does that.
All you have to do is go on the site, purchase something using two lines, and they text you on your phone. You can turn it off explicitly. Then the law and the liabilities can change with such merchants. Of course, this will take years.
In fact, why doesn't one of the credit card companies simply implement their Verified By Visa thing with two factor authentication, which you can turn off for merchants at whom you recently made physical purchases and previously used shipping addresses?
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.
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.
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.
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?
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.
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.
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.
[+] [-] jules|13 years ago|reply
A much better system would be if you could get a temporary number where the merchant can withdraw exactly the amount you need to pay and no more. No charge-backs possible. That's not a problem since the reason we need charge-backs is to patch up the fact that people can randomly take money from you just by knowing the credit card number, which you need to send around to make payments.
Even better is this. At checkout the merchant's site would redirect you to yourbank.com/makepayment?amount=X&target=themerchantsaccount. There you would log in (if you were not already logged in) and click confirm, and the bank would send the money to the merchant. Very user friendly and secure, and no chargebacks. In the Netherlands we have such a system, it's called iDEAL and pretty much all dutch e-commerce uses this. The nice thing is that if your bank is secure, it's secure. You are not relying on thousands of individual merchants implementing security correctly, and you are not relying on the merchant not being evil.
Or bitcoin of course.
[+] [-] unclebucknasty|13 years ago|reply
But, your point in general regarding the fact that divulging your info for one simple payment can expose you so horrendously is very true. Same with other info, like your SSN.
Too much of our current approach to "security" is based on protecting access to informarion, which is the core problem. In my business, we work with a number of retailers, large and small. It is breath-taking how exposed and naive some of these guys are. And, they are handling personal info for millions of people.
In general, we should have learned long ago that it is impossible to secure the data in all cases, so we need systems and processes that assume the data will fall into the wrong hands.
[+] [-] furyg3|13 years ago|reply
Of course, this is easy to do in a small country with less than 10 banks, which all trust one another.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] decadentcactus|13 years ago|reply
> Card, PIN 1234 -> bank -> access John Smith's account -> access "1234" setting (max transaction of $50 otherwise declined).
> Cart, PIN 2345 -> bank -> John Smith -> 2345 is only valid on weekdays
I originally thought of it as a way for parents to loan kids their cards, give them a temporary PIN to use.
Might make more sense to adapt it into the CVV system (or a new system), where each specific CVV would correspond to a setting you determine. They can be created by you quickly and securely with a bunch of constraints.
But then I realised I had no idea how CCs worked, and assumed I'd either have to get a bank on board, or a CC company to implement it, and gave up.
[+] [-] rokhayakebe|13 years ago|reply
[+] [-] UnoriginalGuy|13 years ago|reply
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.
[+] [-] rwmj|13 years ago|reply
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.
[+] [-] eksith|13 years ago|reply
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.
[+] [-] ratherbefuddled|13 years ago|reply
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.
[+] [-] seany|13 years ago|reply
[+] [-] SageRaven|13 years ago|reply
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.
[+] [-] nwh|13 years ago|reply
[+] [-] mrb|13 years ago|reply
[+] [-] sawyer|13 years ago|reply
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
[+] [-] maccman|13 years ago|reply
Turns out that modern browsers (e.g. Safari/Chrome) encrypt CC data on disk, and that it's entirely PCI compliant to turn on autocomplete. The only field we don't do so (and that the browser doesn't store) is the CVC field.
Another tip is adding 'pattern="\d*"' to number/cvc/expiry inputs. That'll bring up a numeric keyboard in mobile browsers.
Lastly we've open sourced a library that'll do a lot of the client side validation and credit card number formatting for you: https://github.com/stripe/jquery.payment
[+] [-] nickpresta|13 years ago|reply
On Wave Invoices [1] we try to make it ridiculously easy for people to get paid. As such, we have a very select number of fields that are mandatory and don't require things like address, country, province, phone number, etc.
Here is an example: http://i.imgur.com/yqSUMNb.png
The payment amount is already filled in - set to the full amount of the invoice in question. The rest is relatively easy to fill out.
We use the awesome jquery.payment [2] and Stripe.js [3] on this form so you get formatted input - like on the credit card number and expiry date - and inline validation.
[1] https://www.waveapps.com/invoicing/
[2] https://github.com/stripe/jquery.payment
[3] https://stripe.com/docs/stripe.js
[+] [-] j-m-o|13 years ago|reply
By the way, getting everything up and running with Stripe was a dream, it's an amazing product. Great work.
[1] http://www.tryringo.com
[2] https://gist.github.com/boucher/1750368
[+] [-] nirvdrum|13 years ago|reply
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.
[+] [-] dave5104|13 years ago|reply
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.
[+] [-] birken|13 years ago|reply
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.
[+] [-] bradgessler|13 years ago|reply
No thief in their right mind would want to steel a Software as a Service product like ours since you can't really resell it. If they were reselling it we'd quickly find out about it and disable the account.
If we were selling hardware or an item that a thief could turn around and resell without any trace, we'd have to worry quite a bit more about fraud.
I'd hate for somebody who is running a SaaS company to read this and implement some insane IP/Tor/blah fraud detection scheme when the nature of their product/transactions doesn't necessitate it.
[+] [-] JoshTriplett|13 years ago|reply
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".
[+] [-] jackseviltwin|13 years ago|reply
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.
[+] [-] Osiris|13 years ago|reply
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).
[+] [-] raverbashing|13 years ago|reply
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
[+] [-] overshard|13 years ago|reply
I implemented a full form asking for all their information and toss out everything during processing. It's a very silly thing but it makes customers feel better about the checkout process for some unknown reason to me...
[+] [-] VengefulCynic|13 years ago|reply
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.
[+] [-] brandonb|13 years ago|reply
[+] [-] tobyjsullivan|13 years ago|reply
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.
[+] [-] sib|13 years ago|reply
[+] [-] EGreg|13 years ago|reply
If someone steals your social security number they can open accounts in your name. To stop it you have to call one of the credit bureaus and they will put an "alert" on your account together with a phone number. What most creditors do when they see this alert is call that phone number and make sure it's really you opening the account.
Really? Why isn't that just the default? Are you opening credit accounts so often you are majorly inconvenienced to make sure someone verifies it's you by calling the number you selected?
Similarly with credit cards. They could just text your phone to confirm that you really are about to purchase something. You could turn this off EXPLICITLY, and turn it back on when you lose your credit card.
If everyone used "Verified By Visa" or PayPal oauth-type portals for payment, this wouldn't happen. When your bank password is compromised, you can just change it. To do this, you simply ask them to send you an authentication code at a previously supplied email address -- two factor authentication. But now it's too late, because anyone who accepts your credit card can steal it, and use it a year later.
For that matter, why do we use Social Security Numbers and Credit Card Numbers for such important things? It's a relic of terrible one-factor authentication. That signature stripe was probably supposed to be used to match your signature that you sign the receipt with. Well, no one does that.
All you have to do is go on the site, purchase something using two lines, and they text you on your phone. You can turn it off explicitly. Then the law and the liabilities can change with such merchants. Of course, this will take years.
[+] [-] EGreg|13 years ago|reply
[+] [-] brandonb|13 years ago|reply
[+] [-] annon|13 years ago|reply
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.
[+] [-] mrb|13 years ago|reply
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.
[+] [-] haroldu|13 years ago|reply
Of course, ideally every citizen would be able to sign anything with a public-private key pair, counter-signed by the state.
[+] [-] jevinskie|13 years ago|reply
[+] [-] stopcyring|13 years ago|reply
[+] [-] smiler|13 years ago|reply
[+] [-] ceautery|13 years ago|reply
[+] [-] tobyjsullivan|13 years ago|reply
[+] [-] tzaman|13 years ago|reply
[+] [-] cynwoody|13 years ago|reply
[+] [-] shurcooL|13 years ago|reply
[1] https://dl.dropbox.com/u/8554242/dmitri/pay.html
[+] [-] npcomplete|13 years ago|reply
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.