Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The anatomy of a credit card form

medium.com

Post reply on HN
Print view View original

121–129 of 129 posts

Re: The anatomy of a credit card form

#121

Post by whoopdedo »

mrweasel wrote: post #49
dchest wrote: post #27

Earlier quoted context omitted.

From the article: "As an extra security measure, we have to ask customers for the ZIP code associated with their card. There is a trade-off here: adding extra inputs to the form can increase bounce rates, but by adding it, our business is more secure and less prone to fraud."

Is the zip sent to the card processing company? Do they check that the zip matches your address? What if the customer just moved? I've implemented card payments on multiple occasions, but not once have I seen a credit card processor that offered to validate the zip code. Unless the name and zip can actually be sent to the credit card processor, and they have access to that information based on the credit card number…

> I know plenty of people who wouldn't think twice about leaving out a middle name that they hate.

And I haven't met a bank that didn't ignore the middle initial when validating a credit card. Even though they all say "enter your name as it appears on the card".

Which just makes it easier for them to be stolen. If someone gets a hold of your card number they probably also have the record of what you bought. If you had it delivered to your house they have your first and last names and zip code. All they need is the CVV2 (pick a random number from one to one-thousand) and they're in the clear.

I really don't get credit card security at all. Seems to me to be a lot of smoke and mirrors that the banks just plaster over with insurance for when they have to give back stolen money. It doesn't actually prevent or deter theft, just sweeps it under the rug.

Re: The anatomy of a credit card form

#123

Post by jerfelix »

kijin wrote: post #28
tomp wrote: post #2

