online payments and credit cards: I have questions

[cellio]

As I make the rounds doing year-end donations, I'm reminded of two things that have long puzzled me:

1. Some web sites auto-detect the type of credit card based on the number. Apparently all credit-card numbers that begin with "4" are Visa. (I don't know if the reverse is true: do all Visa numbers start with 4?) Being me, I've cycled through the other nine digits and nothing else produces a match based on a single digit. What are the patterns for other providers? And are all these sites using some standard library for this, or are programmers really coding that by hand?

2. Years ago, a three-digit code ("CCV") was added to cards to mitigate fraud. On a physical credit card, this number is stamped rather than embossed, so those old-style manual credit-card gadgets that took an imprint of your card (on actual paper, with a carbon!) couldn't record it. Um, that's fine I guess, but online, that number isn't any more secure than the card number itself. And someone who steals your physical card has the number; it's not a password. Does that number have another purpose?

Comments

[goljerp]

I think Discover numbers all start with 60 (or is it 6011)? Back in $OLD JOB, I had to deal with credit cards a bit, and I remember having fun coding the check digit. :-)

Here's my pet peeve: why doesn't everyone ask for the zip code before the city/state? Some forms now do that, and then auto-fill the city/state (although presumably you can still override that). Since zip code maps to state in the US always, and to a city usually, I don't see why everyone doesn't do this (other than the expense of programmers...)

[mdlbear]

Actually the only thing that's needed is the zipcode, and some forms only ask for that. It's possible that city/state are used to cross-check the zipcode.

[sine_nomine]

My zip code, on those lists, often codes to the wrong city. If I can override it that's one thing but, if not, it is a royal pain.

[goljerp]

Yeah, that's why I said "usually" maps to a city; I was aware of the "one zip code is in 2 different town/cities" problem but you have a good point about lists being wrong. That's why, IMHO, one should be able to override the auto-fill. That way, most people will save time, and the folks in your unortunate position at least won't be worse off than before. (Well, I guess you'd have to delete the wrong city/state, so it would be a bit more time...but hopefully not that bad.)

[sine_nomine]

Oh yeah I wasn't arguing your point. Just providing alternate viewpoint. And I left out the one where a person on the phone literally insisted my building (with something like 240 units) didn't exist because they couldn't find my address on the autofill. I am guessing user error on that one...

I totally agree that autofill can be helpful!

[goljerp]

It's good for programmers to remember that just because they have a list which claims to map X to Y, doesn't mean that it's always correct.

(Un)Fortunately for me, I bump against this fairly frequently at work: we deal with locations, and use the UN Location codes (UN/LOCODE). But the list isn't complete; it's possible to find towns which have a US zip code, but aren't in the UN/LOCODE list. So my company (since before I started) fakes up a UN/LOCODE for the place and uses it internally. But that means that there's duplication, inconsistancies, and when a place gets a real UN/LOCODE, there's no easy way to update our database...