UX Patterns Guide
Back to compare picker

Bank details vs Text input vs Input mask vs Review before submit

Prefer bank details when the service must store or verify account holder name, bank or building society account number, routing information such as sort code, and any roll number or regional equivalent.

Bank details live exampleText input live exampleInput mask live exampleReview before submit live example

Decision dimensions

Dimension Bank detailsText inputInput maskReview before submit
UI or UX UI + UX - Secure bank account identification and verification formUI + UX - Single-line freeform data-entry controlUI + UX - Fixed-format text entry controlUI + UX - Final editable answer summary before committing a transaction
UI guidance Render bank details as a secure grouped form with account holder name, routing identifier, account number, optional roll number or regional equivalent, clear hints, field-specific errors, verification status, and a masked review summary.Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.
UX guidance Use bank details when the service needs an account to pay a user, collect a direct debit, issue a refund, run payroll, initiate a bank payment, or save a payout destination.Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.
Good UI A refund form asks for Name on the account, Sort code, Account number, and Building society roll number (optional), then shows a masked summary before Confirm payout.A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.
Bad UI A form has one field labelled Bank details and asks users to paste name, account number, sort code, and notes together.The only instruction is placeholder text that disappears when the user starts typing.A phone field hard-codes a domestic mask and rejects valid international numbers.A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.
Good UX A user types a sort code with spaces, the form normalizes it to 12-34-56, checks the account holder name, warns about a close match, and lets the user review before payout.A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.
Bad UX A user mistypes one digit and the service silently accepts the account, then the payment fails days later with no field-level recovery.Validation fires on the first focus event and blocks typing before the user has had a chance to answer.A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.
Best fit The product needs bank account details to send money, collect money, set up payroll, save payout details, issue refunds, or initiate bank-to-bank payments.The answer is short and user-authored.The value has a stable character pattern and users benefit from live grouping.A user has provided multiple answers and should verify them before a consequential submit action.
Avoid when The task is to collect payment card credentials rather than bank account identifiers.The answer is a paragraph, comment, address block, or explanation requiring multiple lines.Valid values have many lengths, regions, scripts, or exception formats.The task is a single low-risk field with clear inline validation and an obvious submit action.
Required state Initial secure collection state with purpose, account holder name, routing field, account number, optional roll number or regional equivalent, and hints.Empty untouched state with persistent label and optional hint.Empty untouched state with label and visible format example.Initial review state with grouped captured answers, relevant sections, and explicit submit action.
Accessibility burden Group account fields under a heading or legend that explains why bank details are being requested.Associate every text input with a visible label or equivalent accessible name that matches the visible question.Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.Use headings that make the review task explicit, such as Check your answers before sending your application.
Common misuse Using one freeform field for all account details.Using placeholder text as the only label or instruction.Using a mask because a format exists even though many valid values do not fit it.Using a review page that contains no captured answers.

Bank details

UI or UX
UI + UX - Secure bank account identification and verification form
UI guidance
Render bank details as a secure grouped form with account holder name, routing identifier, account number, optional roll number or regional equivalent, clear hints, field-specific errors, verification status, and a masked review summary.
UX guidance
Use bank details when the service needs an account to pay a user, collect a direct debit, issue a refund, run payroll, initiate a bank payment, or save a payout destination.
Good UI
A refund form asks for Name on the account, Sort code, Account number, and Building society roll number (optional), then shows a masked summary before Confirm payout.
Bad UI
A form has one field labelled Bank details and asks users to paste name, account number, sort code, and notes together.
Good UX
A user types a sort code with spaces, the form normalizes it to 12-34-56, checks the account holder name, warns about a close match, and lets the user review before payout.
Bad UX
A user mistypes one digit and the service silently accepts the account, then the payment fails days later with no field-level recovery.
Best fit
The product needs bank account details to send money, collect money, set up payroll, save payout details, issue refunds, or initiate bank-to-bank payments.
Avoid when
The task is to collect payment card credentials rather than bank account identifiers.
Required state
Initial secure collection state with purpose, account holder name, routing field, account number, optional roll number or regional equivalent, and hints.
Accessibility burden
Group account fields under a heading or legend that explains why bank details are being requested.
Common misuse
Using one freeform field for all account details.

