Payment and address form best practices

Well-designed forms help users and increase conversion rates. One small fix can make a big difference!

Try it!
If you prefer to learn these best practices with a hands-on tutorial, check out the two codelabs
for this post:

Payment form best prac…

Well-designed forms help users and increase conversion rates. One small fix can make a big difference!

Try it!
If you prefer to learn these best practices with a hands-on tutorial, check out the two codelabs
for this post:

Here is an example of a simple payment form that demonstrates all of the best practices:

Here is an example of a simple address form that demonstrates all of the best practices:

Checklist

This article is about frontend best practices for address and payment forms. It does not explain
how to implement transactions on your site. To find out more about adding payment functionality to your
website, see Web Payments.

Use meaningful HTML

Use the elements and attributes built for the job:

  • <form>, <input>, <label>, and <button>
  • type, autocomplete, and inputmode

These enable built-in browser functionality, improve accessibility, and add meaning to your markup.

Use HTML elements as intended

Put your form in a <form>

You might be tempted not to bother wrapping your <input> elements in a <form>, and to handle data
submission purely with JavaScript.

Don’t do it!

An HTML <form> gives you access to a powerful set of built-in features across all modern browsers,
and can help make your site accessible to screen readers and other assistive devices. A <form>
also makes it simpler to build basic functionality for older browsers with limited JavaScript
support, and to enable form submission even if there’s a glitch with your code—and for the
small number of users who actually disable JavaScript.

If you have more than one page component for user input, make sure to put each in its own <form>
element. For example, if you have search and sign-up on the same page, put each in its own <form>.

Use <label> to label elements

To label an <input>, <select>, or <textarea>, use a <label>.

Associate a label with an input by giving the label’s for attribute the same value as
the input’s id.

<label for="address-line1">Address line 1</label>
<input id="address-line1" >

Use a single label for a single input: don’t try to label multiple inputs with only one label. This
works best for browsers, and best for screenreaders. A tap or click on a label moves focus to the input
it’s associated with, and screenreaders announce label text when the label or the label’s input
gets focus.

Caution:
Don’t use placeholders
on their own instead of labels. Once you start entering text in an input, the
placeholder is hidden, so it can be easy to forget what the input is for. The same is true if
you use the placeholder to show the correct format for values such as dates. This can be especially
problematic for users on phones, particularly if they’re distracted or feeling stressed!

Make buttons helpful

Use <button>
for buttons! You can also use <input type="submit">, but don’t use a div or some
other random element acting as a button. Button elements provide accessible behaviour, built-in
form submission functionality, and can easily be styled.

Give each form submit button a value that says what it does. For each step towards checkout, use
a descriptive call-to-action that shows progress and makes the next step obvious. For example, label
the submit button on your delivery address form Proceed to Payment rather than Continue
or Save.

Consider disabling a submit button once the user has tapped or clicked it—especially when the user is
making a payment or placing an order. Many users click buttons repeatedly, even if they’re working fine.
That can mess up checkout and add to server load.

On the other hand, don’t disable a submit button waiting on complete and valid user input. For
example, don’t just leave a Save Address button disabled because something is missing or invalid.
That doesn’t help the user—they may continue to tap or click the button and assume that it’s broken.
Instead, if users attempt to submit a form with invalid data, explain to them what’s gone wrong
and what to do to fix it. This is particularly important on mobile, where data entry is more
difficult and missing or invalid form data may not be visible on the user’s screen by the time they
attempt to submit a form.

Make the most of HTML attributes

Make it easy for users to enter data

Use the appropriate input type attribute
to provide the right keyboard on mobile and enable basic built-in validation by the browser.

For example, use type="email" for email addresses and type="tel" for phone numbers.

Two screenshots of Android phones, showing a keyboard appropriate 
  for entering an email addresss (using type=email) and for entering a telephone number (with type=tel).
Keyboards appropriate for email and telephone.

Warning:
Using type="number" adds an up/down arrow to increment numbers, which makes no sense for data such
as telephone, payment card or account numbers.

For numbers like these, set type="text" (or leave off the attribute, since text is the default).
For telephone numbers, use type="tel" to get the appropriate keyboard on mobile. For other numbers
use inputmode="numeric" to get a numeric keyboard on mobile.

Some sites still use type="tel" for payment card numbers to ensure that mobile users get the right
keyboard. However, inputmode is very widely supported now,
so you shouldn’t have to do that—but do check your users’ browsers.

