Verify your account
Customer App can require account verification before some signed-in customer screens become available. The gate depends on current configuration, account state, session type, and whether email or phone verification is still required.
This reference does not ask you to request delivery, enter, share, retain, copy, or reuse verification data. Delivery, checking, account update, session update, and navigation are separate outcomes; no visible timer or message proves that all of them settled.
Root and Home verification gates
| Gate | What it can do | Important boundary |
|---|---|---|
| Root account gate | Make verification the current signed-in destination after higher-priority required profile information is resolved | It does not prove that delivery is available or that a provider accepted a request. |
| Home journey gate | Register verification inside the customer journey when a required channel remains unverified | Guest-checkout and other current gates can change whether this destination is presented. |
| Gate cleared | Allow current navigation to be recalculated after account/session state changes | A local screen change alone is not proof of durable server verification. |
Root and Home evaluate related account/configuration fields, but they are different navigation owners. Do not use a private route or repeated restart to force the gate.
Email and phone are distinct channels
| Channel state | Safe interpretation |
|---|---|
| Email required | The current account/configuration says email verification remains required. |
| Phone required | The current account/configuration says phone verification remains required. |
| Both required | The current source presents email first; phone can follow only after email state clears. |
| More than one phone delivery choice shown | Each offered delivery choice is a separate provider request and result. |
| Required channel without an available action | The gate and action availability can disagree; do not infer that delivery is possible. |
The current action area also depends on phone data even when email is the first required channel. This guide therefore does not promise that every required email prompt has a reachable Send action.
Keep send, delivery, entry, and checking separate
| State | Safe interpretation |
|---|---|
| Pre-send prompt | No delivery request has started. |
| Send requested | Customer App started one channel request; provider acceptance and delivery remain unknown. |
| Sent message shown | The client received a result it treated as sent; it does not prove receipt by the account owner. |
| Verification data entered | Input exists locally and has not yet proved account state. |
| Check requested | Customer App started an account-verification check. Completing the local input can trigger this automatically. |
| Accepted account response | Ordering returned an account result; local session/gate/navigation reconciliation remains separate. |
| Error | Send, delivery, checking, account update, or local error mapping can differ; do not infer which layer failed. |
| Unknown outcome | A response was lost, the app changed state, or the account/session changed before a final result. |
Resend, timer, expiry, and attempts
Resend is another delivery request. A reset timer does not prove that a new verification value was created, that an earlier value was invalidated, or that provider/server time was extended.
The visible countdown is local presentation. It is not authoritative expiry, delivery, resend eligibility, or lockout state. The pinned paths do not support a public promise about remaining attempts, effective lockout, one-time use, rotation, or exact expiration. Do not repeatedly resend or check to discover those limits.
Provider, account, and session settlement
Verification crosses separate owners:
- the delivery provider handles one channel request;
- Ordering owns recipient authorization, verification policy, account state, replay/attempt protection, and the authoritative result;
- Customer App stores current session/account state and recalculates gates; and
- navigation decides which screen is visible next.
Provider delivery does not verify the account. A server response does not, by itself, prove that the current local session, provider callbacks, caches, and navigation all moved to the same generation. Late results from a previous account, project, session, channel, or request must be ignored.
Errors and unknown outcomes
| Observable outcome | Safe interpretation |
|---|---|
| Send reports an error | Delivery may not have started, may have failed, or may still be unknown. |
| Nothing arrives | Do not infer that no request existed or that another channel is authorized. |
| Check reports invalid | The current input was not accepted; no remaining-attempt or expiry conclusion follows. |
| Timer reaches its end | Only the local countdown ended; server/provider validity is unproved. |
| Error disappears and input clears | Local error cleanup occurred; account state remains separate. |
| Gate disappears unexpectedly | Local/session state changed; durable account verification still requires reconciliation. |
| Response is lost | Keep the operation unknown and do not automatically resend or check again. |
Local Logout boundary
The Logout control on the current verification screen clears local session state through the app session owner. The pinned control does not establish server session revocation, provider cancellation, delivery cancellation, or complete cache/callback teardown.
Leaving the gate therefore does not prove verification was canceled or the account was safely signed out everywhere. A late provider or account result must not restore or modify the old local generation.
Troubleshooting safely
Verification appears before expected content
Treat it as the current account gate. Do not bypass it with a private route, notification, restart, or another account/project.
Email is shown while phone is also required
The current source prioritizes email. Do not infer that phone is complete or that both requests should be sent together.
A Send action is unavailable
Keep the state pre-send. Do not change account contact data or use an external provider destination to force delivery.
A sent message appears but nothing arrives
Keep delivery unknown. Do not share recipient or verification data in support notes and do not switch channels merely to test availability.
Resend or the timer behaves unexpectedly
Treat the timer as local only. Do not infer rotation, expiry, remaining attempts, or lockout from it.
The check reports an error or loses its response
Keep account verification unknown. Do not repeatedly submit or change account/ session context while checking may still be unsettled.
Logout leaves an unexpected screen or a late result appears
Treat Logout as local-only at this boundary. Do not infer server/provider revocation and do not continue in the stale account/session context.
Accessibility and privacy
Channel prompt, pre-send, Send, delivery-unknown, entry, automatic checking, busy, error, timer, Resend, Cancel, accepted, unknown, and Logout states need clear semantic names, roles, states, announcements, focus order, and safe return. The interface must not rely only on color, separate visual boxes, or a countdown to convey state. Large text and keyboard/safe-area behavior must keep the current explanation and available action reachable.
Screen readers and diagnostics must not expose recipient or verification data. These are verification requirements, not a current accessibility, security, or delivery certification.
When to recertify
Repeat isolated review after changes to Root/Home gate precedence; email/phone configuration or account flags; action availability; delivery channels; send/resend/check and local timer behavior; recipient authorization, attempt/ expiry/rotation/replay rules; account/session update and local Logout; provider callbacks; error mapping; navigation; accessibility; or App/components/API authority pins.
Related guides: Start the customer journey · Complete required profile information · Profile and account overview · Account settings · Use the app offline and reconnect · Platform and accessibility behavior