Log in
Customer App can show an empty Log in form with one or more conditional methods. This reference explains the states and owners around that form. It does not ask you to enter, submit, copy, retain, or share credentials, one-time values, provider data, or account details.
A submitted form, completed challenge, provider success, or accepted Ordering response does not prove that guest merge, local session storage, provider identity, navigation, or later account gates all settled.
Sign-in methods are conditional
| Method or gate | What can be presented | Important boundary |
|---|---|---|
| Credential form | Email or phone plus password when enabled | Local validation and submission do not prove authentication or session creation. |
| Device-based sign-in | A device method when enabled for the current app experience | Device acceptance, Ordering authentication, account identity, and local session storage are separate. |
| One-time sign-in | Email or phone delivery choices, local countdown, input, checking, and resend when enabled | Generation, provider delivery, local timer, checking, session issuance, and replay protection are separate. |
| Social sign-in | One or more provider buttons when platform/configuration allows | Provider authorization is not Ordering identity verification, account linking, guest merge, or session settlement. |
| reCAPTCHA challenge | A challenge before or after an authentication error when configured | Client completion must be verified by the current server request; it is not authentication. |
| Support-provider identity | A consent-gated registration attempt after account login | It is downstream of authentication and does not prove provider registration or session correctness. |
A missing method does not prove the account, provider, or capability does not exist. Configuration, platform, project, session, and current account state can change the available empty form.
Submit and settlement are separate
| State | Safe interpretation |
|---|---|
| Empty form | No authentication request has started. |
| Local validation error | The current form state was rejected locally; no server/provider conclusion follows. |
| Submit requested | One authentication request may have started. Disable duplicate work until its result is known. |
| Challenge required or pending | Authentication is not complete. Challenge configuration and server validation remain separate. |
| Provider authorization returned | Ordering must still verify the assertion/profile and resolve account identity. |
| Ordering accepted | A server account/session result was returned; local storage and downstream work can still fail. |
| Guest merge pending | Prior guest state may be moving to the signed-in account; completeness and idempotency are separate. |
| Local session storage pending | Credential and account state can be written in more than one step; partial storage remains possible. |
| Post-login provider/event work | Support identity, notification installation, events, or restart can still be pending or fail. |
| Navigation changed | A destination became visible; it does not prove every previous phase settled. |
| Unknown outcome | The response was lost, the app restarted, or account/project/session changed before reconciliation. |
Credential, device, and one-time states
Credential, device, and one-time methods use different inputs and server paths. Do not infer that success or failure for one method applies to another.
For one-time sign-in, keep these states separate:
- delivery requested;
- provider acceptance or delivery;
- local countdown and resend availability;
- local input and automatic checking;
- Ordering authentication and session issuance; and
- local session storage and navigation.
The visible countdown is not authoritative server expiry. Resend does not prove rotation or invalidation of an earlier value. The current sources do not support a public guarantee about remaining attempts, exact expiry, lockout, replay, single use, or delivery.
Social, reCAPTCHA, and support providers
Social authorization, reCAPTCHA, and support registration are separate provider relationships:
- a social provider supplies an assertion or profile that Ordering must verify and link under an explicit identity policy;
- reCAPTCHA supplies a challenge result that the server must validate for the same current authentication request; and
- support registration can occur only after consent and account success, and must be cleared on logout/account/project change.
Provider UI success, cancellation, or error is not a Customer App session receipt. Do not use provider screens, alternate identities, or copied challenge data to troubleshoot documentation.
Guest merge, session storage, and navigation
A login can carry prior guest context into the account request. Server account resolution, guest-data merge, session issuance, local credential storage, local account storage, notification-installation binding, provider registration, events, restart, and the next destination can settle independently.
The next visible screen can depend on address state, project change, profile completion, account verification, tutorial, and the journey that requested Log in. No specific destination is guaranteed by an accepted login response.
Mono-session, logout, and revocation
An account can use a session strategy that changes how a new login relates to existing sessions. The pinned sources do not establish a public guarantee that a new login revokes every prior session, that a mono-session conflict is resolved atomically, or that provider/device/socket state follows server revocation.
Login, Logout, one-session revoke, all-session revoke, provider logout, and local storage cleanup are different operations. A signed-in or signed-out screen does not prove that every server and provider session reached the same state.
Errors, rate states, and unknown outcomes
| Observable outcome | Safe interpretation |
|---|---|
| Method or form is unavailable | Current capability/configuration is unresolved or unavailable; no account-existence inference. |
| Authentication error | The request was not accepted as presented; do not infer which credential, account, provider, or challenge condition caused it. |
| Challenge appears after an error | Authentication remains pending; the challenge is not a successful retry. |
| One-time value reports incorrect | No remaining-attempt, expiry, lockout, or account-existence conclusion follows. |
| Rate or wait state appears | Follow only the current visible state; exact server window and other methods remain unproved. |
| Mono-session or permission state appears | Session authority is unresolved; do not infer revocation or role from the message alone. |
| Accepted response but no destination | Local storage, guest merge, provider work, restart, or navigation may be partial. |
| App restarts or response disappears | Keep authentication/session outcome unknown and do not automatically submit again. |
Troubleshooting safely
A method is missing
Use only the empty-form methods currently shown. Do not change project/provider configuration or use a private route to force another method.
Submit stays busy or returns an error
Do not submit again automatically or switch methods to test the account. Keep the outcome unknown until the current form is ready.
A one-time value never arrives or reports incorrect
Do not infer account existence, expiry, attempts, or lockout. Do not share the recipient or value in support notes.
A provider closes or returns to Log in
Treat provider and Ordering state as unsettled. Do not repeat provider authorization or try another identity merely to force a result.
The challenge repeats
The authentication request is not settled. Do not copy challenge data or infer that a previous credential/provider step succeeded.
Log in appears accepted but the wrong destination opens
Navigation and later account/address/verification gates are separate. Avoid changing profile or project state to test the session.
The app restarts or returns to the empty form
Do not infer login failure or logout success. Re-establish the current session state before another authentication action.
Data from a prior guest, account, or project appears
Stop and avoid acting on, copying, or merging the stale state. The previous generation must be discarded.
Accessibility and privacy
Method tabs, fields, password visibility, device and social controls, challenge, one-time countdown/input/resend/checking, busy/error/rate/unknown states, Cancel, recovery, and Back need clear names, roles, states, announcements, focus order, and predictable return. Large text, keyboard, safe area, screen readers, and iOS/Android Back must not hide the current state or available safe exit.
Do not expose credentials, one-time values, recipient/account details, provider assertions, session values, device identity, guest data, or challenge data in screenshots, logs, diagnostics, support notes, or fixtures. These are verification requirements, not a current accessibility, authentication, or privacy certification.
When to recertify
Repeat isolated review after changes to credential/device/one-time methods; method gates; social providers; reCAPTCHA configuration/server validation; authentication errors/rate/mono-session handling; account linking; guest merge; session issuance/revocation; local storage; notification installation; consent- gated support registration; login/logout events; project restart; post-login navigation; accessibility; or App/components/API authority pins.
Related guides: Start the customer journey · Create an account or continue as guest · Verify your account · Profile and account overview · Account settings · Privacy and consent