For dates, try to avoid using custom select elements. They break the autofill experience if not
properly implemented and don’t work on older browsers. For numbers such as birth year, consider
using an input element rather than a select, since entering digits manually can be easier and less
error prone than selecting from a long drop-down list—especially on mobile. Use inputmode="numeric"
to ensure the right keyboard on mobile and add validation and format hints with text or a
placeholder to make sure the user enters data in the appropriate format.

The datalist element enables
a user to select from a list of available options and provides matching suggestions as the user enters text.
Try out datalist for text, range and color inputs at simpl.info/datalist.
For birth year input, you can compare a select with an input and datalist at datalist-select.glitch.me.

Use autocomplete to improve accessibility and help users avoid re-entering data

Using appropriate autocomplete values enables browsers to help users by securely storing data and
autofilling input, select, and textarea values. This is particularly important on mobile, and
crucial for avoiding high form abandonment rates. Autocomplete also provides multiple accessibility benefits.

If an appropriate autocomplete value is available for a form field, you should use it. MDN web docs has a full list of values and explanations of how to use
them correctly.

As well as using appropriate autocomplete values, help browsers autofill forms by giving form fields
name and id attributes stable values that don’t change between page loads or
website deployments.

By default, set the billing address to be the same as the delivery address. Reduce visual clutter by
providing a link to edit the billing address (or use summary and details elements)
rather than displaying the billing address in a form.

Example checkout page showing link 
  to change billing address.
Add a link to review billing.

Use appropriate autocomplete values for the billing address, just as you do for shipping address,
so the user doesn’t have to enter data more than once. Add a prefix word to autocomplete
attributes if you have different values for inputs with the same name in different sections.

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

Help users enter the right data

Try to avoid "telling off" customers because they "did something wrong". Instead, help users complete
forms more quickly and easily by helping them fix problems as they happen. Through the checkout process,
customers are trying to give your company money for a product or service—your job is to assist them,
not to punish them!

You can add constraint attributes to form elements to specify acceptable
values, including min, max, and pattern. The validity state
of the element is set automatically depending on whether the element’s value is valid, as are the
:valid and :invalid CSS pseudo-classes which can be used to style elements with valid or invalid
values.

For example, the following HTML specifies input for a birth year between
1900 and 2020. Using type="number" constrains input values to numbers only, within the range
specified by min and max. If you attempt to enter a number outside the range, the input will be
set to have an invalid state.

The following example uses pattern="[\d ]{10,30}" to ensure a valid payment card number, while
allowing spaces:

Modern browsers also do basic validation for inputs with type email or url.

Add the multiple attribute to an input with type="email" to enable built-in validation for
multiple comma-separated email addresses in a single input.

On form submission, browsers automatically set focus on fields with problematic or missing required
values. No JavaScript required!

Screenshot of a sign-in form in 
  Chrome on desktop showing browser prompt and focus for an invalid email value.
Basic built-in validation by the browser.

Validate inline and provide feedback to the user as they enter data, rather than providing a list of
errors when they click the submit button. If you need to validate data on your server after form
submission, list all problems that are found and clearly highlight all form fields with invalid
values, as well as displaying a message inline next to each problematic field explaining what needs
to be fixed. Check server logs and analytics data for common errors—you may need to redesign your form.

You should also use JavaScript to do more robust validation while users are entering data and
on form submission. Use the Constraint Validation API
(which is widely supported) to add custom
validation using built-in browser UI to set focus and display prompts.

Find out more in Use JavaScript for more complex real-time validation.

Warning:
Even with client-side validation and data input constraints, you must still ensure that your
back-end securely handles input and output of data from users. Never trust user input: it could be
malicious. Find out more in OWASP Input Validation Cheat Sheet.

Help users avoid missing required data

Use the required attribute
on inputs for mandatory values.

When a form is submitted modern browsers
automatically prompt and set focus on required fields with missing data, and you can use the
:required pseudo-class to highlight required fields. No
JavaScript required!

Add an asterisk to the label for every required field, and add a note at the start of the form to
explain what the asterisk means.

Simplify checkout

Mind the mobile commerce gap!

Imagine that your users have a fatigue budget. Use it up, and your users will leave.

You need to reduce friction and maintain focus, especially on mobile. Many sites get more traffic
on mobile but more conversions on desktop—a phenomenon known as the mobile commerce gap. Customers may simply prefer to
complete a purchase on desktop, but lower mobile conversion rates are also a result of poor user
experience. Your job is to minimize lost conversions on mobile and maximize conversions
on desktop. Research has shown that there’s a huge opportunity to provide a better mobile form experience.

