UX Patterns Guide
Back to compare picker

Payment card entry vs Bank details vs Input mask vs Review before submit

Prefer payment card entry when the user is paying by card and the flow needs card number, expiry, CVC or CID, billing postal code, supported brand detection, processor tokenization, wallet fallback, and card-specific decline or authentication recovery.

Payment card entry live exampleBank details live exampleInput mask live exampleReview before submit live example

Decision dimensions

Dimension Payment card entryBank detailsInput maskReview before submit
UI or UX UI + UX - Secure card payment capture and verification formUI + UX - Secure bank account identification and verification formUI + UX - Fixed-format text entry controlUI + UX - Final editable answer summary before committing a transaction
UI guidance Render card entry as a secure grouped checkout surface with processor-hosted or payment-element fields for card number, expiry, CVC or CID, billing postal code when required, clear labels, card brand feedback, field errors, wallet options, and a masked review summary.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.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 payment card entry when a user needs to pay with a card or add a card-on-file payment method and the product can protect cardholder data through a payment processor or compliant card-data environment.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 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 checkout uses hosted fields for Card number, Expiry, CVC, and ZIP code; it detects Visa, accepts pasted spaces, validates expiry, tokenizes the card, and reviews Visa ending 4242 before charge.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 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 page asks users to paste card number, expiry, CVC, and billing address into one notes field.A form has one field labelled Bank details and asks users to paste name, account number, sort code, and notes together.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 pastes 4242 4242 4242 4242, sees Visa detected, enters 12/30 and 123, tokenizes the card, and reviews Visa ending 4242 before paying.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 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 enters an expired card and receives only Payment failed after submit with no field-level route back to expiry.A user mistypes one digit and the service silently accepts the account, then the payment fails days later with no field-level recovery.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 Users need to pay with a credit, debit, prepaid, or network card.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 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 bank account identifiers for payout, ACH, direct debit, open banking, or bank transfer.The task is to collect payment card credentials rather than bank account identifiers.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 checkout state with amount, accepted card brands, wallet option, card number, expiry, CVC or CID, and billing postal code if required.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 label and visible format example.Initial review state with grouped captured answers, relevant sections, and explicit submit action.
Accessibility burden Use visible labels for card number, expiry, CVC or CID, cardholder name, and billing postal code; do not rely on placeholder examples alone.Group account fields under a heading or legend that explains why bank details are being requested.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 multiline field for card number, expiry, CVC, and billing details.Using one freeform field for all account details.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.

Payment card entry

UI or UX
UI + UX - Secure card payment capture and verification form
UI guidance
Render card entry as a secure grouped checkout surface with processor-hosted or payment-element fields for card number, expiry, CVC or CID, billing postal code when required, clear labels, card brand feedback, field errors, wallet options, and a masked review summary.
UX guidance
Use payment card entry when a user needs to pay with a card or add a card-on-file payment method and the product can protect cardholder data through a payment processor or compliant card-data environment.
Good UI
A checkout uses hosted fields for Card number, Expiry, CVC, and ZIP code; it detects Visa, accepts pasted spaces, validates expiry, tokenizes the card, and reviews Visa ending 4242 before charge.
Bad UI
A page asks users to paste card number, expiry, CVC, and billing address into one notes field.
Good UX
A user pastes 4242 4242 4242 4242, sees Visa detected, enters 12/30 and 123, tokenizes the card, and reviews Visa ending 4242 before paying.
Bad UX
A user enters an expired card and receives only Payment failed after submit with no field-level route back to expiry.
Best fit
Users need to pay with a credit, debit, prepaid, or network card.
Avoid when
The task is to collect bank account identifiers for payout, ACH, direct debit, open banking, or bank transfer.
Required state
Initial secure checkout state with amount, accepted card brands, wallet option, card number, expiry, CVC or CID, and billing postal code if required.
Accessibility burden
Use visible labels for card number, expiry, CVC or CID, cardholder name, and billing postal code; do not rely on placeholder examples alone.
Common misuse
Using one multiline field for card number, expiry, CVC, and billing details.

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.

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 payment card entry when the user is paying by card and the flow needs card number, expiry, CVC or CID, billing postal code, supported brand detection, processor tokenization, wallet fallback, and card-specific decline or authentication recovery.
  • Prefer bank details when the product needs routing and account identifiers for payout, debit, refund, payroll, or account-to-account payment; do not reuse card-entry fields for sort codes, routing numbers, account numbers, IBANs, or roll numbers.
  • Prefer input mask only for local grouping inside card number or expiry fields; a mask does not own card brand rules, Luhn checks, variable PAN length, CVC length by brand, billing postal code checks, PCI handling, tokenization, or payment outcome states.
  • Prefer review before submit after the processor has accepted or tokenized the card details when users need to confirm the amount, card brand, last four digits, billing address, and terms before the charge is placed.
  • Use hosted fields, a payment element, or another processor-controlled capture surface for primary account number and CVC whenever possible so raw card data does not pass through product logs, analytics, support tools, or application servers.
  • Keep CVC collection transient: ask for it only when needed to authorize or verify the card and never show it on review, receipts, saved-payment lists, or later card-on-file screens.
  • Support pasted card numbers with spaces or hyphens, browser autofill tokens, mobile numeric keyboards, and wallet options, while keeping a manual card fallback for users who cannot use a wallet.
  • Validate card number format and checksum, expiry month and year, CVC or CID length, billing postal code where required, and unsupported brands before attempting the charge.
  • Show processor outcomes distinctly: invalid field, unsupported brand, requires authentication, declined, processing, tokenized, and succeeded should not collapse into a single payment failed message.
  • On review and saved states, show only brand, last four digits, expiry when safe to show, token or payment method status, and billing details needed for recognition; never redisplay the full PAN or CVC.
Inspect live examples
Payment card entryBank detailsInput maskReview before submit
Failure modes
  • A checkout asks for all card details in a textarea, so the full PAN and CVC can be copied into logs, support tickets, or browser history.
  • A rigid mask assumes every card has sixteen digits and rejects variable-length cards or different CVC lengths.
  • The page formats a card number but never detects unsupported brands, expired cards, bad CVC length, postal-code requirements, processor declines, or required authentication.
  • A saved-card review screen shows the full card number or CVC instead of a masked brand and last-four summary.
  • A wallet button replaces manual card entry entirely and blocks users whose device, browser, account, or payment method cannot use that wallet.
  • The final confirmation hides the amount, card ending, billing country, or terms, so users cannot detect that the wrong card or payment path will be charged.