
Why are payment forms so complicated? - brandonb
http://blog.siftscience.com/why-are-payment-forms-so-complicated-2/
======
jules
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.

Or bitcoin of course.

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

------
UnoriginalGuy
IP based "fraud" detection is fucking annoying.

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

~~~
brandonb
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?

We have more information with some examples of signals our system uses here:
<https://siftscience.com/large-scale-machine-learning>

~~~
paulsutter
Isn't the first rule of fraud detection not to talk about rules you use to
detect fraud? ;)

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

~~~
segmondy
There is no security through obscurity only illusions of it.

~~~
dalore
It's analysing behaviour for patterns. If you let out what patterns you're
looking for then those patterns change.

~~~
sheri
Wouldn't the patterns change after the fraudsters realize they are not
working?

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

[1] <https://motorcycle.ctec.ca/gifts.html>

~~~
jiggy2011
How are you billing on that? Every payment gateway I have used requires at
least postcode etc.

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

~~~
j-m-o
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.

[1] <http://www.tryringo.com>

[2] <https://gist.github.com/boucher/1750368>

~~~
maccman
For validations there's not much point in using jQuery.payment over Stripe.js
- they're practically the same. However, where the jQuery plugin really shines
is with formatting the expiry and card inputs. Inputting a cc number in groups
of 4 digits is much easier than a whole number munged together.

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

~~~
dave5104
> I suspect abandonment rate is rather low.

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

~~~
ComputerGuru
Look at our checkout form on <http://systemdiscs.com/>

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.

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

~~~
damncabbage
Doesn't work with iOS; hitting Next on the popup keyboard immediately jumps
without giving the chance for the select's change event to fire.

(Bad first-hand experience looking for work-arounds.)

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

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

~~~
jackseviltwin
That's funny, we came to the same conclusions and implemented them for our
checkout flow. Here's an example:

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

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

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

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

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

------
raverbashing
Here's a tip if you care at all for International payment:

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

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

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

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

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

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

~~~
EGreg
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?

------
brandonb
I'm the OP. Let me know if any of you out there have questions! Or, better
yet, experiences with simplifying payments on your site good or bad.

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

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

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

~~~
khuey
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).

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

~~~
smiler
Yes you're right - this post has no discussion of what governments might
require of a business from a legal standpoint

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

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

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

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

------
shurcooL
My payment form[1] is relatively simple.

[1] <https://dl.dropbox.com/u/8554242/dmitri/pay.html>

------
npcomplete
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/>

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...](http://stackoverflow.com/questions/72768/how-do-you-detect-
credit-card-type-based-on-number)

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.

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

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

------
mduvall
I'm not sure '40% higher conversion rates' means anything pertinent. If it
directly correlates to a company's revenue, this is fantastic. However, if it
also contributes to a higher fraudulent payment rate (say we are funding
loans, or performing a transaction where payment fraud tends to be higher), it
must be taken into consideration and weigh how much the company will pay for
each individual customer support case versus revenue accrued from each
conversion.

That aside, customer data here is not only used for simply 'making the
payment' as the writer says. This is a huge over-simplification of the
problem, the payment gateway for the transaction to detect AVS and CVV is a
/last ditch effort/ to catch fraud. The other fields could be used for other
services that detect fraud such as ID Analytics, Experian, etc. and ultimately
help mitigate credit and fraud risk for the company.

------
nawitus
I don't understand why the merchant should pay the chargeback on fraud. Online
payment works best by making electronic wire transfers. This is how payment
normally works in Finland: you buy something, and at checkout click the logo
of your bank. You're redirected to the bank's website where you login and
accept the payment. Then you're redirected back to the website.

That's quite similar to 'Verified by Visa' model, where the client has to
accept the payment on Visa's website.

Recurring billing (e.g. monthly payments) could be authorized once.

If a customer's computer gets hacked and the access to the online bank gets
compromised, then that situation should be dealth completely by the bank (in
the same way it's being dealth even now).

Merchants and online stores shouldn't have to worry about preventing fraud,
that should be centralized and dealt by banks

~~~
PeterisP
The answer to "I don't understand why the merchant should pay the chargeback
on fraud." is very simple - [non-huge] merchants are presented with an offer
they can't refuse: accept the rules as-is, or don't accept credit cards.

For most global businesses accepting credit cards is better, since a
significant portion of customers prefer cards for various reasons, including
the ability to chargeback if they have a disagreement with the merchant.

And wire transfers aren't a good option in many countries due to their cost -
while they should cost a few cents or less (an order of magnitude less than CC
processors charge), in many countries, including USA, wire transfers are
rather expensive.

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

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

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

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

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

------
lucb1e
Bitcoin's forms are easier :)

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

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

------
pfredrich
CSC is only one of many options to improve checkout conversion. There are many
other ones that don't result in increased fraud exposure like:

\- Eliminate the concept of a shopping cart if you just sell one product

\- Don't force buyers to create an account

\- Don't ask for the same information twice like shipping and billing address
(if you collect billing address, you shouldn't)

\- Combine first and last name into one field: name

\- Auto-complete address based on ZIP

\- Trust messaging

Baymard has great recommendations based on their extensive studies:
<http://baymard.com/checkout-usability>

------
ezioamf
Credit card numbers are not something that you keep secret (you give it every
time you use it). This is why you need that much "fraud" detection. So we need
a better alternative to pay like PayWithMyBank
(<http://www.paywithmybank.com>). You can try how it works at
<http://try.paywithmybank.com>

------
knowaveragejoe
While I largely agree with what is said here, the author highlights _131
characters_ like it's an absurd amount. That's not even a tweet.

~~~
hcarvalhoalves
The problem is the number of fields. Usability shows the relation between
number of fields x conversions follows a power law [1]. Aiming at 80%
conversion, the threshold is between 3-7 fields.

[1] <http://en.wikipedia.org/wiki/Power_law>

------
nym
A: Chargebacks

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.

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

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

------
smackfu
This is why I will usually hit the Paypal link if available, because I don't
have to enter anything.

------
readme
Um, the billing address you enter is often used to compare against the billing
address on file with the CC company for security purposes. So you need the
billing address, too. The security code wouldn't hurt, either.

~~~
pfredrich
You don't need it. AVS checks numerical part only anyhow. Billing ZIP is more
than enough.

~~~
robryan
Don't think that is true. Our gateway will report zip match or full address
match.

~~~
pfredrich
<http://en.wikipedia.org/wiki/Address_Verification_System>

"AVS verifies the numeric portions of a cardholder's billing address. For
example, if the address is 101 Main Street, Highland, CA 92346, in the United
States, AVS will check 101 and 92346. Sometimes AVS checks additional digits
such as an apartment number, other times it does not..."

They might call it 'full address', still it's just the numeric part.

~~~
robryan
Ah thanks. Thought it was doing more but for most cases that would be enough.
Most fraud isn't very sophisticated so just the number and zip would be
enough.

------
Xymak1y
I've never had to fill out 14 fields for payment. Ever. While I agree this
might be too many fields, I very much doubt it's the standard practice.

------
toomim
Bitcoin.

------
knodi
They're not complicated if done with little bit of common sense.