Most of all, users are more likely to abandon forms that look long, that are complex, and without a sense of
direction. This is especially true when users are on smaller screens, distracted, or in a rush. Ask for as
little data as possible.

Make guest checkout the default

For an online store, the simplest way to reduce form friction is to make guest checkout the default.
Don’t force users to create an account before making a purchase. Not allowing guest checkout is cited
as a major reason for shopping cart abandonment.

Reasons for shopping 
  cart abandonment during checkout.
From baymard.com/checkout-usability

You can offer account sign-up after checkout. At that point, you already have most of the data you
need to set up an account, so account creation should be quick and easy for the user.

Gotchas!

If you do offer sign-up after checkout, make sure that the purchase the user just made is linked to
their newly created account!

Show checkout progress

You can make your checkout process feel less complex by showing progress and making it clear what
needs to be done next. The video below shows how UK retailer johnlewis.com
achieves this.

Show checkout progress.

You need to maintain momentum! For each step towards payment, use page headings and descriptive
button values that make it clear what needs to be done now, and what checkout step is next.

Give form buttons meaningful names that show what’s next.

Use the enterkeyhint attribute on form inputs to set the mobile keyboard enter key label. For
example, use enterkeyhint="previous" and enterkeyhint="next" within a multi-page form,
enterkeyhint="done" for the final input in the form, and enterkeyhint="search" for a search
input.

Two screenshots of an address form 
  on Android showing how the enterkeyhint input attribute changes the enter key button icon.
Enter key buttons on Android: ‘next’ and ‘done’.

The enterkeyhint attribute is supported on Android and iOS.
You can find out more from the enterkeyhint explainer.

Make it easy for users to go back and forth within the checkout process, to easily adjust
their order, even when they’re at the final payment step. Show full details of the order, not just
a limited summary. Enable users to easily adjust item quantities from the payment page. Your priority at checkout is to
avoid interrupting progress towards conversion.

Remove distractions

Limit potential exit points by removing visual clutter and distractions such as product promotions.
Many successful retailers even remove navigation and search from checkout.

Two screenshots on mobile 
  showing progress through johnlewis.com checkout. Search, navigation and other distractions are 
  removed.
Search, navigation and other distractions removed for checkout.

Keep the journey focused. This is not the time to tempt users to do something else!

Screenshot of checkout page on 
  mobile showing distracting promotion for FREE STICKERS.
Don’t distract customers from completing their purchase.

For returning users you can simplify the checkout flow even more, by hiding data they don’t need to
see. For example: display the delivery address in plain text (not in a form) and allow users to
change it via a link.

Screenshot of 'Review order' 
  section of checkout page, showing text in plain text, with links to change delivery address, 
  payment method and billing address, which are not displayed.
Hide data customers don’t need to see.

Make it easy to enter name and address

Only ask for the data you need

Before you start coding your name and address forms, make sure to understand what data is required.
Don’t ask for data you don’t need! The simplest way to reduce form complexity is to remove unnecessary
fields. That’s also good for customer privacy and can reduce back-end data cost and liability.

Use a single name input

Allow your users to enter their name using a single input, unless you have a good reason for
separately storing given names, family names, honorifics, or other name parts. Using a single name
input makes forms less complex, enables cut-and-paste, and makes autofill simpler.

In particular, unless you have good reason not to, don’t bother adding a separate input for a
prefix or title (like Mrs, Dr or Lord). Users can type that in with their name if they want to. Also,
honorific-prefix autocomplete currently doesn’t work in most browsers, and so adding a field for
name prefix or title will break the address form autofill experience for most users.

Enable name autofill

Use name for a full name:

<input autocomplete="name" ...>

If you really do have a good reason to split out name parts, make sure to to use appropriate
autocomplete values:

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

Allow international names

You might want to validate your name inputs, or restrict the characters allowed for name data. However,
you need to be as unrestrictive as possible with alphabets. It’s rude to be told your name is "invalid"!

For validation, avoid using regular expressions that only match Latin characters. Latin-only excludes
users with names or addresses that include characters that aren’t in the Latin alphabet. Allow Unicode
letter matching instead—and ensure your back-end supports Unicode securely as both input and output.
Unicode in regular expressions is well supported by modern browsers.

Don’t

<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>

Do

<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
Unicode letter matching compared to Latin-only letter matching.

You can find out more about internationalization and localization
below, but make sure your forms work for names in all regions where you have users. For example,
for Japanese names you should consider having a field for phonetic names. This helps customer
support staff say the customer’s name on the phone.

