I would generally always opt for the simplest solution. In this case, one single field for the user to type into.
With split fields, such as the 4-box one you propose it adds in an extra cognitive load to the user.
"Do I need to manually jump to each field?"
"Will the system do it for me?"
"What if I hit tab myself but the form automatically jumped - will ...
This answer and this answer cover some of the points nicely but for some reason nobody is discussing auto-fill support.
Don't use 4 separate fields.
First, it's annoying, a lot of those reasons are covered in the other answers.
Also, a CC number isn't four 4-digit numbers, it's a single long number. Some credit cards don't even have groups of four, in ...
As someone who happens to use virtual credit cards, I'm strongly in favour of a single field. Every time I want to pay, there is a new card number generated for me by the banking app, and it's very tedious to have to copy-paste four times instead of one. I'm assuming here that your form won't fill the 4 fields if I paste 16 digits in the first one. Will it?
Google and UC Berkeley tested different solutions to understand users perception of HTTPS in the browser. While this is not specifically geared to a payment page, their paper contains some strong insights when it comes to choosing an icon to signify security online.
Here's what they said specifically about the icons used in the survey:
The shield and ...
You should never save credit card information, client or server, unless you are PCI compliant. PCI stands for Payment Card Industry. You can view their website here. The standard of which we are all held to when handling credit cards is the Payment Card Industry Data Security Standard (PCI DSS).
You can get around having to be PCI compliant if you use a ...
The simplest, if not necessarily the absolute best, solution is a single credit-card field that lets a user input any string of digits and spaces. It should be trivial for the server-side logic to strip the spaces out of the submitted string before checking whether the resulting string of digits is or is not a valid credit card number. If the user chooses to ...
Users will not have as much understanding of what a credit represents as opposed to actual local currency (Dollar in this instance). Even if 1 credit = 1 dollar that is still a mental calculation the user has to do, and there is also the extra consideration they have of "Is my 1 credit still worth 1 dollar...?"
A case in point - Microsoft back in 2013 ...
Well it's not a completely unused pattern:
I see this pattern mostly used where the purchase button is the only step in the process (that or purchase button + sign in/password). This is how Google Play, iTunes/the App Store and Amazon's App store all work. Note the following about all of these stores:
There's no cart. There's one step and (usually) no ...
Baymard has done a number of studies on the subject of perceived webpage security, summarized in this article. Some key points:
Throughout all of our testing of checkout processes, we’ve consistently observed 2 important user behaviors relating to security:
Depending on the design, users perceive some parts of a page to be more secure than other ...
Your shipping and billing information is pretty crucial to the process of placing an order. If it's incorrect, your order will be misdelivered (not cool) or you won't be able to charge the customer correctly for the order.
Like any input that has such huge consequences for a software process, it is good UX to allow the user to review this essential ...
Placeholders gone terribly wrong
When a placeholder doesn't clarify anything, it shouldn't be there.
This is a great example of the negative impact of placeholder text pointed out by NN/g quite some time ago.
Summary: Placeholder text within a form field makes it difficult for people to remember what information belongs in a field, and to check ...
I don't know of any reliable research but:
these guys report 33.7% increase in conversion rate after adding paypal.
a comment for this article suggests it works.
so does this blog.
a cautionary note is in this article which is really worth reading if you are to replace current methods with paypal (not a good option - you better add it).
But seems to me ...
Stick to conventions and consistency
This is really simple: if user is charged on day 5 of the month, he should be charged on day 5 next month. Most users plan in anticipation and they know that every fifth day of the month they will be charged for a service. Otherwise, see what would happen
More often that not, what you have to store is determined by your payment processor and so you usually have very little say in the matter. When you do, the general rule for security is to only store what you absolutely have to. The less information you store, the lower your security risk, and the less information customers have to enter (in general) the ...
Free shipping is known to be one of the most effective marketing tools e-commerce sites have.
Shipping fees can affect the number of items a customer purchases, and they can decrease how frequently a customer makes purchases from the site:
With fees, shoppers will make fewer shopping trips and purchase more goods at a time -- not unlike shoppers who ...
Users need to trust your application. If you remove unavailable options, they will have a difficult time understanding the rules that dictate completion of their goals.
Here's a helpful article on dropdowns: design guidelines from Neilsen Norman:
Gray out any unavailable options instead of removing them: any items that cannot be selected should remain ...
Luke Wroblewski, a UX expert with great insights on building efficient forms, answered this question: use a single numeric input field (here’s a video of how this works).
As you can see in the video above of Zachary’s demo, a single input field is used to capture credit card number first. If the credit card number is invalid an error is displayed that ...
This has nothing to do with how you feel about this. It has everything to do with what works better for your business. I run a SaaS myself, and we require a credit card upfront to enter our 30-day free trial.
For some services, no credit card upfront works really well. For example, business to business software where an employee tries it out and then goes ...
We've been telling people to look for the lock in the address bar and to mistrust anything that says it's secure but doesn't have the lock. Any way you look at it, it's going to look like you're phishing and no amount of design is going to help you with that.
That doesn't mean everything needs to be on SSL. Amazon isn't but takes you to a secure server for ...
Without knowing the numbers for the lifetime value of a customer, and the percentage of people that do give you new credit card information, we can only offer generic advice.
Ideally you should make sure that there is something in it for your customer. Something like giving them a month free service if they update their credit card details within the next ...
I recommend reading this excellent case study of how Evernote got its customers to pay for its service which was initally free. To quote the article
But according to one hugely successful startup which operates under
the Freemium model, Evernote, converting free to paid is all about
"The easiest way to get a million people to pay for ...
This is a "Steps Left" pattern:
The Steps Left pattern is used when it is critical to maintain the user’s focus throughout the process of filling in data to the system. This is for instance critical in web-shops, where the checkout process is often guided by this pattern. In web-shops, the checkout process is the most critical part of the site, as this is ...
A few things things to consider:
Having the name can help with sorting out some kinds of credit card fraud offline. You can usually call the card issuer directly and validate that the name, card number and address match for example.
Some folk use the name as a way to filter out some kinds of pre-payment credit cards (like visa gift cards) that don't have a ...
Show them the order status page, thank them for their purchase and send them the receipt or purchase order via email. Whether you want to make this an entire page or pop up is up to your design. You could also throw in some product recommendation based on their current purchase.
Swift/BIC codes follow this convention:
AAAA BB CC DDD
AAAA Bank code A-Z
4 letter code. It usually looks like a shortened version of that bank's name.
BB Country code A-Z
2 letter code. It says which country that bank is in.
CC Location code 0-9 A-Z
2 digit location code that could be either 2 letters or numbers. It says where that bank's head office is....
You have to make sure users entered the correct email address prior to proceeding with the order, otherwise billing information could reach the wrong person or be lost.
Also, just because you need an email address doesn't mean users have to sign up: Should registration be optional on an e-commerce site?
If the users need to register prior to ...
Please follow the advice of others and do not attempt to reinvent the wheel. Not unless you have read and understood the ISO standard ISO/IEC 7812 that governs Payment card numbers, which, by the way, range from 13 to 19 digits and usually (but not always - read the spec) include a check digit that you can use to validate the input.
Inserting spaces where ...
I simply can't believe they did this. First of all, it shows a definite bias. Cards starting with 4 belong to VISA, so I can imagine all other CC card companies complaining.
Another thing: 4 groups of 4 digits, equalling 16 digits number. It sounds nice.... if it wasn't because I'm an AMEX owner. AMEX cards use the format NNNN NNNNNN NNNNN (4 digits + 6 ...
To protect user from such situation you will need two session records:
CART_ITEMS - Items that are currently in the cart.
CHECKOUT_ITEMS - Items the user is about to pay for.
Before you send the payment token to the server you need to compare CHECKOUT_ITEMS with CART_ITEMS and if there are any differences you inform the user of these changes.
I feel like you're going about this the wrong way, you should ask the creator of the button, prior to any implementation, the questions if it fundamentally relies on them being in the right country and having registered for Stripe, something like this:
This prevents them from placing a button that potentially would not work, on their site in the first place....