Checkout as a guest
Guest checkout is a conditional experience. The choices and fields that appear can depend on the app, order type, checkout context, payment option, and other requirements for the current order.
:::warning Important boundary
Selecting Continue as guest only opens the guest customer-details state in the current checkout. It does not create an account, place an order, transfer guest data, or confirm payment.
:::
Guest choices are separate
When the current checkout allows it, a guest customer may see these choices:
| Choice | What it changes | What it does not prove |
|---|---|---|
| Log in | Starts the separate account sign-in journey | That guest data moved, or that checkout completed |
| Sign up | Starts the separate account-creation journey | That an account or session was accepted |
| Continue as guest | Locally reveals the guest customer-details step | That a guest account, order, or payment exists |
The app can omit Continue as guest even when another surface previously showed a guest choice. Treat the checkout currently on screen as the relevant availability signal.
Availability has several layers
Guest checkout is not one universal switch. Its visible and usable state can depend on distinct layers:
| Layer | Possible effect on the experience |
|---|---|
| App and project policy | Guest choices may be shown or hidden |
| Current order type | Guest checkout may be allowed for some types but not others |
| Entry surface | Home and Checkout can apply different readiness checks |
| Customer details | Required identity or contact fields can vary |
| Address and fulfillment | Delivery, pickup, location, or reservation requirements can differ |
| Payment option | A payment choice can require account conversion before placement |
| School context | A separate authorized student selection can be required |
Seeing one eligible layer does not prove that all later layers are eligible.
Guest identity and account conversion
A guest session uses a sensitive guest capability to associate current state. Do not copy, share, log, or treat that capability as an ordinary customer identifier.
Any guest account and session already present at Checkout was established by a separate guest-entry process. The local Continue as guest choice does not repeat or confirm that process.
Creating an account, logging in, or completing a social sign-in while a guest can start a separate conversion and transfer boundary. Address, cart, grouped cart, and order state must remain unresolved until the new authorized session shows a reconciled result. Do not assume that every item was preserved, moved, or removed because an account screen closed or navigation changed.
Checkout requirements remain separate
| State | Customer-safe interpretation |
|---|---|
| Identity fields shown | The current checkout is requesting details; acceptance is not yet known |
| Address section shown | Address and fulfillment validation remain separate from guest eligibility |
| Payment choice shown | Availability is not authorization, payment, or order placement |
| Account prompt after payment selection | That payment path may not support the current guest state |
| Student selection shown | School authorization and selection must settle separately |
| Place action unavailable | At least one current checkout requirement is unresolved |
Required fields and validation can change after the order type, business, payment choice, account state, or project changes.
Conversion and placement are different outcomes
Account or provider success can return control to checkout and may immediately continue a pending placement attempt in some source paths. Those are still separate outcomes. Account acceptance does not prove guest-data transfer, payment settlement, order creation, or current order status.
If the result of conversion, payment, or placement is unclear, do not submit again based only on a closed modal, changed button, spinner, toast, or navigation. First obtain a reconciled current state from the normal account, cart, and order surfaces.
Interpret partial and unknown outcomes
| Observed state | Safe interpretation |
|---|---|
| Guest details opened | Local entry only |
| Account screen opened | Account request has not necessarily been sent or accepted |
| Account screen closed | Account, session, and guest transfer can still differ |
| Payment handoff returned | Provider, payment, cart, and order can still differ |
| Loading stopped with no result | Outcome is unknown |
| Cart changed after conversion | Reconcile the current cart and account before continuing |
| Order view appears | Confirm the current authorized order state; navigation alone is not a receipt |
Troubleshooting safely
| What you observe | Safe next check |
|---|---|
| Continue as guest is absent | Confirm the current order type and use an available account choice; do not infer a fault |
| Guest fields do not appear | Return to the current checkout summary and confirm that the guest choice is still available |
| A required field changes | Recheck the current fulfillment, business, and customer-detail requirements |
| A payment choice asks for an account | Treat that option as unavailable to the current guest state unless conversion settles |
| Conversion closes without a clear result | Check the current account and cart state before any further action |
| Placement has no clear result | Treat the order outcome as unknown and use the normal order-status surface |
| The app or project changed | Treat prior guest and provider results as stale; rely only on the cart shown for the current project |
Support reports should use only a value-free state class such as “guest conversion unresolved.” Do not include timing, contact details, payment information, codes, guest capabilities, account/cart/order identifiers, or private screenshots.
Privacy and accessibility
- Enter personal or payment information only in the app's current authorized form. Never send it through a support report.
- Guest mode is not anonymous to the systems needed to prepare and fulfill an order. The app can still require identity, contact, address, payment, or school-related information.
- Each choice, field, validation message, loading state, and dialog should have a clear accessible name, role, state, and focus order.
- At large text sizes, choices and errors should reflow without hiding the current requirement. Closing a dialog should return focus predictably.
- Do not rely on color, motion, haptics, or a disabled button alone to explain why checkout cannot continue.
When this guide must be recertified
Recheck this contract whenever guest policy, allowed order types, checkout fields, address behavior, payment providers, school rules, login or signup, social identity, session handling, guest-data transfer, grouped carts, order placement, project switching, or shared accessibility primitives change.
Guest and conversion claims also require renewed review after changes to API deployment authority, capability lifetime, replay protection, transaction or idempotency behavior, error mapping, provider callbacks, or account and project cleanup.