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

81–90 of 129 posts

Re: The anatomy of a credit card form

#81

Post by gingerlime »

eli wrote: post #50
gingerlime wrote: post #21

Earlier quoted context omitted.

jquery.payment from stripe[0] helps with formatting and automatically adjusts it to the card type as you type in the numbers. It does seem to ignore spaces though, but it adds them for you as you type. If you type in a VISA number it will format it as XXXX XXXX XXXX XXXX, but if you type in AMEX, it will format it as XXXX XXXXXX XXXXX. Pretty neat if you ask me. You can try it here http://codepen.io/anon/pen/WvygyO V…

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.

I find it both cool and useful. The digits on my credit card are already separated into 4 segments, so it's natural for me to both read and type them in 'chunks' of 4. If I need to compare it to what's on screen, it's much easier to see. And it's harder to lose track of which digit you're at and what's next. Or if you mistyped anything - it's visually clear as well because you're likely to change the "balance" between the individual segments (e.g. push one digit to the next segment).

Re: The anatomy of a credit card form

#82

Post by gregschlom »

I use Dashlane and stopped entering credit card and billing info manually 2 years ago :-)

Their tech is amazing. They autodetect credit card fields when you focus on them and show a little popover where you can choose the card that you want to use. Just click on the card and everything fills up.

http://dashlane.com - email me if you'd like a referral link to get 6 months of premium service for free, btw.

Re: The anatomy of a credit card form

#83

Post by jimbobimbo »

Nice write up.

Suggestion: instead of generating garbage-looking "verification code" I as a user would prefer to have a string of digits separated in groups. Imagine the experience of spelling the code in its current incarnation over the phone...

Nit: the passage about "getting rid of physical cards" by replacing them with Apple Pay. If you use your phone to pay, it's still a "physical card", albeit more hi-tech.

Re: The anatomy of a credit card form

#84

Post by [deleted] »

DiabloD3 wrote: post #9
nicboobees wrote: post #3

Earlier quoted context omitted.

Another example of doing it wrong is when the form splits the cc number into 4 separate boxes, and automatically skips along merrily to the next box as you type it in. This might look nice and everything, but usually breaks if you try to backspace your entry, or paste etc

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.

[deleted]

Re: The anatomy of a credit card form

#85

Post by logfromblammo »

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

I have worked on an actual product where the user input is validated prior to losing focus, and if the input is invalid, the user cannot move focus from that control until it is corrected.

Several developers on the team opined that it must be the worst idea in the history of input validation, yet the customer still wanted it that way.

Re: The anatomy of a credit card form

#87

Post by mynameisvlad »

markbnj wrote: 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.

Re: The anatomy of a credit card form

#88

Post by cdcarter »

eli wrote: post #76
mseebach wrote: post #55

Earlier quoted context omitted.

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.

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.

Re: The anatomy of a credit card form

#90

Post by incarnate »

markbnj wrote: 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.

Post reply on HN