[InclinedPlane]

I don't think this is a good argument against input validation, though it's a good argument against incorrect input validation, of course.

A few things that seem missing from this critique is the idea that shipping and payment aren't just human mediated processes.

With most ordering systems payments and shipping are directly integrated using external APIs, and if you pass garbage data out to those then you will fall into the trap that professionals call "really fucking everything up", which is undesirable. Processing payments typically requires a name and an address, as does shipping. That's not much of an excuse for not doing proper input validation or accepting non-ascii input but it does help to explain why the problem isn't a trivial one. If users are just sending you cash (or, say, some sort of gift-card code which might as well be digital cash) and you're just hand labeling packages and taking them to the local post office that's one thing, but that's not the way even very tiny businesses work today.

[jordangsu]

Agreed, especially when shipping, and invalid address can be expensive. We were charged $$ for each address which was "invalid"...even as simple as missing a "NE" on the street. An address lookup service was put in place, but it was done non-obtrusively. The user was prompted if the address was completely invalid, but they were allowed to ignore and continue anyway instead of stopping the order. Bad-validation certainly doesn't justify no-validation.

[thierryrietsch]

as long as one does not prevent the user from ordering, the process can be ok but still it is not working in so many cases.

[jordangsu]

Really, what cases are these? We found the address lookups to be very accurate, and saved money.