If users have no way of paying you, they have no way of buying anything from you, and so it’s clear that accepting a wide range of payment methods is a good idea to ensure that all users actually have a way of sending money your way.
Yet, during our checkout usability studies, we observed how just presenting the user with a bunch of payment methods introduces complexity to the checkout process, and must be designed carefully to avoid confusion and choice paralysis.
For international sites accepting multiple payment methods is not just a matter of user preferences (although that is certainly a benefit of it too), given that in markets such as Germany, China and Russia, international cards such as VISA and MasterCard have less than 40% online payments market share, with solutions like ELV, Union Pay, QIWI and Alipay, being very popular payment methods. Similar tendencies can be found in B2B and B2G where accepting invoice and bank transfers can be mission critical. (For more on why it’s so important to accept numerous payment methods and which types of payment methods exist, see the addendum at the end of this article.)
So how do you design a checkout process that gives the user plenty of payment methods to choose between without introducing needless friction and complexity, or triggering choice paralysis?
In this article we’ll go over some common pitfalls when designing the payment method selection, look at a couple of “best practice” examples, as well as outline a set of principles for how to design a good payment method selection interface.
Pitfalls in Payment Method Designs
While preferable to offer a lot of payment methods, simply throwing options at the user can go horribly wrong if great care isn’t taken in how the options are presented, as evidenced by the following examples. You’ll notice that the design pitfalls largely revolve around proximity and selection state – both of which become even more expressed during mobile optimized checkout flows, as observed during our year long mobile usability study, due to the decrease in context caused by smaller screen sizes.
During our usability studies we’ve time and again observed how radio buttons placed far apart cause great confusion among the test subjects – that is when they are not overlooked altogether. The test subjects simply lack the necessary context to understand the implications of the radio button and often did not activate the radio button, even as they began filling out any associated fields next to it.
Proximity is key in making radio buttons user-friendly – the options must be placed next to one another so the user perceives them as a collection mutually exclusive of choices, and can view and compare all the options without scrolling around the page.
In an effort to solve this proximity issue, some sites place all the payment methods in a list and then push the active content below these options. However, this just introduces a new proximity issue, as the active content is now “detached” from the selected option (except when the last option is selected).
It essentially works like a “tab design” but without the necessary visual clues to cement the relationship between selected option and active content. Tabs are an excellent design pattern, and indeed a very appropriate solution to this payment method selection design issue, but tabs must be designed as actual tabs in order to effectuate these affordances.
It’s critical that the “active” or selected payment method is absolutely clear to the user. In the above diapers.com example this isn’t clear at all as all form fields for each option are laid out at the page. In fact, the user never selects a payment method, instead they are supposed to fill out some form fields and then submit a payment method.
This understandably cause great confusion for some users and makes the page appear intimidating with the wealth of headers, form fields and apply buttons appearing on the user’s screen. A much better approach would be to progressively disclose relevant (and hide irrelevant) form fields and buttons based on user selections.
You can browse our checkout usability benchmark database to see 104 different examples of payment steps from the 100 top grossing e-commerce sites.
How to Design Payment Method Selection
So how should the payment method selection be designed? There isn’t one “right” design as it depends on the number and types of payment methods accepted, as well as the rest of the checkout design. However, while there isn’t one “right” solution there are a number of principles to follow when designing the payment method selection in your checkout process:
- Place the options in close proximity so the user can see all the available payment methods in a single view, allowing them to compare the options and make an informed decision about which one to choose.
- Make it absolutely clear which option is currently selected – the user must never be in doubt about which payment method that’s currently active.
- Use progressive disclosure to gradually reveal form fields so the user only sees form fields relevant to the current selection(s).
- Explain the different payment methods and highlight their most important implications (e.g. “1% fee when paying with American Express” or “product only shipped once bank transfer clears”) so the user can make an informed decision about which option is the most appropriate to them.
- Consider having a default selection to speed up form entry and reduce choice paralysis by nudging users towards a particular payment method (typically the most popular one).
Let’s look at a couple of “best practice” implementations that adhere to these principles.
Best Buy uses a tabbed interface for the payment method selection during checkout. Notice how all the options are placed in close proximity so the user will perceive them as a collection and compare them to one another. Furthermore, the tabbed design makes it abundantly clear which option is currently selected and ensures that only form fields relevant to the current selection are displayed. Finally, Best Buy have made “Credit Card” the default choice so the user doesn’t have to stop and think but can simply proceed unless they want to make use of one of the other secondary payment methods accepted.
Tabbed interfaces generally lend themselves very well to this particular design challenge as they bundle the options together in a single collection, make it clear what is and isn’t selected, and ensures that only relevant content is displayed. We’ve found both vertical (see Best Buy above) and horizontal (see Apple) tab designs to perform equally well.
An alternative solution can be found at Blue Nile, where an entire checkout step is dedicated to selecting a payment method. By dedicating an entire checkout step to the payment method selection, Blue Nile has plenty of space to explain each of five payment methods offered and highlight the most important implications of each one (such as the 1.5% discount when selecting “Bank Wire”).
While this design introduces a little more friction compared to the tab design (Best Buy example) – where a default choice has been made for the user and form fields are displayed inline as the payment method is selected – this friction may be warranted in certain circumstances if it helps the user make a more informed about the most appropriate payment method to them. This is appropriate for Blue Nile where orders are high in value and users will likely need to consider their payment options more closely, whereas the tabbed interface makes better sense for Best Buy where more orders will tend to be more impulse-driven and generally be smaller in value.
In short: Make sure you support a wide range of payment methods so potential customers are actually able to buy from you, and possibly even have a few options to choose between (see more on this in the addendum). And then reduce checkout friction with a payment method design that: ensure the payment methods are in close proximity, makes the selected method completely clear, utilize progressive disclosure, explain the differences between the payment methods, and have any vastly popular method selected as default.