Create an account or continue as guest
Customer App can present account creation and, in some experiences, a separate Guest choice. These are different identity journeys. Visibility, submission, navigation, or a provider response does not prove that an account, guest session, marketing preference, verification state, or downstream customer context settled.
:::warning Signup and Guest are separate
Guest is not a control inside the pinned Signup form. It is a conditional Home action. Do not infer that Guest is available from a Signup screen, that Signup preserves a guest session, or that either path completed because the visible screen changed.
:::
Compare the two choices
| Choice | Current source boundary | What it does not prove |
|---|---|---|
| Signup | A conditional account-creation form with configuration-dependent fields, methods, consent, and provider handoffs | Account creation, session issuance, guest merge, verification, address readiness, or provider completion |
| Continue as guest | A conditional Home action that can request a separate guest user and session | Registered account creation, durable guest eligibility, cart/order transfer, or later conversion |
A missing choice is not an error or evidence that it can be enabled. Account, project, configuration, caller, order, and provider state can change which choice appears.
Empty pre-submit states
A safe documentation state contains empty synthetic fields and no selected marketing, terms, reCAPTCHA, OTP, social, or provider choice. It can show only the field and method classes currently made visible by configuration.
Signup can conditionally present a bounded identity-field set, contact input, password, terms, marketing preference, anti-abuse check, account-method tabs, Login handoff, and social choices. No field, tab, provider, or terms destination is universal. An empty form does not prove that submission is available or that the configuration is valid.
Marketing consent is purpose and channel specific
Marketing email, SMS, and push preferences are separate choices. Each optional channel needs an explicit customer action and a versioned receipt tied to its purpose, account, project, policy, and time.
A combined promotions choice, an unchecked or omitted value, OS notification permission, account submission, or provider initialization does not prove the final state of every marketing channel. Signup must not default an optional channel to enabled merely because its value is missing. Later notification settings and provider delivery remain separate lifecycles.
Submission is not complete settlement
| Visible event | Safe interpretation |
|---|---|
| Validation begins or errors appear | The local form evaluated current values; no account request is proven. |
| Submit shows loading | One account or verification request may be pending; duplicate work must remain disabled. |
| Success message or navigation appears | One local/returned phase advanced; account, session, plugin, webhook, provider, and next-gate state remain separate. |
| Main customer surface appears | Local session/navigation changed; durable account authority and guest/cart merge still require reconciliation. |
| Verification or profile gate appears | A separate account requirement became current; it does not undo or certify earlier settlement. |
| Address screen appears | The current journey requires address state; no address or serviceability result is implied. |
| App restarts after a project change | Process state changed; the new project/account/provider generation still requires reconciliation. |
Account registration, session persistence, plugins, webhooks, marketing receipts, provider identities, and navigation require one recoverable outcome; the current source does not establish that combined settlement.
Guest creation and conversion
Guest creation can request a new guest identity and then establish local session state. A Guest button, loading state, main-screen navigation, or retained cart does not prove that every guest identity and order capability is authoritative.
Later Signup, Login, or social authentication must treat guest-to-account conversion as an explicit, audience-bound, one-time merge. It must not silently link accounts by shared contact information or assume that carts, orders, groups, payment context, or provider identities transfer successfully.
OTP, social, reCAPTCHA, and Intercom boundaries
| Boundary | Safe interpretation |
|---|---|
| OTP account method | A separate send, delivery, input, check, account, and session lifecycle; no delivery or verification is implied. |
| Social choice | A provider authorization result that still requires Ordering verification, explicit account-link/collision handling, guest merge, and session settlement. |
| reCAPTCHA | An external anti-abuse result; it does not create an account, prove a human identity, or grant marketing consent. |
| Intercom | A separate support-provider identity registration that must follow approved consent and current account/project generation. |
| Terms destination | An external content boundary; visibility does not prove that it is approved, reachable, or accepted. |
Cancel, error, or provider acceptance in one boundary does not settle another. This guide does not instruct any provider, OTP, social, reCAPTCHA, terms, or support action.
Validation, errors, and unknown outcomes
| State | Safe interpretation |
|---|---|
| Field or terms error | Local validation did not accept the current pre-submit state; account existence is unchanged. |
| reCAPTCHA unavailable or expired | Anti-abuse state is unavailable; no account or provider outcome follows. |
| OTP send/check error | Delivery, input, account creation, and session remain separate and can be unknown. |
| Social cancel or error | Ordinary Signup and the prior guest/session state should remain unchanged until reconciled. |
| Account response lost | Account creation and session settlement are unknown; do not automatically resubmit. |
| Account created but local session fails | Server identity and local app state can disagree. |
| Plugin, webhook, or provider failure after account work | Partial settlement; do not infer rollback or safe retry. |
| Guest request fails or is repeated | No guest session should be inferred; duplicate guest identities must not be created. |
| Account/project changes during a request | Late results must not enter the new generation. |
Troubleshooting safely
- Guest does not belong on the Signup form; use only the choice currently shown by its owning surface.
- A missing field or method does not prove that another configuration supports it.
- Do not use repeated Submit, Guest, OTP, social, or reCAPTCHA actions to resolve an unknown outcome.
- Do not change OS notification permission to determine a marketing preference.
- Do not infer session, guest merge, verification, address, or provider success from navigation alone.
- Keep names, contact information, credentials, marketing choices, tokens, verification data, account/session details, and raw errors out of screenshots and diagnostics.
Use only value-free state descriptions such as “signup settlement unknown” or “guest request unresolved.”
Accessibility and privacy
Fields, required/optional state, tabs, marketing and terms choices, password visibility, reCAPTCHA, Submit, Guest, Login, OTP, social choices, errors, loading, cancel, and unknown outcomes need clear names, roles, values, state, consequences, focus order, and predictable focus return. Large text, keyboard, safe-area, and screen-reader behavior must preserve all choices without exposing private data or provider results.
These are verification requirements, not a claim of current accessibility, privacy, provider, consent, or identity certification.
When to recertify
Repeat isolated review after changes to Signup or Home Guest placement; configuration-driven methods/fields/terms; marketing defaults or receipts; validation and duplicate-submit behavior; account/session/plugin/webhook settlement; guest creation/conversion; OTP/social/reCAPTCHA/Intercom/provider lifecycle; verification/profile/address routing; project restart; accessibility; or App/components/API authority pins.
Related guides: Start the customer journey · Log in · Verify your account · Complete required profile information · Privacy and consent · Social-login boundaries