Checkout form design: what keeps shoppers on the page

Approval rate gets most of the attention in payments, but an issuer can only approve a payment that reaches it. Before that, the shopper has to get through a form on a small screen, often on a keyboard that covers half of it. In Baymard Institute’s data on US shoppers who abandoned for reasons other than browsing, 17% blamed a checkout that was too long or complicated, 18% left because the site wanted an account, and 17% hit website errors or crashes.

This article covers the mechanics of the form: how many fields to show, how to handle accounts, when to validate, how to make autofill and card entry work, and which keyboard each field should open. It is based on published research, mostly from Baymard. Baymard estimates that fixing solvable checkout usability issues could raise conversion by 35.26% for the average large e-commerce site, which is its own estimate from testing large US and EU sites, not a promise for any one store. For market differences, see checkout localisation. For what to show after a decline, see decline messages at checkout.

How many fields should a checkout form have?

As few as you can defend. Baymard’s benchmark found that the average checkout flow in 2024 had 5.1 steps and 11.3 form fields, and it says most sites need only 8. It advises teams to focus on how many fields shoppers must review or consider, not on the step count.

Most of the saving comes from a short list of familiar fields.

Field	What the research suggests	Source
First name and last name	One full name field: 89% of sites use more than one, yet users think of a name as a single entity	Baymard, web.dev
Address line 2	Hide it behind a link	Baymard
Company name, extra phone numbers	Hide them behind links	Baymard
Coupon code	Hide it behind a link	Baymard
Billing address	Default it to the shipping address	Baymard
Card type selector	Remove it: the type can be inferred from the number	web.dev
Account creation	Move it to the confirmation step	Baymard

web.dev adds one exception on names: split the field only if you have a good reason to store the parts separately. Some providers do ask for a first and last name, so check their requirements. The broader question of which data each method needs is covered in collecting customer data at checkout.

Should you force shoppers to create an account?

No. In a 2022 Baymard study of 4,384 US adults, 24% had abandoned one or more carts in the prior quarter solely because of forced account creation. Baymard’s key point is simple: allowing guest checkout is key to avoiding unnecessary abandonment.

Offering it is not enough, though. Baymard found that 47% of sites with guest checkout do not make it prominent enough. Its recommendations are specific:

• Label it clearly. Use the word “Guest”, as in “Guest Checkout”. Avoid vague labels such as “Continue”.
• Use a button, not a text link. Plain links are easy to miss, especially on mobile.
• Put it at the top of the account step, above the sign-in and registration options.
• Allow it for existing emails. Forcing sign-in sends shoppers into password resets.

Timing matters as much as the option. Baymard found that 42% of sites ask users to create an account at the start of checkout or before the order is placed, which distracts them from finishing. Its testing favoured asking at the confirmation step, where the order is complete and the benefits of an account can be listed. It suggests naming three to five of them.

When should a form validate input?

When the shopper has finished, and no earlier. Baymard reports that 31% of sites have no inline validation at all, so errors appear only after submitting. The opposite mistake is just as irritating: in its testing, participants were frustrated by errors that appeared before they had finished typing.

Baymard’s rules are easy to build:

1. Check most fields when the shopper leaves them.
2. Check fixed-length fields at the right length. This covers card numbers, security codes and postal codes.
3. Once a field is in error, check on every keystroke. Remove the message as soon as the input is valid, or shoppers may think a corrected entry is still wrong.

The wording matters as much as the timing. Baymard found that 98% of benchmarked sites use generic error messages. In testing, participants took up to five minutes to resolve simple errors because of vague wording, and some became completely stuck. At one UK retailer, a vague card payment error led a participant to suspect insufficient funds when the real issue was a minor entry error. “Your card number is incomplete” tells the shopper what to fix. For complex fields, Baymard suggests writing four to seven distinct messages.

Card numbers can be checked as they are typed with a Luhn check. Baymard notes that this catches format errors but cannot confirm a card is valid or funded, so it complements the provider’s checks and does not replace them.

How do you make autofill work?

Tell the browser what each field is. web.dev says the correct autocomplete values let browsers store card and address data securely and fill the fields for the shopper. Without them, shoppers may keep card details in insecure places of their own.

