Registration and Onboarding

NowToPrint keeps signup short and assigns access on the server. Onboarding asks how you will use the platform; it does not ask you to buy or choose a package.

Flow

Signup
  -> verification notice and sign-in screen
  -> email verification
  -> verified sign-in
  -> usage type
  -> optional passkey enrollment
  -> server-assigned membership status
  -> profile and activation steps

Signup and identity

Signup collects the person's first name, last name, email, authentication method, and legal consent. Company, tax, team, membership, and pricing questions are not part of signup.

For email/password signup, Firebase creates the credential after the server preflight. The idempotent Better Auth exchange receives the verified Firebase ID token, validated display name, short-lived signed receipt, and the password over TLS. It matches the password to the screened preflight and re-authenticates the exact Firebase UID, then immediately discards the password without persisting or logging it. Google registration uses a separate federated signup intent. An email match does not merge two identities. Signup and recovery responses do not reveal whether an account exists.

A successful registration first creates a restricted session that permits only email-verification operations. The registration redirect prefills the email address, while the signed verification link preserves any safe local continuation; dashboard and onboarding stay closed until verification is complete. If an exchange request is interrupted before its result is known, submit the form again. In the same tab, the browser resumes the exact Firebase UID and original idempotency operation. If the tab was closed or the local marker was lost, the form authenticates the existing credential with the supplied password and sends its exact UID through a new signed preflight and signup exchange; it does not try to create or delete that credential blindly. If a successful exchange response or its cookie-backed session confirmation is then lost after provisioning, the flow continues from sign-in instead of trying to create the same credential again. New passwords use the shared 15-128 character policy and the same compromised-password screening as administrator-created accounts.

The password indicator on the signup form evaluates that same shared policy. It does not invent a separate uppercase, digit, or symbol requirement: a sufficiently long passphrase can be both valid and strong, while a short mixed-character password remains invalid. Validation and server errors move focus to the first field that needs attention so the problem is reachable by keyboard and assistive technology. The password itself is never included in error, analytics, or audit output.

If a temporary network problem prevents cleanup after a rejected registration, keep the page open and retry registration. The client retries cleanup before creating another credential; the unfinished account has no application access.

Usage type and initial membership

Usage type	Initial state	Available immediately
Individual or corporate print customer	Print Customer	Basic purchasing and account capabilities
Agency / Broker	Review-controlled account	Basic customer capabilities; pilot features remain closed
Print Shop / Producer	Producer Candidate	Basic customer capabilities; producer operations remain closed
Supplier	Supplier Candidate	Basic customer capabilities; supplier operations remain closed

Producer and supplier candidates do not gain quoting, publishing, public listing, invoicing, or other producer/supplier authority merely by registering. The dashboard explains the review state and next profile steps.

Advanced memberships are not purchased or self-applied for. The platform may invite eligible accounts after evaluating operating history, participation, quality, expertise, trust, compliance, and other risk signals. Exact scoring, thresholds, and anti-abuse controls are not public. An invitation never creates authority by itself: independent approval, acceptance, a valid time window, and the current security policy are still required.

Membership access can expire, be revoked, or be reassessed. There is no recurring membership package price at launch, but transaction, service, logistics, payment/financing, and optional service fees may apply.

Passkey security

Onboarding offers an optional device passkey. A passkey is phishing-resistant and can also be used from the sign-in screen. Unsupported browsers can finish onboarding without it, and enrollment remains available in Profile later.

Privileged or sensitive actions may require a recently user-verified passkey even if onboarding enrollment was skipped. TOTP does not replace that critical-action proof.

Completion and session continuity

Completing onboarding increments the account's principal and authorization versions and revokes the old application sessions. While onboarding is pending, the client keeps the primary password/Google Firebase identity and deliberately postpones the custom-token data-plane binding. The browser accepts only that primary token lineage when it silently exchanges the identity for a new standard application session containing the new organization and membership facts, so no password is requested again. The final continuation uses a full page load so the active session can then establish its normal data-plane binding. If that final exchange is temporarily unavailable, Try again retries only the session replacement and does not create another organization. A validated callback returns you to the intended local page; external or malformed callback targets are ignored.

For both new customer and print-producer accounts, the onboarding page receives only the fields it actually consumes: account type/intent, business tags, first and last name, email, and display name. Server timestamps, uid, role, and referral-principal fields remain on the server while a validated local returnTo continuation is preserved.

Platform roles

Public signup never creates a platform administrator. A normal verified user may receive a separately reviewed platform-role request. A different platform owner must approve it, and phishing-resistant authentication remains mandatory for privileged operations.