Payment and address form best practices

Maximize conversions by helping your users complete address and payment forms as quickly and easily as possible.

Sam Dutton

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

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

Use meaningful HTML elements: <form>, <input>, <label>, and <button>.
Label each form field with a <label>.
Use HTML element attributes to access built-in browser features, in particular type and autocomplete with appropriate values.
Avoid using type="number" for numbers that aren't meant to be incremented, such as payment card numbers. Use type="text" and inputmode="numeric" instead.
If an appropriate autocomplete value is available for an input, select, or textarea, you should use it.
To help browsers autofill forms, give input name and id attributes stable values that don't change between page loads or website deployments.
Disable submit buttons once they've been tapped or clicked.
Validate data during entry—not just on form submission.
Make guest checkout the default and make account creation simple once checkout is complete.
Show progress through the checkout process in clear steps with clear calls to action.
Limit potential checkout exit points by removing clutter and distractions.
Show full order details at checkout and make order adjustments straightforward.
Don't ask for data you don't need.
Ask for names with a single input unless you have a good reason not to.
Don't enforce Latin-only characters for names and usernames.
Allow for a variety of address formats.
Consider using a single textarea for address.
Use autocomplete for billing address.
Internationalize and localize where necessary.
Consider avoiding postal code address lookup.
Use appropriate payment card autocomplete values.
Use a single input for payment card numbers.
Avoid using custom elements if they break the autofill experience.
Test in the field as well as the lab: page analytics, interaction analytics, and real-user performance measurement.
Test on a range of browsers, devices, and platforms.

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.

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.

Caution: The default type for a button in a form is submit. If you want to add another button in a form (for Show password, for example) add type="button". Otherwise clicking or tapping on the button will submit the form. Pressing the Enter key while any form field has focus simulates a click on the first submit button in the form. If you include a button in your form before the Submit button, and don't specify the type, that button will have the default type for buttons in a form (submit) and receive the click event before the form is submitted. For an example of this, see our enter button demo: fill in the form, then press Enter.

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 address (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.

Note: 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 demo.

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.

Stable values

Note: 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.

Billing address

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.