Use checkout for the end-to-end purchase commitment flow that coordinates cart summary, customer details, delivery, payment handoff, review, place-order action, error recovery, and confirmation; use payment card entry for secure card capture, review before submit for a final editable gate, and step navigation for progress display across a longer flow.
Use checkout for the end-to-end purchase commitment flow that coordinates cart summary, customer details, delivery, payment handoff, review, place-order action, error recovery, and confirmation; use payment card entry for secure card capture, review before submit for a final editable gate, and step navigation for progress display across a longer flow.
Practice the judgment: Imagine this situation: The user is forced to create an account before purchase even though guest checkout would satisfy order needs. 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 | Checkout | Payment card entry | Review before submit | Step navigation / step indicator | Address entry | Confirmation page |
|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Purchase commitment and order finalization flow | UI + UX - Secure card payment capture and verification form | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Linear multistep task progress indicator | UI + UX - Structured postal or contact address capture flow | UI + UX - Final endpoint page after a transaction is complete |
| UI guidance | 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 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. | Show a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states. | Render address capture as a labelled fieldset or page section with address line, locality, region when needed, postal code, country, and an address lookup only when its coverage is clear. | 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 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 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. | Use step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains. | Use address entry when the service needs a complete address for delivery, billing, correspondence, identity, eligibility, routing, tax, or account records and downstream systems need reliable address parts. | 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 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 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. | A five-step application shows Eligibility complete, Contact details current, Documents upcoming, Review upcoming, and Submit upcoming, with the current step emphasized and a matching page heading. | A benefits claim asks for postcode lookup, lists matching addresses, includes Enter address manually, and then shows editable address line 1, address line 2, town or city, postcode, and country. | 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 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. | Change links lack context, so assistive technology users hear a list of identical Change links. | All future steps look clickable and complete even though required earlier fields are blank. | A selected address is stored as a provider label rather than structured parts. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. |
| Good UX | 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 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. | After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current. | A user enters SW1A1AA, sees several addresses, selects Flat 2, adds an organization name, and reviews the stored line, town, postcode, and country parts before continuing. | 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 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 user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | The indicator says Step 4 of 5 while the page content and route still show Step 2. | A checkout removes Apartment 4B after validation and the parcel is delivered to the wrong household. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. |
| Best fit | 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. | A user has provided multiple answers and should verify them before a consequential submit action. | A linear form, application, checkout, or setup flow has three or more meaningful steps. | The product needs a complete postal, delivery, billing, service, or official contact address. | A transaction or service journey has ended and users need durable proof plus next-step information. |
| Avoid when | 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 a single low-risk field with clear inline validation and an obvious submit action. | The journey has only one or two screens. | The product only needs one short location label, room name, or delivery note. | The user remains inside an ongoing task and only needs local proof near the changed object. |
| Required state | 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 review state with grouped captured answers, relevant sections, and explicit submit action. | Default state with completed, current, and upcoming steps. | Initial state with country or domestic coverage explained and lookup or manual entry available. | Submitted state immediately after authoritative commit routes to the confirmation page. |
| Accessibility burden | 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. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states. | Group related address fields with a clear heading or legend that states which address is being requested. | Keep interactive controls out of low-contrast panel treatments unless focus and text contrast are explicitly verified. |
| Common misuse | Forcing account creation before purchase when guest checkout would work. | Using one multiline field for card number, expiry, CVC, and billing details. | Labelling the final commit button Continue. | Using a step indicator as breadcrumbs, tabs, side navigation, or pagination. | Forcing every address through a domestic postcode or ZIP lookup. | Showing a toast or local success strip as the only proof of a completed transaction. |