Live data from Hacker News

The anatomy of a credit card form

medium.com

91–100 of 129 posts

Re: The anatomy of a credit card form

#91
When I look at the logos on the top of the form, I feel like I should click on the one (Visa/Mastercard/Amex/Discover) I'm going to use to tell the form which one I'm entering the details for. Although this can be deduced from the number, most online forms require the user to select it explicitly (although most commonly with radio buttons or drop downs). This minor friction and confusion could be avoided by just saying "We accept " followed by the logos.

Re: The anatomy of a credit card form

#92

Earlier quoted context omitted.

Paywave / Paypass / Tap & pay / whatever your country or bank calls it. With NFC payments you don't have to type a PIN when using a card. Although you can use extra PIN when paying using your phone.

In Austria you do need a PIN for contactless payments over 25€ (might depend on your bank).

It depends on your account (you can set it higher if you sign a form).

Re: The anatomy of a credit card form

#93
post #26
post #12

Has anyone actually stepped back and looked at the larger picture, what a buyer wants to do is pay X (credit card is only one of them payment methods available and not really popular in some countries) they do not want to be entering long strings of numbers (whether its a credit card number, bank IBAN number, prepaid card #, or a bitcoin address) into forms they just want to pay

With bitcoins, I click on a bitcoin address in my web browser. That opens up a bitcoin client with the information already filled in (amount and receiving address). I then have to type my bitcoin password for the transaction to complete. Except for the authorisation step, which could be done in other ways, most of the convenience is already in bitcoins. Any other payment URI scheme could do the same thing.

Bitcoin is the most convenient way of payment, bar none. I point my phone at the QR code, keep my fingerprint on the sensor, the page refreshes, done. None of the CC crap.

Re: The anatomy of a credit card form

#94
post #76

Earlier quoted context omitted.

Most fields don't reformat and add characters like spaces as I type. I personally find it a bit jarring. I suppose reformatting it one the box loses focus isn't as bad, but I'd still prefer you just keep what I type.

The iPhone reformats phone numbers as you type them, and I personally don't find it jarring at all.

Try moving to a country that splits phone numbers different that what you are used to. I grew up with 3-3-4 but live in a country that splits 2-4-4. Subtly annoying.

Re: The anatomy of a credit card form

#95
post #50

Earlier quoted context omitted.

The automatic formatting seems more "cool" then actually useful. I'd much prefer that it show characters as I type them, like pretty much every other text input field.

As opposed to most other text input fields you encounter in the wild, credit cards (and phone numbers) have a singular canonical format. As long as you don't limit HOW it's entered (or pasted), it makes a lot of sense to coerce the input into the canonical format.

They most certainly do not have a singular canonical format. American Express cards use different groupings and a four-digit card security code.

Re: The anatomy of a credit card form

#96
post #86

Interesting post, and I'm not surprised to see a diversity of opinion on the design. Question: does anyone still use the CRC validity check for client- or server-side validation of payment card numbers?

You're talking about a Luhn check? I still see it as common practise, particularly on the client side. Interesting that the article didn't mention it as a validation point (only card number length), but testing their demo it does do the check.

Yes, exactly. I had forgotten the name, and I also found it interesting that it wasn't mentioned.

Re: The anatomy of a credit card form

#97
post #68

Earlier quoted context omitted.

> 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 de…

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.

Re: The anatomy of a credit card form

#99
post #86

Interesting post, and I'm not surprised to see a diversity of opinion on the design. Question: does anyone still use the CRC validity check for client- or server-side validation of payment card numbers?

Does anyone not? It's a dead stupid simple way to check that the card number entered could possibly be valid, so you can let your users know earlier in the process (during client side validation) that there may be an issue.

Yes. Luhn checksum detects adjacent digit transposition errors, which I'd tend to believe are the most common, and it will detect a single wrong digit, which might be most or second most common. It's a simple check, although all the example code I've seen is grotesque.

The lesson here is that when you're dealing with those pirates that do the "Rachel from Account Services" scam cold calling, transpose two digits seperated by another digit. Don't monkey with the first 7 digits or the final digit. You can get those idiots to go all the way through verifying your (incorrect) card number, as the BIN/IIN is correct and Luhn check passes. Waste some time on double checking your card number before spewing vitriol and profanity on them.

Re: The anatomy of a credit card form

#100
post #68

Earlier quoted context omitted.

> 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 de…

The implementation is up to the bank. My banks use 2-factor authentication solutions for 3DSecure (one has you put the chip in a special reader, the other uses a mobile app)

https://www.flickr.com/photos/kalleboo/2486214902

Post reply on HN