
Stupid American Website Owners - johns
http://hicks-wright.net/blog/stupid-american-website-owners/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Hicks-Wright+%28Hicks-Wright.net%29
======
po
I understand the point of this article but...

> a credit card form is not a feature

It absolutely is. It's a feature that every paying customer will use at least
once. I would say if you can't properly support international CC
orders/addresses, then make that your policy and don't ask for the country.

There's nothing wrong with saying "Sorry, US addresses only" if you don't have
the resources to support international. But if you're asking your users what
country they live in, you should have all of the machinery in place to
properly process it.

~~~
fakelvis
Exactly. If a user is being led to believe that their location is supported,
support it. Otherwise make it explicit that it isn't.

You are supporting international orders? Spend a few hours making a
comprehensive address verification system and reuse it everywhere. Over time
the effort expended on this task will hopefully become negligible. Maybe
that'll happen after you get your first international order.

It's not as if the data aren't freely available. This is the internet, after
all
([http://en.wikipedia.org/wiki/Address_(geography)#Mailing_add...](http://en.wikipedia.org/wiki/Address_\(geography\)#Mailing_address_format_by_country)).

~~~
sern
"A comprehensive address verification system" does not take a few hours to
make. In another comment on this thread I posted a link to an amazingly
detailed address format database and I'm quite sure it took longer than that
to make.

I think this would be an awesome open source project!

~~~
fakelvis
To clarify: I'm not suggesting that this AVS be made from scratch. That
definitely would take, as you say, more than a few hours -- not to mention
that it's unnecessary.

Finding the rules and data is but a trivial, slightly time-consuming task. I
saw your link before posting my previous comment and took this into
consideration: someone reading this immediately has a comprehensive DB of
address formats.

"A few hours" may have been a bit ambitious, but over a weekend, and with the
required data already available, creating a back-end solution to this is
surely not out of the realms of possibility for a reasonably competent
programmer?

Have to agree with this being a great idea for an open source project. I had a
little look around and the Google Geocoding Web Service
(<http://code.google.com/apis/maps/documentation/geocoding/>) looks like a
nice place to start, although most likely outside their ToS. For everyone
else, it's determining what's good enough from what's perfect (a good starting
point: [http://www.endswithsaurus.com/2009/07/lesson-in-address-
stor...](http://www.endswithsaurus.com/2009/07/lesson-in-address-
storage.html)).

Edited: And the resources on a previous HN posting for this article are
helpful, too: <http://news.ycombinator.com/item?id=1232042>

------
henrikschroder
This whole post is a false dichotomy, there are more options than "US only"
and "Correct for the whole world + validation".

If I had mostly US customers, then I would make an address form that had the
forms and the validation for US addresses, add a country dropdown, pre-select
US in it, and _if the user changed it_ just disable all validation and pass
whatever the user enters on to the third parties. That way the international
users won't have to try to guess how I want the addresses to validate, but
they might run into errors from the third parties, and that validation might
be slower, but at least we're down to a bare minimum of requirements.

You know how those credit card processors are picky with US addresses? Here's
another hint: They can't do international validation either! Just pass in a
different country and whatever garble the user entered and you're usually good
to go, as long as the credit card number and cvc matches.

You know that CC billing address concept? That doesn't exist where I am. My
credit cards don't have that. So when I'm asked to provide it, I enter
complete garble, and it usually works every time. So don't worry about only
giving well-formed data to the CC processors.

~~~
tghw
That's actually kind of what I was trying to say. Having people put in fake
data to satisfy a validator isn't the worst problem in the world. There are
probably much better things to be spending your time on.

And, yeah, in general, CC validation is a complete farce. Depending on how a
vendor has set up their payment gateway, sometimes you don't even need a
correct CVV or expiration date, much less a correct address...

~~~
henrikschroder
_Having people put in fake data to satisfy a validator isn't the worst problem
in the world._

If you do have a country field, but still do validation according to US rules,
then very few of your international customers will ever get through it. Most
will just get frustrated after several tries and then leave. By not having a
country field in the first place, you're telling these people that they
needn't bother, you won't be wasting their time, and then everyone is happy
and won't be writing angry blog posts about it.

------
jwr
I'm the poster of the original article that this responds to.

First, please note that I never called anyone stupid or moronic. You did, and
I do not know why. I said "stupid forms" and I stand by my opinion.

I see why you'd want to validate US addresses properly now, thanks for the
explanation. However, I still don't quite understand why you'd want to use the
same rules for the rest of the world.

Your credit card company cannot possibly validate my address (with zip code)
and telephone in a rigid US-based form, because I won't be able to enter my
zip code or my telephone into that form. They simply won't fit and validators
won't let them through. Also, many systems won't process non-ASCII characters
in my street name.

Of course, I have been entering crap data into those forms for the last few
years when buying online and have yet to see a credit card transaction
rejected. Which means you don't have to worry about rejected transactions on
out-of-country purchases, which means you might as well give us a reasonable
form and not expect us to fight our way through your validators.

So why not make two forms -- one for US customers, and one for everyone who
chooses a different country? Given your estimates I expect you might even get
that done in 2010 :-)

~~~
joshd
"So why not make two forms".

Exactly. Have a US form. If the customer selects a non-US country then switch
out the state for a freeform "state/territory" field and skip the US-centric
validation. All up you might need 10 lines of HTML and server side code.

This applies to US-only services too. When trying to book accomodation and
flights for a US trip I have heaps of websites refuse my money because I
couldn't provide a US billing address. For example it didn't occur to the
brain-dead developers of the Disneyland website that tourists be from outsite
the US.

The problem is developers who seem to think they know what the customer wants.
I know because I've done the same thing. If you're relying on your intuition
then you are almost certainly wrong.

------
David
The distinction is the expected ratio of US customers to international ones. A
significant inconvenience for a select few customers is nowhere near as bad as
a small inconvenience for every customer.

Also, shipping is _important_. Definitely agree with that point - if you spend
all your time making the checkout form internationally friendly, you've
already run out of time for your product. You're either irrelevant, hopelessly
behind the competition, or completely out of money.

Might be viable at a large company, though, where you've got people who are
already doing nothing useful.

~~~
joshd
But he doesn't know even what conversion rates he could achieve because he
chose to totally ignore non-US billing addresses. He's just assumed that it's
not worth his effort.

He's talking about a web-based product. There is no reason to require a
properly formatted address. When people are trying to give you money you
should make things as simple as you can.

~~~
tghw
Not to be rude, but I think you're having a bit of a reading comprehension
problem. Nowhere did I say to block non-US users, as you've repeatedly
asserted I did.

What I am saying is don't worry too much about getting it right, especially if
you plan on targeting US-based users first. If people have to pick a random
state because the validation library you used always validates states, but
only 5% of your users hit that problem, big deal. You should have a decent
analytics package installed, and if you do you'll know what the bounce rates
are for your international users, so you can decide if and when there is a
business case for doing full i18n and l10n.

------
tjmc
Hmm what takes more time? An 800 word blog post or adding an "Outside US"
option to the select control for "State"?

~~~
wooster
There are countries outside the US where the province may be required for
proper routing of mail.

I'm still working on my address support. It's hard, considering there are more
de facto countries than are legally recognized by any international body, and
most of them are one-offs in terms of address formatting.

~~~
tjmc
I live in one of those countries and I think people are over-analysing the
problem. I think you're perfectly safe with:

Addr 1 (req) Addr 2 (optional) State (req but including "Outside US") Country
(req) Post/Zip Code (optional outside US)

When I order stuff from the US I just put my city and state in the Addr 2
line.

In the end this is a classic example of the "perfect being the enemy of the
good". Look at where your sales are going and allocate validation efforts
accordingly. A lot of sites include Canadian provinces in the "state" field
for example.

~~~
smikhanov
This piece of advice is so obvious that it makes me wonder why we need to have
this discussion in the first place.

------
sern
Was looking through my history and found this:
<http://i18napis.appspot.com/address>

It's not clear who owns it, though, so don't just go and use it. My point is
that it's worth spending the time (and maybe money) to find one of these
databases to make your international customers happy.

------
nosse
"Contrary to popular belief credit card companies will handle all sorts of
not-quite-right data :)"