Data	autocomplete value
Full name	name
Address in one field	street-address
Address in separate lines	address-line1, address-line2
Card number	cc-number
Name on card	cc-name
Expiry in one field	cc-exp
Expiry in two fields	cc-exp-month, cc-exp-year
Security code	cc-csc

Three build details decide whether this works. Keep name and id values stable between page loads and deployments, which web.dev says helps browsers autofill. Avoid custom select elements for dates: web.dev shows a form where autofill completed every field except a custom expiry control. And test on real devices, because a form that autofills in one browser may fail in another.

Reducing typing was already Baymard’s mobile advice in 2013, when it recommended detecting and completing as much as possible, for example by asking for the postal code first and filling in the city and state. The advice is old, but typing on a phone is still slow.

How should the card fields behave?

Baymard’s summary is to make the card form match the physical card in the shopper’s hand as closely as possible. Its June 2026 standards article reports two common failures: 72% of sites do not detect the card type automatically, and 72% miss the two-digit format people expect for expiry dates.

Card number entry has its own rules. People read a card number in groups, so the field should show it that way.

• Allow spaces. Baymard says spaces should not trigger validation errors or be stripped from the displayed input. web.dev says the same, and suggests allowing for lengths from about 14 to 20 digits or more.
• Add spaces as the shopper types. Baymard says 16-digit cards such as Visa, Mastercard, Discover and JCB should get a space after every fourth digit. In 2019, 50% of sites failed to do this. Baymard now puts the figure at 15%.
• Handle American Express. These cards have 15 digits, grouped 4-6-5, and start with 34 or 37.
• Do not limit the characters allowed in the field. A hard limit can break valid cards.

The most damaging failure comes after an error. Baymard reports that 34% of sites do not keep card numbers when an error occurs, even if the error was in another field such as the phone number. In testing this directly caused abandonment, because participants refused to enter their details again. Its suggested fixes are to validate the other fields first, or to use the payment vendor’s secure tokens and handle errors without a full page reload.

A provider’s hosted fields or hosted checkout handle much of this for you. If you want your own checkout without card data on your servers, Omno Card Fields embed secure fields for card number, expiry and CVV in your page. If you plan to build card fields yourself, read about SAQ A for hosted checkouts first, since the choice changes your PCI DSS work.

Which keyboard should each mobile field open?

The one with the keys the shopper needs. Baymard’s 2013 testing found the touch keyboard covers close to 50% of the screen in portrait mode and 70% to 80% in landscape, so a wrong layout costs more than a tap. That testing is old, but the principle holds.

Field	Markup	What the shopper sees
Card number, security code	type="text" with inputmode="numeric"	Digits 0 to 9
Phone number	type="tel"	Telephone keypad, with asterisk and hash keys
Email	type="email"	Keyboard with the at sign to hand
Postal code	Numeric only where codes are digits	Digits, or a full keyboard in markets with letters

web.dev warns against type="number" for card and account numbers, because it adds up and down arrows that make no sense for a card number. MDN notes that inputmode changes the keyboard only and does not enforce validity, so you still need validation behind it. It also says devices vary in the keys they show, so test on real phones.

Two small fixes from the same Baymard article are still useful. Put labels above fields on mobile, because labels to the left leave a field too short to show what was typed. And turn off autocorrect where it does harm: in one test, a phone changed a street abbreviation into another word without the participant noticing.

What should a checkout form review check?

Run this list on a real phone, using a card of your own, in each main market.

1. Count the fields a guest must complete. Compare the total with Baymard’s figures of 11.3 on average and 8 for most sites.
2. Hide address line 2, coupon code and optional fields behind links.
3. Use one full name field, unless a provider needs the parts.
4. Make guest checkout a clear button at the top of the account step.
5. Move account creation to the confirmation step.
6. Validate when a field is finished, and clear errors as soon as they are fixed.
7. Replace generic errors with messages that say what to fix.
8. Add autocomplete values to every field, then test autofill.
9. Format card numbers as they are typed, including American Express.
10. Check that each field opens the right keyboard.
11. Trigger an error in another field and confirm the card details stay.

How does Omno help with checkout form design?

Omno’s hosted checkout has a no-code builder for layout, branding, categories, minimum and maximum amounts, routing and fields, so your team can change the form without a release. Custom field validation checks what customers enter, Omno forms ask for extra details only when a provider needs them, and card data never touches your servers. The hosted checkout page shows what can be configured.