Text input

UI or UX
UI + UX - Single-line freeform data-entry control
UI guidance
Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance
Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
Good UI
A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI
The only instruction is placeholder text that disappears when the user starts typing.
Good UX
A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX
Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit
The answer is short and user-authored.
Avoid when
The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state
Empty untouched state with persistent label and optional hint.
Accessibility burden
Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse
Using placeholder text as the only label or instruction.

Input mask

UI or UX
UI + UX - Fixed-format text entry control
UI guidance
Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.
UX guidance
Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.
Good UI
A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.
Bad UI
A phone field hard-codes a domestic mask and rejects valid international numbers.
Good UX
A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.
Bad UX
A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.
Best fit
The value has a stable character pattern and users benefit from live grouping.
Avoid when
Valid values have many lengths, regions, scripts, or exception formats.
Required state
Empty untouched state with label and visible format example.
Accessibility burden
Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.
Common misuse
Using a mask because a format exists even though many valid values do not fit it.

Review before submit

UI or UX
UI + UX - Final editable answer summary before committing a transaction
UI guidance
Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.
UX guidance
Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.
Good UI
A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.
Bad UI
A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.
Good UX
A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.
Bad UX
A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.
Best fit
A user has provided multiple answers and should verify them before a consequential submit action.
Avoid when
The task is a single low-risk field with clear inline validation and an obvious submit action.
Required state
Initial review state with grouped captured answers, relevant sections, and explicit submit action.
Accessibility burden
Use headings that make the review task explicit, such as Check your answers before sending your application.
Common misuse
Using a review page that contains no captured answers.
Decision rules
  • Prefer bank details when the service must store or verify account holder name, bank or building society account number, routing information such as sort code, and any roll number or regional equivalent.
  • Prefer text input only for a single non-financial short answer, such as a payment reference label, because bank-account capture requires multiple fields, validation, privacy handling, and review.
  • Prefer input mask only for display grouping or paste cleanup inside one bank-detail field; the mask does not own account holder name, roll-number optionality, account validation, or verification outcomes.
  • Prefer review before submit after bank details have been captured when users need to confirm masked or partially shown details before a payout, debit, refund, or payroll update is committed.
  • Collect bank details securely inside the product flow; do not move bank account collection into email, chat, attachments, or other unstructured channels.
  • Do not ask users to classify bank versus building society accounts when the product can ask for the fields it needs and make roll number optional unless the user has one.
  • Use field-specific validation for sort code, account number, routing number, roll number, and account holder name rather than reporting only Payment failed after submit.
  • Where account validation or Confirmation of Payee is available, present match, close match, no match, pending, and override states as user-reviewable outcomes rather than silent corrections.
  • For ACH, direct debit, or open-banking flows, distinguish manual account details from bank-login or account-selection flows and provide fallback or pending verification states when instant verification is unavailable.
  • Mask or summarize stored bank details on later pages, but keep enough recognizable information for users to detect a wrong account before money moves.
Inspect live examples
Bank detailsText inputInput maskReview before submit
Failure modes
  • A payout form uses one generic Account field, so the account number, sort code, roll number, and holder name cannot be validated or reviewed separately.
  • A mask inserts separators but silently stores a different account number, making users unable to check what will be paid.
  • A form asks whether the user has a bank or building society account and users choose the wrong path because they do not know the classification.
  • A service collects bank details by email or attachment, exposing sensitive account information outside the controlled product flow.
  • Account validation returns a close match or pending micro-deposit state but the UI still shows the details as fully verified.
  • A review page hides every digit of the account number, so users cannot detect that the wrong account was captured.