This is about a design for a credit card entry flow on a website. Target: desktop users, who might need accessibility help. See it here.
I’ve been thinking about credit card forms because I’ve come across a few that were striking in their aggression regarding validation. I understand that validation (including calls to the server) can be done at each keystroke, but I expect the machine to wait until I’ve entered sufficient amount of numbers. Instead, these new forms are continuously telling me I’ve failed, up until I’ve entered all the numbers.
Guilty until proven innocent is the all-too often new norm with web forms.
My idea re. credit card numbers input was to make a default state that was valid, and to let the user fail if they wish. I also thought it would be good to break up the 16-diit entry into quadrants. The target user is someone a bit older, who is using a desktop computer.
I know there is more to credit card entry than just the card number, so I began to think of how to arrange the various inputs. I had in mind a multi-step process. The general goals are to be personable, reassuring, logical, and a little awesome. I want the user to be treated with dignity, and help him avoid error. Ease of use is a primary concern. We also have to be mindful of the potential for fraud. I knew I would also keep with my design philosophy of never showing something unless or until it is needed, and to show the things that are necessary.
As it turns out, the card number input shouldn’t even be displayed until screen 4 !
The First Screen
I decided that the first screen should convey warmth and personality. You are asking for someone’s money. Seems like time for a happy face. Put in some welcoming words, and an image of a smiling person. A lock-icon is a good way to convey that the page is secure.
Also use the screen to display critical info: which cards you accept; then, give the user a way to select a card type. Thus, right off the bat, the customer knows whether she has a card of the types you accept. If not, she knows not to proceed. Time saved!
Credit: the CSS for the Visa / MC buttons is based on an Alvaro Trigo hover solution.
The Second Screen
Now we can filter out customers further by asking for two critical inputs : the billing zip code, and the card’s expiration date. A thief can walk away, not knowing the zip.
The expiration date is critical. It forces the customer to examine her card and confirm that it is “still good.” If she doesn’t have an active card, she will have to walk away.
Now, I must address the essence of the inputs. For codes (a sequence of numbers) I thought it would be best to use a ‘flywheel’ such as you see on some bicycle locks. The user can click / hold and drag, let go / spin, or use her mouse’s scroller. Never has to click or press any numbers. I think this is accessible and fun. I default the values to ‘5’ because it is midway through 0-9. The solution for a ‘wheel / counter’ was provided by @Shikkediel at CodePen. You can read his post at StackOverflow.
For the expiration, I broke it up into month and year, giving each a jQuery UI slider with a custom handle to display the value. Again I set the default value in the middle. And again, the slider too is an interface that allows for entry without pressing a number from the keyboard.
As an added favor / prompt, I display the current month / year. (I didn’t make this dynamic but you could use JavaScript to fetch the Date).
The Third Screen
On our third screen, you want to collect additional required input. If a customer doesn’t have it, she knows to quit. Another filtering out before getting to the card number.
The essential “CCV” number. Again we present to the user a flywheel set at 5-5-5 to be altered to the correct value.
This is followed by the sole text input, requiring the keyboard, to get the cardholder’s name.
The Fourth Screen – Card Number
We’ve put off the longest chore to the last: entering the card number. Our 2 card types, Visa and Mastercard, each have 16-digit numbers. Because we already know the customer’s card type (from Screen 1), we are able to fill-in the first digit (either 4 for Visa, or 5 for Mastercard).
So, the customer is confronted with a matrix of 4 sets of flywheels to complete. These are also defaulted to 5.
The Fifth Screen – Confirm and Pay
We present to the customer a summary of her card information. Note the attractive pseudo-card to display card number, name, and card type.
The customer is given a secondary button to ‘go back’ to fix a mistaken card number. Else, she uses the Pay button. Note the text which spells out the authorization / consequence of clicking the Pay button.
The Final Screen – Post Payment
We show a confirmation that the payment was processed. Our smiling rep reappears. Note how we offer two ways of obtaining a receipt. The first method will show a webpage with the details. The second method is novel: it instructs the customer to send an email to an auto-responder that we could set up to send receipts based on an order number in the subject line. By using this method, the store’s domain and email address will be approved by the email vendor (usually Gmail) because the user will have a history of sending mail.
Live Demo
You can checkout the full solution. My attempt to be a “little awesome” was to give a neat animated transition between screens. Does it work?
Note: there is little validation. If I were to use in a working solution, I would add JavaScript validation on the expiration date. I would also do a validation on the card number.
I was thinking of fetching and displaying the IP number’s geolocation. This would help customize our welcome message. And it could also be used as a ‘show of force’ to convey that we are on top of things, server-wise, looking for fraud.
We could also do a geo-lookup based on the customer’s input of zipcode. Showing the IP number city , state next to the zipcode’s city / state is a nice service to convey to the customer if there is a discrepancy.
How do you like the flow of inputs and messaging? Do you think the flywheel is effective as a numerical code input? Or is it too much?
Send notes to mh at itgoeslike.com
Closing Thoughts
As long as businesses are looking to make money, they will pursue ways to make it easy for customers to pay. Much energy and ingenuity has brought about simple, fast methods to obtain payment online, especially on the phone (Apple Pay etc). Computers and browsers are also routinely used to store card information for checkouts. Nevertheless, there remains instances where a company online does not use 3rd party ‘wallets’ or pre-authorization, requiring the user to manually enter the card. In such cases, it might as well be fun.