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

71–80 of 129 posts

Re: The anatomy of a credit card form

#71

Post by grkvlt »

provemewrong wrote: post #69
ajanuary wrote: post #63

Earlier quoted context omitted.

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.

They do exactly that! However it depends on the type of card, so if you just start typing '1234567' it is not a valid card number and is unformtted. Try entering something that starts '42' (for a Visa debit card) and it will be formatted as such, in four groups of four digits. They also recognise AMEX cards and format appropriately, try '345612346712348' for example.

Re: The anatomy of a credit card form

#72

Post by insin »

provemewrong wrote: post #69
ajanuary wrote: post #63

Earlier quoted context omitted.

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.

They do, but only when the number you're entering is recognised as one of the expected formats. If you type 1234, you'll see the space being added, but it's then stripped again with the next digit you input. If you hold down 4 or type 3 then hold down 4, the spaces will be added.

Things get fun if you try to go back and edit the number, though. Forms are hell :)

Re: The anatomy of a credit card form

#73

Post by [deleted] »

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

[deleted]

Re: The anatomy of a credit card form

#74

Post by eli »

mrweasel wrote: post #57
eli wrote: post #52

Earlier quoted context omitted.

Yes. They are asking so that it can be sent to the credit card processing and used as part of a anti-fraud algorithm. Have you implemented credit card processing yourself or used something like Stripe? It's honestly a pretty common option. At least around me in the North Eastern US, pretty much every gas pump will refuse to sell you gas if you can't provide the billing zip for the credit card.

We use multiple companies, all of which are "something like Stripe", to avoid dealing with PCI requirements. I've never seen any of them check zip or name, if you want added security you ask for 3D Secure/Verified by VISA. That will either require the customer to login via their online banking solution of enter the code sent to them via SMS. On of our payment providers just told us today that by August 1st. 3D Secure…

Stripe actually has a checkbox in the settings to check the zip code and address: https://support.stripe.com/questions/what-is-avs

I don't know how many people actually use it, but it's definitely a common option. The idea is that it would be another layer in your anti-fraud protection, not that it would replace something else.

Re: The anatomy of a credit card form

#75

Post by joosters »

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…

Yes - and if you look at the source URL (mostly hidden if they use an iframe, or sometimes visible if they do a complete page redirect), then the hostname is often a completely unrelated, unintelligible name that no-one would associate with either the shop or the card company. These are exactly the websites that you should NOT trust!

Re: The anatomy of a credit card form

#76

Post by eli »

mseebach wrote: post #55
eli wrote: 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.

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.

Re: The anatomy of a credit card form

#77

Post by grkvlt »

amolgupta wrote: post #16

Use Luhn's algorithm to validate the card number on client side ranther than throwing an error from server. https://en.wikipedia.org/wiki/Luhn_algorithm

Which is exactly what it does. Try entering a random 16 digit numer - it will probably be invalid, but then edit the last digit until it is accepted.

But, once you have a valid number, that's all it is, a number. So you still have to round-trip to the payment processor, via the server, to check the number represents an actual payment card, and has money available.

Re: The anatomy of a credit card form

#78

Post by tbrake »

nothrabannosir wrote: post #8

> We realized that users may enter the ZIP code associated with their personal address, instead of the code associated with their cards. To add clarity, we added a note in a tooltip, which asks for the code from the credit’s card billing address. By the time some people start typing, they are looking at the keyboard and not at whatever is changing in the UI. The people who might need this tooltip won't be the ones to…

I noticed that too. I think a "Billing Zip/Postal Code" label would be clear enough.

Re: The anatomy of a credit card form

#79

Post by ColinDabritz »

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

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

The demo form does seem to handle backspacing and pasting correctly.

I do know a LOT of places where this gets missed, and a typo goes to the next field, but reflexive backspace correction also fails.

Re: The anatomy of a credit card form

#80

Post by dcminter »

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…

My UK bank (Lloyds) cannot handle non ASCII symbols in the address fields for IBANN payments. Drives me crazy every time as most places I make payments to have at least a few å or ë letters in them. How someone could create such a form without testing it on a bunch of international addresses is boggling.
Post reply on HN