A checkout asks for a postcode. The mobile keyboard has letters, so someone changes the field to type="number". The keypad looks more convenient. The implementation now treats a delivery identifier as a quantity.
That distinction matters beyond the screen. A leading zero can survive typing and disappear when an application converts the value to an integer. A postcode containing letters may be rejected before the buyer reaches delivery options. A cleaner-looking form can still collect the wrong data.
Start with what the value means. Then specify the keyboard, autofill behavior and validation separately. These decisions belong in the same field specification, but they solve different problems.
Four decisions hiding inside one input
The HTML type defines the kind of control. inputmode suggests a virtual keyboard. autocomplete describes the information the browser may help fill. Validation decides which submitted values the business can accept.
A numeric keyboard does not establish that a value is valid. MDN explicitly describes inputmode as a hint without validity requirements. Keyboard layouts also vary, so a design review should describe the intended characters rather than promise an identical keypad on every phone.
For identifiers, the HTML specification offers a useful test: would incrementing the value with a spinbox make sense? Quantity often passes. A card number or postal code does not. Digits alone are insufficient reason to use a number input.
The team should be able to answer four questions for each field: What does it represent? Which characters must the buyer enter? Can saved information help? What makes the value acceptable for this particular transaction?
A field reference for checkout decisions
| Field | Meaning | Starting point | Decision that still needs care |
|---|---|---|---|
| Quantity | An amount to increase or decrease | Numeric control with appropriate minimum and step | Whether fractional quantities are actually sold |
| Postal code | A delivery identifier | Text control; country-aware keyboard choice | Countries served, letters, spaces and optional formats |
| Telephone | A contact identifier | Telephone input with suitable autofill purpose | International prefixes and the actual contact requirement |
| Membership or collection code | An identifier | Text control; numeric input mode only if digits are guaranteed | Leading zeros, length and case sensitivity |
| Payment card details | Payment credentials | The payment provider’s supported collection component | Integration behavior, supported methods and error recovery |
This is a starting point for a field specification, not a universal form recipe. A quantity of fabric may allow fractions. A membership code may change from digits to letters next year. Document those assumptions where both design and engineering can see them.
For payment details, changing ordinary form attributes is not a substitute for following the payment integration. Stripe, for example, provides a Payment Element that works alongside its address and express-checkout components. Review the provider’s component and supported configuration before creating custom fields that collect card information.
A leading zero is part of the value
Consider the illustrative identifier 00501. A string round trip preserves 00501; converting it to an integer produces 501. The difference is not cosmetic when another system expects the original identifier.
The same problem appears with a fictional collection code, 000123. A successful keyboard check cannot tell you whether the API serializer, database column or export will keep its six characters.
Use a small preservation check that follows the value through the full journey:
- Enter the identifier manually and with autofill where applicable.
- Inspect the submitted value before any normalization.
- Read back the stored value through the normal application path.
- Reopen the form and confirm the buyer sees the same identifier.
Treat normalization as an explicit rule. Removing an accidental trailing space may be appropriate for a particular identifier; removing every space, punctuation mark or leading zero needs a reason. Preserve the original where the operational process requires it, and make transformations visible to the team responsible for delivery or fulfillment.
This check concerns ordinary checkout identifiers. Do not put real payment credentials into debugging logs to perform it.
Postal codes need a country decision
A general international postal-code field should not assume digits only. If the checkout supports several countries, the country selection and address requirements need to agree before the application chooses a restrictive keyboard or validation rule.
For an ordinary international address form, a simple starting point is:
<label for="postal-code">Postal code</label>
<input
id="postal-code"
name="postal-code"
type="text"
autocomplete="shipping postal-code"
>This example intentionally leaves country-specific validation to the application’s address rules. It does not demonstrate a complete address form or prove that every destination requires a postal code.
The shipping token helps distinguish this field from a billing postal code. MDN documents these autocomplete groupings; use the purpose that matches the information being requested.
If address lookup is available, provide a usable route when it fails or cannot cover the destination. The GOV.UK address pattern separates UK lookup guidance from international entry and recommends a manual option for forms accepting both. The useful design lesson is to make the fallback part of the address journey, with entered details preserved.
Test correction, not just successful entry
A field can work perfectly when the buyer types the expected value once. Checkout is less tidy. Someone pastes a telephone number with spaces, changes the delivery country, selects the wrong saved address or returns after a payment error.
Build the review around those transitions. After changing country, can the buyer still correct the postal code? After an error, does the form preserve the other fields? Can a buyer paste a permitted value instead of retyping it? Does the error identify the exact field and explain the accepted format without erasing the entry?
Include at least one physical phone from each mobile platform important to your audience, plus the browsers you support. Record the actual keyboard and correction behavior. A desktop device emulator is useful for layout, but it does not settle how a real mobile keyboard, saved address or password manager behaves.
Write an acceptance condition the team can verify
“Use the right keyboard” is too vague to close the task. A better condition names the field and its boundary: “The collection code accepts six digits, retains leading zeros through submission and redisplay, allows paste, and explains an invalid length without clearing the value.”
For an address, name the supported destinations and test cases. For a phone number, explain why it is needed and which formats the receiving service accepts. For payment fields, verify the supported provider flow, including a declined payment and a return to correction.
Then review the field within the whole checkout. Fewer keyboard switches are useful only if the buyer can still enter accurate information and complete the purchase. The final check is a recoverable transaction with intact data.