Actually I thought they would not handle any data if it's not exactly right. I
think of myself more web savvy than most dudes out there, running linux and
surfing with opera. Still I thought that if I put wrong zip code to the form,
I would lose money. Stupid me. I'm from Finland, guess how much I have bought
stuff from websites that require me to put zipcode in the billing form.

"probably have bigger problems to solve than a Polish guy having to pick a
state at random"

That polish guy might be the polish guy that markets your product to ten
french, one british and two australian guys, and then chain reaction! And the
one thing keeping him from doing this is the billing form of your otherwise
brilliant product.

What I'm telling you is that if you want money, at-least tell people: "pretend
you're from Virginia if you're not from U.S." in the billing form. Writing
that takes considerably less time than two hours.

------
ErrantX
Yeh this is.... something of a foolish rant (it sounds like he's taken
personal affront to the original post).

He's getting hung up on validating everything when, really, the _sensible_
thing to do is minimum viable validation and leave it at that.

Contrary to popular belief credit card companies will handle all sorts of not-
quite-right data :)

------
joshd
So lets weigh up the options:

A) Let non-US customers enter whatever billing information they want. Accept
that a small percentage will fail when we try and charge the credit card.
Everyone else is happy and we make more money.

B) Explicitly block non-US citzens who are trying to give us money.

Oh! Let's choose B.

~~~
tghw
Where exactly in the article did I mention blocking non-US "citizens"? (I
think you mean users; most websites don't require citizenship verification.)

------
mynameishere
Very hard to read that website.

~~~
micaelwidell
Yeah, you know, readability is not a feature. Gotta focus on features ;)

------
_ivan
bla bla

------
kristiandupont
I don't understand why you are offended by the original article. It didn't
seem offensive to me - he was describing a general frustration which may or
may not be valuable feedback to you.

~~~
tghw
No offense was taken in the reading and writing of these two articles. Just
trying (and apparently failing) to humorously point out that if most of my
users are based in the US, then I probably have bigger problems to solve than
a Polish guy having to pick a state at random.

~~~
jasonlotito
The way to think of it is like so:

Most of your users are based in the US because those not in the US can't get
in to use your service. =)

~~~
tghw
It's not that they _can't_ , it's that there's a little more friction for them
to.

(Speaking of _my_ websites, we've actually done the i18n necessary to make it
usable from anywhere, but only after we knew we had that international
demand.)

~~~
jasonlotito
Oh, I'm not talking about your websites. =) I'm just referring to the problem
in general.

The first moment the craziness of i18n that I experienced was almost 10 years
ago, building software for Koreans (I think, not sure, was a long time ago)
and after the UI team demoed the product, one of the partners who was pushing
this for the Asian market remarked they had to remove the red. Apparently, red
is a taboo color or something over in that region.