Allow for a variety of address formats

When you’re designing an address form, bear in mind the bewildering variety of address formats,
even within a single country. Be careful not to make assumptions about "normal" addresses. (Take a
look at UK Address Oddities! if you’re not
convinced!)

Make address forms flexible

Don’t force users to try to squeeze their address into form fields that don’t fit.

For example, don’t insist on a house number and street name in separate inputs, since many addresses
don’t use that format, and incomplete data can break browser autofill.

Be especially careful with required address fields. For example, addresses in large cities in the
UK do not have a county, but many sites still force users to enter one.

Using two flexible address lines can work well enough for a variety of address formats.

<input autocomplete="address-line-1" id="address-line1" ...>
<input autocomplete="address-line-2" id="address-line2" ...>

Add labels to match:

<label for="address-line-1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line-1" id="address-line1" ...>

<label for="address-line-2">
Address line 2 (optional)
</label>
<input autocomplete="address-line-2" id="address-line2" ...>

You can try this out by remixing and editing the demo embedded below.

Caution:
Research shows that Address line 2 may be problematic for users.
Bear this in mind when designing address forms—you should consider alternatives such as using a
single textarea (see below) or other options.

Consider using a single textarea for address

The most flexible option for addresses is to provide a single textarea.

The textarea approach fits any address format, and it’s great for cutting and pasting—but bear in
mind that it may not fit your data requirements, and users may miss out on autofill if they previously
only used forms with address-line1 and address-line2.

For a textarea, use street-address as the autocomplete value.

Here is an example of a form that demonstrates the use of a single textarea for address:

Internationalize and localize your address forms

It’s especially important for address forms to consider internationalization and localization, depending
on where your users are located.

Be aware that the naming of address parts varies as well as address formats, even within the same
language.

    ZIP code: US
Postal code: Canada
Postcode: UK
Eircode: Ireland
PIN: India

It can be irritating or puzzling to be presented with a form that doesn’t fit your address or that
doesn’t use the words you expect.

Customizing address forms for multiple locales may be necessary for your site, but using techniques
to maximize form flexibility (as described above) may be adequate. If you don’t localize your address
forms, make sure to understand the key priorities to cope with a range of address formats:

  • Avoid being over-specific about address parts, such as insisting on a street name or house number.
  • Where possible avoid making fields required. For example, addresses in many countries don’t
    have a postal code, and rural addresses may not have a street or road name.
  • Use inclusive naming: ‘Country/region’ not ‘Country’; ‘ZIP/postal code’ not ‘ZIP’.

Keep it flexible! The simple address form example above can be adapted to work
‘well enough’ for many locales.

Consider avoiding postal code address lookup

Some websites use a service to look up addresses based on postal code or ZIP. This may be sensible
for some use cases, but you should be aware of the potential downsides.

Postal code address suggestion doesn’t work for all countries—and in some regions, post codes can
include a large number of potential addresses.

ZIP or postal codes may include a lot of addresses!

It’s difficult for users to select from a long list of addresses—especially on mobile if they’re
rushed or stressed. It can be easier and less error prone to let users take advantage of autofill,
and enter their complete address filled with a single tap or click.

A single name input enables one-tap (one-click) address entry.

Simplify payment forms

Payment forms are the single most critical part of the checkout process. Poor payment form design is
a common cause of shopping cart abandonment. The devil’s in the details: small
glitches can tip users towards abandoning a purchase, particularly on mobile. Your job is to design
forms to make it as easy as possible for users to enter data.

Help users avoid re-entering payment data

Make sure to add appropriate autocomplete values in payment card forms, including the payment card
number, name on the card, and the expiry month and year:

  • cc-number
  • cc-name
  • cc-exp-month
  • cc-exp-year

This enables browsers to help users by securely storing payment card details and correctly entering form
data. Without autocomplete, users may be more likely to keep a physical record of payment card details,
or store payment card data insecurely on their device.

Caution:
Don’t add a selector for payment card type, since this can always be inferred from the payment card
number.

Avoid using custom elements for payment card dates

If not properly designed, custom elements
can interrupt payment flow by breaking autofill, and won’t work on older browsers. If all other
payment card details are available from autocomplete but a user is forced to find their physical
payment card to look up an expiry date because autofill didn’t work for a custom element, you’re
likely to lose a sale. Consider using standard HTML elements instead, and style them accordingly.

Screenshot of payment 
  form showing custom elements for card expiry date that interrupt autofill.
Autocomplete filled all the fields—except the expiry date!