> “My card number has spaces. Do I enter my card number with spaces, or without?” To solve for this, we limit the input values to numbers only, so 0–9. So if a user types a space, it does not register and it does not affect the number format. They failed, at the most important part of the form. The correct, i.e. the most user friendly solution is, obviously, to allow spaces (and optionally other characters, like "-,.…

Ditto for the expiry date. Showing a slash in the placeholder text but silently eating it if the customer actually tries to enter one is a recipe for confusion. As a matter of fact, you won't even have to worry about the expiry date format for the rest of your life. None of the valid YY or YYYY codes for the next 84 years (15-99, 2015-2099) collide with a valid MM code (01-12). There's no ambiguity. So just let the c…

I'm curious about their statement that they automatically append a slash as soon as you type the month.

The instructions say "MM/YY", but do not indicate whether the month is required to have two digits, or just permitted to have two digits. My card says it expires 1/16 So when I key in 1, does a slash get appended? Probably not. Instead, it gets appended after 11. 11/6. now what?

Re: The anatomy of a credit card form

#124

Post by adnrw »

billyhoffman wrote: post #119
tomp wrote: post #2

> “My card number has spaces. Do I enter my card number with spaces, or without?” To solve for this, we limit the input values to numbers only, so 0–9. So if a user types a space, it does not register and it does not affect the number format. They failed, at the most important part of the form. The correct, i.e. the most user friendly solution is, obviously, to allow spaces (and optionally other characters, like "-,.…

Testing whether a account number is valid before transmitting to the server is a problem that was identified and solved over 60 years ago with the Mod10 algorithm. Why aren't they using it? Right now, the only "does this credit card number look right" validation they do in JS is to look for a known prefix digit, and the length of the number. Otherwise the send it to the server for processing. This is silly. In 1954,…

They are using it, they just don't reference it specifically in the article.

You can try the demo: https://s3.amazonaws.com/gabe-cc-form/index.html

Re: The anatomy of a credit card form

#125

Post by tommorris »

david-given wrote: post #109
tommorris wrote: post #97

Earlier quoted context omitted.

Thing is it is very difficult to not be signed up for 3D Secure/VbV/SecureCode. I've had friends who have gone through ludicrous arguments with banks to get them opted out from 3D Secure.

I have been unable to be opted out from 3D Secure. It just doesn't seem to be possible. The argument the credit card companies usually use is that they aren't forcing it on us; it's the merchants, who set a flag in the transaction saying they require it. If you know how to opt out of it, I'd love to know.

A friend of mine told me his bank let him opt out. He just pestered them a lot.

Re: The anatomy of a credit card form

#126

Post by kijin »

jerfelix wrote: post #123
kijin wrote: post #28

Earlier quoted context omitted.

Ditto for the expiry date. Showing a slash in the placeholder text but silently eating it if the customer actually tries to enter one is a recipe for confusion. As a matter of fact, you won't even have to worry about the expiry date format for the rest of your life. None of the valid YY or YYYY codes for the next 84 years (15-99, 2015-2099) collide with a valid MM code (01-12). There's no ambiguity. So just let the c…

I'm curious about their statement that they automatically append a slash as soon as you type the month. The instructions say "MM/YY", but do not indicate whether the month is required to have two digits, or just permitted to have two digits. My card says it expires 1/16 So when I key in 1, does a slash get appended? Probably not. Instead, it gets appended after 11. 11/6. now what?

11/6 may have been a valid expiration date before November 2006, but not anymore. So a smart algorithm could tell that you meant 1/16 rather than 11/6.

It even works if you put the year first. 16/1 is valid, and it's clear that 16 is the year. Meanwhile, 1/61 either contains an invalid month or is too far in the future to be a valid expiration date.

NearlyFreeSpeech.net [1] does it right. It accepts anything between 3 and 6 digits (MYY, MMYY, MYYYY, MM YYYY, YYYY/MM, etc) and only throws an error if parsing it results in an impossible date.

[1] https://blog.nearlyfreespeech.net/2015/05/13/new-payment-fea...

Re: The anatomy of a credit card form

#127

Post by xtreme »

samstave wrote: post #120
DiabloD3 wrote: post #9

Earlier quoted context omitted.

Also, dealing with AMEX screws up a lot of forms. 15 numbers, 4 then 6 then 5. Yes, only 3 groups. And the CVV2/CVC2/CID is on the front and four digits, not three.

I wonder if this has any thing to do with why amex was so infrequently an available payment option online for so long...

I doubt it. A more probable reason is the higher transaction fee charged by Amex (3.5% compared to 2%).

Re: The anatomy of a credit card form

#128

Post by fidz »

tommorris wrote: post #46
TheOtherHobbes wrote: post #20

UK banks sometime sends payments to a separate verification page which either returns automatically or asks further security questions. I don't think this form is going to work with those banks. A couple of takeaways: 1. This has been a standard problem for twenty years now. Why are designers and developers still having to reinvent the wheel? 2. Reinventing the wheel is really hard. If you want to support internation…

> UK banks sometime sends payments to a separate verification page which either returns automatically or asks further security questions. Ahh, 3D Secure/Verified By Visa/MasterCard SecureCode. It really needs to die right now. Basically it teachers consumers to fill in random iframes on merchant sites. And the fact that the card industry thinks 3D Secure is secure or in any way a good idea is why they'll never make s…

It is basically up to merchant what to implement. I ever developed a site (in team) for South East Asia customer. Singapore law and Indonesia law are pretty much have freedom in it. You can choose 2D / 3DS. Yes, the different is pretty clear: who will responsible for the fraud. For 2D, merchant is responsible for fraudulent transaction -- and merchant can be charged back; while in 3DS the merchant will free from chargeback (hey you have been notified via two-factor authentication, so it is your fault, customer!)

Meanwhile, in Malaysia, all credit card transaction must be in 3DS.

Re: The anatomy of a credit card form

#129

Post by foldr »

nucleardog wrote: post #118
jameshart wrote: post #58

Earlier quoted context omitted.

For postal codes, they're even doing the right thing for the wrong reason. They believe they're only going to encounter US or Canadian postal codes. Billing addresses can be anywhere, of course.

This comes up all the time. Moderately annoying situation if you ever drive in the US with a foreign payment card. The gas pumps use some "ZipSecure" thing that requires you to enter your zip code to authorize a credit card payment at the pump. ... Except I don't have a zip code. Which usually meant I either had to prepay inside (and then go back inside to receive the remaining balance as cash) or leave my credit car…

This is indeed annoying. I've found that entering 00000 as the zip for a foreign card quite often works (though not 100% of the time).
Post reply on HN