UX Patterns Guide
Back to compare picker

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

Use bank details when a product must capture account-identification parts for payout, debit, refund, payroll, or payment initiation; use text input for ordinary short values, input mask for formatting a stable field, and review before submit for final verification after capture.

Bank details live exampleText input live exampleInput mask live exampleReview before submit live example
Learn the decision

Match the interaction to the person's task

Use bank details when a product must capture account-identification parts for payout, debit, refund, payroll, or payment initiation; use text input for ordinary short values, input mask for formatting a stable field, and review before submit for final verification after capture.

Bank details

Use it when: 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.

Make this state clear: Initial secure collection state with purpose, account holder name, routing field, account number, optional roll number or regional equivalent, and hints.

Observe the result: 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.

Study the full pattern →

Text input

Use it when: The answer is short and user-authored.

Make this state clear: Empty untouched state with persistent label and optional hint.

Observe the result: A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.

Study the full pattern →

Input mask

Use it when: The value has a stable character pattern and users benefit from live grouping.

Make this state clear: Empty untouched state with label and visible format example.

Observe the result: A user submits ABCD 123 and receives a precise error that the six-digit serial group and check digit are incomplete.

Study the full pattern →

Review before submit

Use it when: A user has provided multiple answers and should verify them before a consequential submit action.

Make this state clear: Initial review state with grouped captured answers, relevant sections, and explicit submit action.

Observe the result: 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.

Study the full pattern →

Practice the judgment: Imagine this situation: A mask inserts separators but silently stores a different account number, making users unable to check what will be paid. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

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.Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.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.Change links lack context, so assistive technology users hear a list of identical 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 leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.A user submits ABCD 123 and receives a precise error that the six-digit serial group and check digit are incomplete.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 form rejects a pasted sort code with dashes even though the digits are valid and the user is copying from their bank.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.Connect hint, format example, canonical-value note, and error text to the input with descriptive relationships where supported.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.Rejecting pasted values that include spaces, dashes, parentheses, or lowercase characters.Labelling the final commit button Continue.

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 form rejects a pasted sort code with dashes even though the digits are valid and the user is copying from their bank.
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
Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.
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 leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.
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 submits ABCD 123 and receives a precise error that the six-digit serial group and check digit are incomplete.
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
Connect hint, format example, canonical-value note, and error text to the input with descriptive relationships where supported.
Common misuse
Rejecting pasted values that include spaces, dashes, parentheses, or lowercase characters.

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
Change links lack context, so assistive technology users hear a list of identical 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
Labelling the final commit button Continue.
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.

Saved items