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

61–70 of 129 posts

Re: The anatomy of a credit card form

#61

Post by pjc50 »

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…

"Please type in a whole load of other personal information" Nope! I get a good feeling of petty bureaucratic victory every time I see a site bounce in and out of Verified by Visa since I persuaded my bank to opt me out.

Re: The anatomy of a credit card form

#62

Post by pjc50 »

yc1010 wrote: post #53
warbastard wrote: post #17

Earlier quoted context omitted.

Yes, PayPal and other similar services were invented.

Problem with PayPal is that they ban people (I lost my account years back, still do not know why) and also of course not available in all countries. I was thinking something along the lines of some sort of new HTML "payment" tag so it could signal to the browser things such as "product details, price, available/preferred merchant payment method" and then the browser would pay from an in browser wallet containing stor…

Pre-filled credit card information would be great - if it could be stored securely. PCs are basically far too insecure for this to be accepted by the payment processors, it would just be phished to death.

Apple Pay would be the right solution if it weren't so proprietary.

Re: The anatomy of a credit card form

#63

Post by ajanuary »

provemewrong wrote: post #31
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 "-,.…

Yeah, seriously. The expiry date field fails as well. >Note that the placeholder text includes a “/”, but this is not required to be typed by the user. We limit the input value to numbers only, so if a user does type a forward slash, it is not registered. Frankly, I'd prefer that field to be split into two, but I'd be fine with a single field, if they didn't ignore slash. It's pretty annoying to see a form silently f…

The "/" is automatically added after you type the month, so you're never left with "0515". Try out the demo [1] and it should be a bit clearer.

[1] https://s3.amazonaws.com/gabe-cc-form/index.html

Re: The anatomy of a credit card form

#64

Post by teh_klev »

pjc50 wrote: post #37
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…

This is why people use payment gateways.

Even in the UK when using payment gateways (by which I presume you mean PayPoint/Protex/WorldPay etc and you're a "merchant") you still, in many cases, need to use 3D Secure/VbV/SecureCode if you wish to remove being the liable party for fraudulent card use.

Re: The anatomy of a credit card form

#65

Post by adamsch »

Apple should integrate Touch ID into their Macbooks and turn Apple Pay into a service for ecommerce. Payment would be one tap, similarly to Apple Pay IRL.

They could place the capacitive fingerprint sensor where the ON/OFF button used to be, it would actually be a neat way to wake up the machine without typing a password too.

For now, I just have my credit card number memorized so I can checkout fairly quickly without having to fiddle with physical objects in my pocket.

Re: The anatomy of a credit card form

#66

Post by pjc50 »

jordigh wrote: post #56
pjc50 wrote: post #39

Earlier quoted context omitted.

Bitcoin has shown how critical the fraud problem is. Between wallet loss and exit fraud by bitcoin companies, bitcoin users have lost vast amounts.

Do we have a comparison of how much is lost to fraud otherwise, without bitcoins? Anecdotally, the only time I have ever been defrauded of money was when my debit card was skimmed. The fraudsters kept trying to withdraw money, which I didn't keep in that account as I immediately took it elsewhere. It was the account in which I received my paycheque. The fraudsters were able to steal one of my paycheques, and the bank…

A few seconds of googling gives me UK figures of £479m fraud on a volume of £573bn, which is under 0.1%, and much of that falls on merchants.

http://www.theukcardsassociation.org.uk/plastic_fraud_figure...

http://www.theukcardsassociation.org.uk/plastic_fraud_figure...

Re: The anatomy of a credit card form

#68

Post by junto »

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…

The worst thing about these programs is the liability shift. Normally the merchant is left on the hook for fraudulent transactions.

With VbV and 3DS that liability passes back to the credit card company. Since the credit card company doesn't want that liability, and obviously there are no security holes in their system, then only one person can be responsible for not taking adequate care of their card and security details. Yep, you the consumer (read your small print).

Hence, by signing up for any of these programs as a consumer, you are shooting yourself in the foot.

Added to which, the program has been shown to be insecure, since if you hold the card in your hand (i.e. you skimmed the card), you can/could simply choose to reset your password: http://www.alphr.com/realworld/373768/the-security-hole-in-v...

Re: The anatomy of a credit card form

#69

Post by provemewrong »

ajanuary wrote: post #63
provemewrong wrote: post #31

Earlier quoted context omitted.

Yeah, seriously. The expiry date field fails as well. >Note that the placeholder text includes a “/”, but this is not required to be typed by the user. We limit the input value to numbers only, so if a user does type a forward slash, it is not registered. Frankly, I'd prefer that field to be split into two, but I'd be fine with a single field, if they didn't ignore slash. It's pretty annoying to see a form silently f…

The "/" is automatically added after you type the month, so you're never left with "0515". Try out the demo [1] and it should be a bit clearer. [1] https://s3.amazonaws.com/gabe-cc-form/index.html

Ah, I didn't notice the demo. That is actually pretty nice. If only they would do the same with the credit card number field and spaces.

Edit: okay seems like it is more thought out than I assumed.

Re: The anatomy of a credit card form

#70

Post by grkvlt »

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 "-,.…

Checking the demo, they sort of do what you suggest, and allow spaces, but in fact they are adding them in automatically. So the number is split into groups of four digits, visually.
Post reply on HN