Use payment collection when a service must collect or reconcile a payment amount through one or more payment methods and lifecycle states; use checkout for purchase order finalization, payment card entry for secure card credential capture, and bank details for account identifier capture or verification.
Use payment collection when a service must collect or reconcile a payment amount through one or more payment methods and lifecycle states; use checkout for purchase order finalization, payment card entry for secure card credential capture, and bank details for account identifier capture or verification.
Practice the judgment: Imagine this situation: The same payment reference can be submitted twice and creates duplicate charges. 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 →| Dimension | Payment collection | Checkout | Payment card entry | Bank details | Retry | Confirmation page |
|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Payment request, authorization, and status lifecycle | UI + UX - Purchase commitment and order finalization flow | UI + UX - Secure card payment capture and verification form | UI + UX - Secure bank account identification and verification form | UI + UX - Scoped failed-operation retry control | UI + UX - Final endpoint page after a transaction is complete |
| UI guidance | Render payment collection as a money-movement journey with amount due, reference, payer or service context, accepted methods, provider handoff, authorization or processing state, failure and cancel recovery, retry rules, receipt, and reconciliation status. | Render checkout as a purchase commitment flow with order summary, customer contact, shipping or pickup choice, payment handoff, discount and tax state, total due, review, place-order action, payment processing, and confirmation handoff. | 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. | Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization. | Render a full page after commit with a prominent completion panel, a page heading that names what finished, a reference or receipt when users need one, and a clear section for what happens next. |
| UX guidance | Use payment collection when the user must pay a bill, fee, invoice, application charge, renewal, subscription, donation, deposit, or balance and the service must make the amount, reference, status, and next action unambiguous. | Use checkout when a user is ready to turn selected items, services, tickets, or subscriptions into a committed order and needs confidence about total cost, delivery, payment, and recovery before placing the order. | 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. | Help the person reach a clear task outcome. | Use a confirmation page when the transaction or service journey has ended and users need durable proof, reassurance, next-step timing, or a record they can bookmark, print, quote, or revisit. |
| Good UI | A permit-fee payment page shows Reference APP-2048, Amount due $84.00, accepted card and wallet methods, Continue to secure payment, and returns to a status page after provider authorization. | A checkout shows cart items, shipping address, delivery options, taxes, discount, total, payment state, and a Place order button that disables while authorization is pending. | 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 report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048. | A grant application page says Application complete, shows reference APP-48291, lists what happens next within 5 working days, and offers Save record, Track application, and feedback links. |
| Bad UI | A page says Payment failed after redirect but hides whether the bank declined, the user canceled, the session expired, or money might still be pending. | A checkout hides shipping costs until after card entry and changes the total at the last moment. | 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. | Retry creates duplicate records, payments, invitations, exports, or queued jobs. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. |
| Good UX | The person reaches the intended result with clear feedback. | A user changes shipping speed, sees delivery date and total update in the sticky order summary, reviews the final charge, places the order once, and lands on a confirmation page with an order number. | 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 second failure increases the wait before the next attempt and then offers cached export, background notification, or support reference after attempts are exhausted. | A user copies the reference, saves the receipt, follows Track application, and later returns from a bookmark to the same confirmation details or a helpful tracking fallback. |
| Bad UX | A user pays the same invoice twice because retry generated a second reference instead of reusing a duplicate-safe payment attempt. | A user taps Place order twice during a slow authorization and receives two duplicate orders. | Full card details leak into application state, logs, analytics, replay tools, screenshots, or support transcripts. | A form rejects a pasted sort code with dashes even though the digits are valid and the user is copying from their bank. | The app retries aggressively every second during an outage and makes the service harder to recover. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. |
| Best fit | The user must pay a known fee, invoice, balance, application charge, renewal, subscription, donation, deposit, or service amount. | A user is ready to purchase selected items, services, tickets, subscriptions, donations, or orderable options. | 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. | A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason. | A transaction or service journey has ended and users need durable proof plus next-step information. |
| Avoid when | The task is a full ecommerce checkout with cart, shipping, tax, discounts, and order finalization. | The user has already placed the order and needs a confirmation page, receipt, or post-purchase management. | 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. | The error is caused by invalid user input and correction is required. | The user remains inside an ongoing task and only needs local proof near the changed object. |
| Required state | Payment request state with amount, currency, reference, description, payer context, accepted methods, and secure provider handoff. | Cart summary state with items, quantities, price, shipping, tax, discount, and total due. | 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. | Retryable failed state with affected operation, object, and preserved request context. | Submitted state immediately after authoritative commit routes to the confirmation page. |
| Accessibility burden | Use headings that name the payment task and amount, such as Pay application fee or Pay invoice INV-1482. | Use headings that expose the current checkout task and step, such as Delivery, Payment, or Review order. | Expose input purpose with autocomplete tokens and keep helper text connected to inputs or hosted-field containers. | Group account fields under a heading or legend that explains why bank details are being requested. | Expose pending, failed again, cooldown, succeeded, exhausted, and non-retryable outcomes through status text or live regions. | Keep interactive controls out of low-contrast panel treatments unless focus and text contrast are explicitly verified. |
| Common misuse | Letting users submit the same payment twice while the first attempt is processing. | Forcing account creation before purchase when guest checkout would work. | Using one multiline field for card number, expiry, CVC, and billing details. | Using one freeform field for all account details. | Offering Retry for every error regardless of whether the user or system state can change. | Showing a toast or local success strip as the only proof of a completed transaction. |