Stupid American Website Owners
hicks-wright.net
hicks-wright.net
> 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.
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...).
I think this would be an awesome open source project!
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...).
Edited: And the resources on a previous HN posting for this article are helpful, too: http://news.ycombinator.com/item?id=1232042
If 5% of users have to lie and put California in as their state and 90210 as their zip...well, it's not the worst compromise in the world.
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.
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...
One time had a customer on the line with us asking why he no longer had access. We explained because he had chargedback the transaction. No, no he did not, he assured us.
We called the bank, and found out that he had asked for a chargeback, but it was for another transaction he had problems with, and wanted it corrected. So here we are, my customer service rep, the customer, and the bank on a 3-way call, and the customer is telling the bank to undo the chargeback and give us the money back, and to chargeback the other transaction. And they wouldn't do it. Oh, they applied the chargeback to the other transaction, but the penalty was still applied to us.
The customer apologized to us later, and wanted to pay again, and was even willing to pay the chargeback fee. He simply paid again the normal price, and we swallowed the cost.
I hate banks.
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.
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 :-)
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.
My main point is that it depends on your audience. For most things I would develop, my primary audience is probably going to be from the US, so I should take that into consideration. If my analytics show a higher percentage of international users than I'd expected, then I can go back and spend more time developing another form for outside the US. It's all a matter of priorities.
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
Most of your users are based in the US because those not in the US can't get in to use your service. =)
(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.)
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.