Use a single input for payment card and phone numbers

For payment card and phone numbers use a single input: don’t split the number into parts. That makes
it easier for users to enter data, makes validation simpler, and enables browsers to autofill.
Consider doing the same for other numeric data such as PIN and bank codes.

Screenshot of payment form showing a 
  credit card field split into four input elements.
Don’t use multiple inputs for a credit card number.

Validate carefully

You should validate data entry both in realtime and before form submission. One way to do this is by
adding a pattern attribute to a payment card input. If the user attempts to submit the payment form
with an invalid value, the browser displays a warning message and sets focus on the input. No
JavaScript required!

However, your pattern regular expression must be flexible enough to handle the range of payment card
number lengths
: from 14
digits (or possibly less) to 20 (or more). You can find out more about payment card number structuring
from LDAPwiki.

Allow users to include spaces when they’re entering a new payment card number, since this is how
numbers are displayed on physical cards. That’s friendlier to the user (you won’t have to tell them
"they did something wrong"), less likely to interrupt conversion flow, and it’s straightforward to
remove spaces in numbers before processing.

You may want to use a one-time passcode for identity or payment verification. However, asking users
to manually enter a code or copy it from an email or an SMS text is error-prone and a source of friction.
Learn about better ways to enable one-time passcodes in SMS OTP form best practices.

Test on a range of devices, platforms, browsers and versions

It’s particularly important to test address and payment forms on the platforms most common for
your users, since form element functionality and appearance may vary, and differences in viewport
size can lead to problematic positioning. BrowserStack enables free testing for open source projects on a range of devices and browsers.

Screenshots of a payment form, payment-form.glitch.me, on 
  iPhone 7 and 11. The Complete Payment button is shown on iPhone 11 but not 7
The same page on iPhone 7 and iPhone 11.
Reduce padding for
smaller mobile viewports to ensure the Complete payment button isn’t hidden.

Implement analytics and RUM

Testing usability and performance locally can be helpful, but you need real-world data to properly
understand how users experience your payment and address forms.

For that you need analytics and Real User Monitoring—data for the experience of actual users, such
as how long checkout pages take to load or how long payment takes to complete:

  • Page analytics: page views, bounce rates and exits for every page with a form.
  • Interaction analytics: goal funnels
    and events
    indicate where users abandon your checkout flow and what actions do they take when interacting
    with your forms.
  • Website performance: user-centric metrics can tell you if your
    checkout pages are slow to load and, if so—what’s the cause.

Page analytics, interaction analytics, and real user performance measurement become especially
valuable when combined with server logs, conversion data, and A/B testing, enabling you to answer
questions such as whether discount codes increase revenue, or whether a change in form layout
improves conversions.

That, in turn, gives you a solid basis for prioritizing effort, making changes, and rewarding success.

Keep learning

Photo by @rupixen on Unsplash.


Print Share Comment Cite Upload Translate
APA
Sam Dutton | Sciencx (2024-03-28T22:30:47+00:00) » Payment and address form best practices. Retrieved from https://www.scien.cx/2020/12/09/payment-and-address-form-best-practices/.
MLA
" » Payment and address form best practices." Sam Dutton | Sciencx - Wednesday December 9, 2020, https://www.scien.cx/2020/12/09/payment-and-address-form-best-practices/
HARVARD
Sam Dutton | Sciencx Wednesday December 9, 2020 » Payment and address form best practices., viewed 2024-03-28T22:30:47+00:00,<https://www.scien.cx/2020/12/09/payment-and-address-form-best-practices/>
VANCOUVER
Sam Dutton | Sciencx - » Payment and address form best practices. [Internet]. [Accessed 2024-03-28T22:30:47+00:00]. Available from: https://www.scien.cx/2020/12/09/payment-and-address-form-best-practices/
CHICAGO
" » Payment and address form best practices." Sam Dutton | Sciencx - Accessed 2024-03-28T22:30:47+00:00. https://www.scien.cx/2020/12/09/payment-and-address-form-best-practices/
IEEE
" » Payment and address form best practices." Sam Dutton | Sciencx [Online]. Available: https://www.scien.cx/2020/12/09/payment-and-address-form-best-practices/. [Accessed: 2024-03-28T22:30:47+00:00]
rf:citation
» Payment and address form best practices | Sam Dutton | Sciencx | https://www.scien.cx/2020/12/09/payment-and-address-form-best-practices/ | 2024-03-28T22:30:47+00:00
https://github.com/addpipe/simple-recorderjs-demo