Checkout

Problem Context

• The user has selected products, services, tickets, subscriptions, donations, or billable options and is ready to commit to payment or order placement.
• Checkout may need contact details, shipping or pickup address, delivery option, billing details, payment method, discounts, tax, fees, terms acceptance, inventory reservation, fraud checks, and receipts.
• Users compare total cost, delivery timing, trust signals, return policy, account requirements, and payment options while deciding whether to continue.
• Totals and availability can change when quantity, address, shipping speed, tax location, discount, inventory, or payment method changes.
• Checkout errors can have external effects such as payment authorization, inventory holds, duplicate orders, abandoned carts, or legal acceptance.

Selection Rules

• Choose checkout when the primary task is completing a purchase or order from selected items or priced services.
• Use payment card entry for secure card capture inside checkout; checkout owns when payment is requested, reviewed, authorized, retried, or confirmed.
• Use review before submit for the final editable summary, but add checkout-specific total, shipping, payment, inventory, discount, and terms details before the place-order action.
• Use step navigation only to communicate checkout progress; it must reflect actual validity of contact, delivery, payment, and review steps.
• Use address entry for shipping or billing address capture; checkout owns how address changes update delivery options, tax, fees, and order availability.
• Use confirmation page after the order is committed, not as a substitute for checkout review or payment processing state.
• Offer guest checkout unless account creation is required by the business or regulatory task, and defer account creation until after order placement when possible.
• Keep the order summary, item quantities, shipping cost, discounts, taxes, fees, and total due visible or easily reachable throughout checkout.
• Recalculate and explain total, delivery, tax, or inventory changes before the user places the order.
• Preserve cart, address, shipping, discount, and payment method context across validation errors, payment declines, authentication, redirects, refresh, and browser Back.
• Disable or guard duplicate place-order actions while payment authorization, inventory reservation, or order creation is in flight.
• Route success to a confirmation page with order number, receipt, delivery or pickup expectations, and next steps.

Required States

• Cart summary state with items, quantities, price, shipping, tax, discount, and total due.
• Guest or sign-in choice state that does not block purchase without a clear reason.
• Contact and receipt details state.
• Shipping or pickup address state with delivery eligibility and address-change effects.
• Delivery option state with cost, arrival estimate, unavailable option, and changed total.
• Discount or promotion state with applied, invalid, removed, and expired cases.
• Payment method state with secure card entry, wallet, saved payment, redirect, or alternate route.
• Final review state with charge amount, items, delivery, payment summary, terms, and explicit place-order action.
• Processing state that disables duplicate commit while keeping order reference and recovery context visible.
• Payment declined, authentication required, or authorization failed state with preserved checkout details.
• Inventory, price, or shipping changed state that requires acknowledgement before order placement.
• Abandoned or expired checkout recovery state.
• Order placed handoff state that routes to confirmation with receipt and next steps.

Interaction Contract

• Changing quantity, address, delivery method, discount, or payment route updates the order summary and total before commit.
• Users can move between checkout steps without losing valid entered data or hiding newly invalid dependent choices.
• The final action names the purchase consequence, such as Place order or Pay now, and is protected against duplicate activation.
• Payment errors preserve non-sensitive checkout context and return focus to the failing payment or recovery area.
• Shipping, tax, inventory, and price changes are shown near the affected order summary and must be acknowledged when they affect the final charge.
• Guest checkout, sign-in, wallet, payment redirect, and browser Back return to the same checkout context unless security policy requires a fresh start.
• Successful order creation removes editable checkout controls and hands off to a confirmation page.

Implementation Checklist

• Define checkout ownership for cart state, customer identity, guest rules, addresses, delivery, tax, discounts, payment authorization, inventory holds, order creation, receipts, and post-order account creation.
• Design cart summary, guest choice, contact, shipping, delivery, discount, payment, review, processing, decline, changed-total, expired-session, and confirmation handoff states.
• Bind checkout totals to canonical pricing, tax, shipping, discount, and inventory services rather than duplicating calculations only in the browser.
• Use secure payment components or redirects for payment credentials and keep checkout state resumable after authentication or payment-provider returns.
• Use idempotency, duplicate-submit guards, and clear processing states for place-order, payment authorization, and order creation requests.
• Preserve safe checkout data through validation, payment decline, refresh, browser Back, and session timeout while redacting payment secrets.
• Explain final total changes, unavailable items, expired discounts, address-dependent tax or shipping changes, and delivery promise changes before commit.
• Test guest checkout, forced sign-in exceptions, mobile viewport, long order summaries, address changes, delivery changes, discount failure, card decline, wallet cancel, redirect return, duplicate tap, inventory change, abandoned cart return, screen readers, and high zoom.

Common Generated-UI Mistakes

• Forcing account creation before purchase when guest checkout would work.
• Hiding shipping, tax, fees, or total until after payment details are entered.
• Letting totals change after payment capture without a visible review or acknowledgement.
• Clearing the cart, address, discount, or delivery choice after a payment decline.
• Treating all checkout failures as one vague checkout failed message.
• Leaving Place order enabled while authorization or order creation is already running.
• Using step labels that imply payment or shipping is complete before required dependencies are valid.
• Showing a confirmation page before payment, inventory, or order creation is actually committed.

Critique Questions

• What exactly is committed when the user presses the final checkout action?
• Can the user see the current total, shipping cost, taxes, discounts, delivery promise, and payment state before commit?
• Which checkout changes can alter the final charge, delivery eligibility, or inventory state?
• Does guest checkout remain available unless there is a specific reason to require an account?
• How are payment decline, authentication, redirect cancel, duplicate submit, inventory change, and expired session recovered without losing the order?
• Where does checkout stop and the post-order confirmation page begin?