| 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. | Use retry when a specific operation likely failed for a transient reason and the same operation can be attempted again without losing user context or duplicating side effects. | 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. | A generic Try again button appears after every error, including validation and permission failures users cannot fix by repeating the request. | A submitted application only redirects to a dashboard toast that says Done, with no reference, receipt, or next-step details. |
| Good UX | A user returns from bank authentication, sees the payment is processing, waits without retrying, and later sees the receipt once the provider reports success. | 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 user retries the same export after a network timeout, sees the attempt change to sending, and then returns to the recovered download state without re-entering filters. | 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 closes a hosted payment page and returns to a blank form with no way to check whether the payment was canceled or still pending. | A user cannot find guest checkout, creates an unwanted account, then abandons when email confirmation blocks payment. | 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. | The app retries aggressively every second during an outage and makes the service harder to recover. | A user closes the page after seeing a transient message and later cannot prove the payment or application happened. |
| 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 task is only secure card capture, bank-details entry, address entry, or a final answer review without purchase state. | 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. | 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. | Use an action label that names the operation, not only an icon or generic phrase. | Use one clear page H1 or panel title that communicates completion without relying on green color alone. |
| Common misuse | Showing a Pay button without amount, currency, or reference. | 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. |