One of the most fragile parts of an e-commerce checkout is how you handle credit card details. Due to security requirements from VISA and MasterCard (PCI compliance), most e-commerce sites aren’t allowed to even temporarily store the customer’s credit card details on their server.
This means the credit card data can’t be reused later (or even immediately after the request) in the checkout process. So most e-commerce sites are forced to clear out the credit card fields on form errors, even if the error isn’t actually in the credit card details.
This is obviously very annoying to the customer. After all, credit card numbers are long, they have to be transcribed from a physical card, and it’s the point during checkout where the customer usually feels the most uneasy. The whole process is bothersome and prone to human mistakes.
So what can you do? There’s 2 solutions, other than of course seeking approval to store your customers credit cards (a complex and expensive process).
When credit card details are the only thing being validated on form submit, the data only needs to be cleared if the card is declined. This is definitely better than nothing since the credit card data was likely wrong in the first place, so clearing it can be excused.
However, during our checkout usability study we found that people much preferred to correct their data, rather than having it cleared out completely. Another downside is that it adds another step to your checkout flow (no one-page checkouts).
This is a decent work-around, but it doesn’t truly solve the problem.
One of the perks of submitting forms with AJAX is that form data retention is given to you for free. So in the case of credit card details, they never disappear from the customer’s screen because the page isn’t reloaded. (In fact, you’d have to specifically program the form to clear out in order for that to happen.)
So the credit card fields stay intact on the customer’s end, and just as important: your servers still don’t store any credit card details. You’ve effectively managed to preserve the customer’s credit card data without adding any security overhead to your back-end.
This is particularly important for one-page checkouts where an empty required field or other form error would otherwise cause all credit card data to be cleared out – even if the credit card data itself is valid.
A simple upgrade for an existing system would be to simply submit the form with AJAX and then then redirect the customer to the next step as usual if the data is accepted. This means you won’t have to change too much in your existing system yet you get around clearing out the credit card fields.
A more substantial change would be to make your entire checkout run via AJAX (unobtrusively of course). Companies like Apple and AllPosters are doing this. It can speed up the checkout process significantly since you only load the page once, and nice visual transitions from one checkout step to the other can be implemented.
So there you have it. A couple of solutions to preserving the customer’s credit card details on form errors.
Join 22,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
is it possible to do these validations using jquery instead of ajax ?
The big danger with this approach is that you risk an impatient user submitting the form multiple times and possibly causing multiple charges on the card. An issue with standard forms too, but my experience has been that the problem is much worse with fancy ajax forms unless you’re really a UX expert. There are good technical ways to avoid that problem as well, but some of them depend on your merchant processor’s capabilities and are way beyond the scope of a comment on a blog post.
@Suhail: Part of the Jquery framework includes Ajax. In fact the vast majority of Jquery is built to provide easier use of ajax functionality. So yes you can (but technically it’s not ‘instead of’)
@Jamie: Great article! The vast majority of sites have a ‘confirmation’ step (review your order before processing) between where the payment information is entered and when it is actually processed with the gateway. Under your model, how do you accommodate for this step and remain compliant?
Those sites store the customer’s CC info so they would already have the necessary PCI compliance level to do that. However, if you wish to do this without storing (even temporarily) the customer’s CC details, then you could do a full AJAX checkout (solution #2, 2nd approach).
This way you could just validate all the data and send the summary view back to the customer’s screen without actually refreshing the DOM, and then only when they click “Place order” send the CC details to the payment gateway. However, in that case the CC details wouldn’t be validated immediately, but only when you actually try to place the order.
It’s quite probable these sites are performing a 2-step authorize/capture on the details, using a token provided by the payment gateway to match these up:
When card details are submitted, the site sends them to the payment gateway and gets a token in return following successful authorization of the card (no funds are taken).
When the customer confirms the sale the site returns the token to the payment gateway and charges the card, sans card details.
You can return the credit card number without storing it in a database or session. As far as i know, credit card companies do not allow most merchants to store numbers and CVV, but returning the number when validation fails is totally different. The credit card details are submitted with the post request, and can be returned if the validation fails. I believe that a lot of web frameworks do that automatically.
Absolutely, and this is how it should be handled. There’s no need to store card details on the server if it’s contained within the same request/response pair, however you DO need to be careful about filtering your logs to exclude card numbers and CVVs. Many application servers will log these parameters even when they appear in POST requests, and it’s part of your PCI compliance questionnaire that you address this.
© 2021 Baymard Institute US: +1 (415) 315-9567 EU: +45 3696 9567 firstname.lastname@example.org